I guess this article is only about Macs, or something. I found I didn’t know what he was talking about. Why do you have to “clear your desktop” to make a video call?
No kidding. I don't see why you'd need to clear your desktop unless you're screen sharing and have things open you really don't want the other person seeing. If you're trying to find something on the Windows desktop, Win+D once to minimize everything, then a second time to bring all your windows back.
Well, "we" might have already abandoned the metaphor. On my Chromebook there is a filesystem but I can ignore it, and the filesystem lacks a thing called "desktop". There's no way to litter the root window with files, like there is on macOS or Windows or Ubuntu. Ephemera such as screenshots and downloads go in a little stack in the corner of the screen and eventually disappear, unless I pin them. Access to files is generally by search instead of folder traversal.
I use Linux, and my computer doesn't draw files (or anything else other than the default stipple) on the root window either; I have no desktop environment installed, because I do not use it and do not like it. (I don't use the Desktop, Downloads, Documents, etc directories, so I have deleted them. I can add directories with shorter names with whatever categorizations I need, and those aren't them.)
Files can be accessed by typing in their full path (with tab completion in some cases). (Some programs insist to use the GUI to select/list files rather than you can just type them in, and I hate this.) For searching files by name, ordering, etc, there is such commands as ls, and stuff that can be used.
For downloads, I will always type in what I want to save it as and in what directory, and usually I will use curl to download and redirect output to a file, or sometimes to another program is useful.
For screenshots, again I can use command-line programs; a program can make the screenshot, and then piped to the one that encodes it as PNG, and redirect its output to a file in order to save it to disk.
That dialog also invokes so many issues with computers today.
When I open a program, I want to use that program. I don't want to update it, I don't want to see all the new features, I want to USE it. I opened it because I had a task to complete and all this junk is getting in my way.
And same when I close a program, as the author hits on very well.
Basically, the computer/program/etc always wants me to do something for it, but it never asks for those things at an opportune time.
No, I don't want to update my computer right now, and no, updating overnight tonight isn't good either because I need to keep this program running until tomorrow. I understand that your new UX is better for me, and I'm sure I'll love it, but forcing that on me right now is preventing me from doing what I need to do. I see your error dialog describing some odd issue, but I don't have time to triage that right now and decide to take the time to fix it.
I wish software would respect the human element more. My time and attention is valuable, please don't interrupt it carelessly.
I think some are getting quite good. I’m following Manjaro/Phosh, and it’s showing promise. I’m not using it for much yet, just watching it develop. I believe other distros are further along.
The closest thing to secure, actually usable Linux distro on phones is Android; if you are serious about security and degoogling GrapheneOS especially. The bad thing is that you have to have a Pixel for that.
Source: I own a Pinephone and has tried both Phosh-based and KDE-based offerings, there is also Sailfish though. Out of these Sailfish is the only one close to usable as of now.
As it stands, the only thing keeping my Pinephone from replacing my BlackBerry is better messaging notifications. Calling, messaging (via Matrix), and Firefox are all mostly good enough for me.
Note I'm not saying it's good, but good enough for me. I've been using Arch, as I find the rate of improvement shows in a rolling release distro, and in my experience, Mobian is no more stable.
I think that random examples without reference to a particular arena would be...random. If you would like a recommendation for an email client, or a web server, or a programming language, I would be happy to share what works for me. I do everything on Linux, by the way.
Better software doesn't always exist and when it does exist is not always possible to switch (or has other downsides).
But for example Steam updates on boot, which is a (albeit minor) pain when I want to use it. Similar with Spotify. There aren't really any great alternatives to either of them that have equivalent libraries of content.
Or going right to the core, Windows and it's annoyingly frequent updates. Sure I could use Linux (and I do on a few machines), but that isn't possible on my work machines, and introduces incompatibilities on my personal machines.
Unfortunately that's not always feasible. I use Cura a 3D printing slicer (takes a 3D model, generates instructions for your printer), and it's one of the best at what it does (slicing). The UX is horrible though and is clearly 'designed by programmers' with little thought into how people will actually use it. And every time I upgrade there's a 50/50 chance it'll forget all my settings (there's lots of things you need to tweak and customise specific to your printer) and I'll need to start from scratch. Dealing with these issues is easier that switching to different software and learning it from scratch.
I’m really confused how the author generated 88 documents in
Preview that are unsaved. What kind of documents and changes were these? Why were they not saved when the changes were made? Preview is mainly used to view image files and do simple editing. Those edits are auto saved as you go long.
I’m sure the author has a point but I’m just distracted by this strange use case.
It’s a balance though isn’t it. If they hide everything away so as to respect your time, then another user will be frustrated by the constant magic going on in the background. Even you might want more prompts in some situations.
Maybe some applications could have an alert mode, similar to logging levels. But then it will probably get more buggy.
Honestly, I rarely get annoyed by the number of popups in most of my software. I’ll happily take a few extra dialog boxes for extra control.
The extreme alternative to "device, please don't ask me when you want to update something, just do it" is losing control of your computer. If you're comfortable, like the author mentions, having your digital "home" be away from your devices, to "live in the cloud", I guess this doesn't matter (at least, while your favorite cloud providers and services don't shut down taking all your data with them, decide to hike prices, or ban you for breaking some ToS rule).
If you want to fully own your computer, it matters. You don't want to give away all control over it.
I don't think those are the only options. For example, Linux Mint shows an icon in the system tray to indicate when repository updates are available. I fully own the computer, and it is my choice if/when to apply updates. However, that doesn't imply that each individual program needs to yell at me at startup to get updates.
For security updates it still depends on risk though.
A flaw in my browser is extremely high risk and I require it fixed and updated quickly. But a flaw in my SSH server that is only accessible from behind a VPN is lower. And the risk is lower still if it's a flaw in a feature which I do not use.
I don't see an easy solution of course, it's a hard problem. But I wish that I had more granular control over what and when I update, and was given a clearer way to see the impacts of the update so I could weigh risk.
I totally agree that provided enough time and users, changing the user interface will almost always break some users experience. “Better” is subjective.
On my Linux systems, both server and desktop there are a set of programs that I don’t use the package manager for, because they’re usually out of date.
This includes browsers, where I let the auto updates handle it, and programming environments (Python, R, Node), where I often use their specific updaters.
I don’t think it’s realistic to expect a global curated package manager to stay on top of the bleeding edge all the time.
The way Linux puts the package manager front-and-center is pretty cool, but in my experience it doesn't result in a very up-to-date system. You might have a version of OpenOffice that is years out of date. Oh, you want the latest version? You need to update your Ubuntu 16.04 first, it'll say!
I'm a programmer and still this makes no sense to me. Windows and Mac somehow let me use the latest OpenOffice even if I haven't updated my OS in forever.
Sure, but why? I can easily install the latest Firefox on Windows XP most likely (or could until a few years ago), but I can't on Ubuntu 20.04 (or couldn't until Firefox started doing auto updates on Ubuntu as well)?
Because Linux folks like to bash on Windows, while in reality they live like every application would be putting their stuff into C:\Windows, like Windows used to do in the old day pre-XP.
So naturally when all applications depend on the same shared libraries and configuration files, they need to be updated on a full swoop.
Yeah, when one knows their way around UNIX it is possible to actually install new software that works around this, but that is exactly the problem for most desktop users, "one knows their way around UNIX".
> Oh, you want the latest version? You need to update your Ubuntu 16.04 first, it'll say!
Well, yes, that's the flipside of updating everything at the same time. You have to update everything :)
And if you're using an LTS version of an OS, you'll usually get a related LTS version of the apps from the same era, especially for the older OS versions. Because they prioritise production stability. If you just use it as a working desktop you'd be better off using the bi-yearly versions.
Because in practice if you don't push people to update, they just don't update. And then complain about bugs, security issues, bad performance, missing features, etc... all available in the updates they have been postponing for years.
that is a problem but servers are one place where there should absolutely not ever have automated updates that cannot be overridden and turn off as you are apt to break things if it isn't tested first.
I 100% feel this pain. And for security updates and major fixes, I see the need for frequent updates.
Though setting aside practicality for a bit I wish we would design software to be more backwards compatible so old versions of things could continue to work for longer. I shouldn't have to buy a new phone every three years, for example.
Also for a tool like Audacity, I rarely need to update it. It doesn't depend on a service, so I don't need to worry about an API falling out of support and he security risks are much lower. I wish we could design more of our software to work this way.
Obviously for internet connected things like browsers this isn't possible as the security impacts are significantly higher, but why should I need to update Word every month if I don't plan to use the online components, for example.
Just spitballing here: what if we selectively notified users of updates when they'll be affected? So, when I'm using my spreadsheet program, and I go to sort the rows, a little note pops up informing me that there's a bug in sorting non-ascii characters that was fixed recently and would I like to update my word processor now or continue anyway?
I'm imagining some automated tooling where changelogs are tied to specific git commits, and when you go down a code path that has a changelog entry tied to it in this way, it pops up the dialog. The program downloads the changelogs in the background (if the user chooses), but doesn't pop up a notification unless it's relevant to the user.
I don't think it would entice more people into upgrading. People don't necessary want to stay on old versions, they just don't want to be interrupted. To make it more probable that a user updates, you need to make the interruption as little as possible: download stuff in the background, make it patches rather than full blown installer, ... to follow in your direction, if I have a popup that says "you just sorted rows alphabetically but there's a bug, do you want me to fix it ?" and the install takes 5 seconds then it's good. If it takes 30 minutes then screw your update
I think what we need is another way of architecturing software. I'm thinking of Erlang's actors and hot reloading: the whole language and its environment were built to allow upgrading parts of the app without turning the whole thing off, thanks to actors that compartmentalize state and minimize the places where it can change. That's extremely useful for servers, but why can't I have the same for desktop apps ? For your example again, maybe have some "actor" that can give me a sort, and when updates come the old instance is killed and the new instance takes its place. No need to turn down the app, to lose my current work, to waste dozens of minutes.
Unfortunately desktop apps are pretty much dead for the masses, and webapps solve both the problem of not updating (next time you come it'll be updated) and atomic updates (a client side app can load some javascript when needed). If we want desktop apps to come back (I do) we need to find a way to do the same
> I don't think it would entice more people into upgrading. People don't necessary want to stay on old versions, they just don't want to be interrupted.
It might, if you did it like GP posted:
>> a little note pops up informing me that there's a bug in sorting non-ascii characters that was fixed recently
>> The program downloads the changelogs in the background (if the user chooses)
Note the stark deviation from standard practice: GP would like the popups to actually tell you what's in the update.
In my experience with both techies and non-techies alike, the main reason everyone hates updates is that it's always a cat in a bag. You'll likely get some bug fixes. You may get some new features. Some of those may even be useful. It's more likely the app will become slower instead of faster. It's quite likely there will be disruptive UI changes. Often completely gratuitous ones.
Random recent example: I noticed my wife has an OS update on her phone pending for the past three months. I asked, she agreed, I did the update round. Told her, "wow, you're getting a version bump, I envy you". I immediately noticed some user-set icons were wrong[0], but quickly corrected it without saying anything. I though that's the worst of it. Couple hours later, she comes back to me complaining that the update messed up notification sounds and the new keyboard has changed scaling, breaking her muscle memory for touch typing. Also the battery life dropped significantly.
Updates today are like loot boxes in games, except most of the "rewards" make your life worse.
One solution to this problem would be to have a separate stream for feature updates, and a separate one for bugfixes and security updates - and only ever bother the user about the latter. But that would increase the costs for the software vendor, and we can't have that. Who are you, the user, to complain about what your lord does? SaaS stands for Serfdom as a Service.
--
[0] - The ones you assign to your SIM cards in dual-SIM use scenario. The update added new icons to the set, and apparently the OS must have been storing user choice as an index into that set, instead of using icon ID.
Can't agree more with everything you're saying, except for the last part: if bugfixes/security updates are in one stream, and new features are in another, the first one should be applied all the time without asking, and the second one should be the one that prompts a pop-up.
> SaaS stands for Serfdom as a Service
It's interesting that the SaaS term was born from the Cloud, but its tenets still apply to desktop applications
> bugfixes/security updates (...) should be applied all the time without asking
I'd agree in most cases, but I'd still leave some grace period for updates that require rebooting the app or the OS. Nag and cajole the user all you want, but don't ever lose their data, or interrupt them during a meeting.
> SaaS term was born from the Cloud, but its tenets still apply to desktop applications
There are two main facets of SaaS - a nice one, and a nasty one. The nice one is that it outsources ops/maintenance. You're just using the software, someone else is keeping it running and up to date - and it's more efficient this way. The nasty one is, the party controlling the software is in position of power - they can make you pay rent, lock you in and hold your data ransom, and exploit your data in ways you don't want - and you can't do anything to stop it.
Desktop apps relinquish most of the benefits of SaaS, but the drawbacks were backported to local software by means of normalizing subscriptions and automatic updates.
I just want updates to happen in a separate 'thread'. Not (necessarily) in the literal sense, in the sense of my human attention. Update in the background, don't interfere with my use of the application itself — at most, give me an icon that tells me the application will be a newer version the next time I restart it, a bit like how Google Chrome manages its updates.
I generally agree. And Chromes method is definitely better than Steam's where you have to wait 30 seconds on boot every few days for it to load.
But that introduces issues where if Google adds some shitty new feature to Chrome I sorta get forced into it instead of having an opportunity to choose, so there's definitely a tradeoff and also a responsibility on the part of the vendor to make sure they aren't abusing their ability to install things on my computer.
I don't like automatic updates either. I can just acquire the new version somehow and update it that way (perhaps handled by the package manager, when I tell it to update the package); it shouldn't be a part of the program itself, I think.
The notification center or whatever it's called that's available in pretty much every modern OS would be a good location for such stuff. It's available, retrievable and not in the way when you don't want it.
I'm generally in favor of more control too. Though that control extends to wanting to be able to control when my software updates and when I get to have new features, settings,etc.
My comment above is more of a rant than a recommendation.
It would be lovely if it became a standard part of everybody's work day to spent 15 minutes doing TLC to their computer.
You'd clear away all the stubs of work, and the computer would say "Hi! Did you have a good work day? Here are a few things that would be great for you to do:
1. Upgrade these two apps
2. Do you want to check out how Dark Mode works? No? Ok
3. You've had these 46 tabs open since that one day six weeks ago you got into the idea of building your own treehouse. Want me to save them all in a notebook entry and remind you about it next summer?
Really, any machine needs maintenance. Even an electric stove or a microwave needs an occasional clean if it gets dirty. Why should computers be the only special appliance that needs no maintenance whatsoever?
Personally I almost never agree with these "the desktop is dead" kind of articles. If anything, the problem this author has to be exacerbated by the move away from the traditional desktop style than an embrace of it. That preview close dialog is not something you'd see 20 years but is something you see in "apps" all the time.
Perhaps the problem is, as you allude to, that software is hostile to the user now. There's always something more than simply being a tool that you buy, use, and close. Now most programs are merely portals for "services".
This is spot on. People want to hand over responsibility for their computations to some big company offering a "free" service so long as you use the official app, and then they wonder why they don't feel like they have any power or freedom.
> That preview close dialog is not something you'd see 20 years
That’s because the application would straight up lose the files without prompting.
Also pretty sure text editors had something similar 50 years back, that’s why you :q! from vim, :q would tell you that you have unsaved buffers (or whatever the lingo is) and refuse.
TFA is literally abusing a crash-resistance feature out of laziness, and will no doubt complain when it fails them. 20 years back we’d all trained ourselves to save with regularity to avoid issues, that feature would be considered manna from the heavens, and tfa absolutely mental.
Completely stupidly too, I must add:
> This is the dialog that I see every time I want to close the Preview app to clear my desktop of all that clutter in a hurry for a video call.
MacOS has a shortcut to minimize all windows! It even has a shortcut to hide all aplications but the current one! You don’t need to close anything to “clear your desktop in a hurry”!
Yeah but the semantic difference between "hide" and "quit" is a very technical one that doesn't need to exist. On mobile it doesn't happen, and we can thank Android for that, as they insisted from day one that multi-tasking APIs should not require the user to manually manage memory on the device. When Apple added multi-tasking to iOS later they copied the Android design more or less exactly. Browsers do something similar for browser tabs now.
However this was never brought to the desktop, largely because native desktop APIs are dead and none of the companies that fund them are interested in improving them. We get the web and if it sucks, well too bad.
> Yeah but the semantic difference between "hide" and "quit" is a very technical one that doesn't need to exist.
Funny, because I think the exact opposite. "Hide" means, "stop showing it for now, but keep it around". "Quit" means, "I'm done with you and I expect you to not be doing any work until I start you again". It's a very significant usability difference.
> On mobile it doesn't happen, and we can thank Android for that
To this day I consider it to be the worst, most dumb idea Android ever had. I hate it. It's the reason I hated my first smartphone. It's the reason why, from the second phone on, I only ever buy top-of-the-line most overpriced flagships available - I have to overprovision resources to ensure the phone works smoothly, because there are countless of background processes doing god knows what, that cannot be killed and prevented from restarting.
I know best when I'm done with an app. I want to be able to kill it, and all its background processes, and I want them to stay dead until I change my mind. If I were designing a mobile OS, I'd make the distinction between "hide" and "quit" as clear as day, and make it an app store policy violation for an app to execute anything in the background after being "quitted" by the user (polling for notifications would be handled by the system).
I agree with you about this distinction being important, but I come at it from a different angle - I don't mind if most apps operate in the background as they need, with preemptive scheduling like Android. But I really, Really mind if I don't have a rock solid way to quickly and easily kill an app (and all related tasks/processes/async jobs/etc).
1. There are times I want to make sure an app is not running (think zoom/hangouts with video access), or a work app that records location
2. The single best way to fix a problem, any problem, is still 'turn it off and back on again'.
I don't want to kill the current activity and hope that the background jobs stop at some point in the nearish future with absolutely no feedback or insight. I want "killall <root app process>" then give the app 5ish seconds to cleanup and if it's still around "killall -9 <root app process>".
On mobile there are ways to force quit apps. They just aren't front and centre, nor mandatory for users to understand, like it is on the desktop.
Too many apps abusing resources and affecting UI speed is a separate issue, and mobile OS's developed a lot of techniques and technologies to allow apps to work in the background without bothering the user, and without overloading the device's resources. It's a nice set of systems, really, and I would be happy if desktops worked the same way. Nobody would be taking force quit away from me, even if such a system were to be implemented.
> On mobile it doesn't happen, and we can thank Android for that, as they insisted from day one that multi-tasking APIs should not require the user to manually manage memory on the device.
Yes, and this turns my phone into an amnesiac the moment I have a hundred tabs and fifteen apps open. Switch to a different app, switch back... Oops, all gone! Enjoy recreating the state from history manually, if that's even possible.
There are no words to express how unhappy this makes me. We've got gigabytes of memory on our handhelds these days, why can't the phone just deal with it?
The (graphical) software program with guaranteed internet connectivity has become a control vector for the software author, many times the company employing the software author, over the user. Users are being "used", as suggested by the original author of GCC.
For whatever reasons, non-graphical software seems to suffer less from this problem.
Seconded. It seems like over the years I spend a greater and greater fraction of my screen time either setting something up or un-fucking it after an update/new version ruined it.
> No, I don't want to update my computer right now, and no, updating overnight tonight isn't good either because I need to keep this program running until tomorrow. I understand that your new UX is better for me, and I'm sure I'll love it, but forcing that on me right now is preventing me from doing what I need to do.
I especially love when Firefox decides that he really needs to update, and I cannot open any new tab until I do so. Who cares if I am on a crappy connection and the download that I need to finish will take 20 minutes more; it's either restart it or wait until I finish. And that other thing in that tab that I need time to finish but I cannot really save ? Who cares.
That Firefox issue only happens on Linux when you upgrade Firefox on disk using your package manager while Firefox is running. The ABI mismatch between the running version and the new version makes starting new Firefox processes unstable, so it's disabled to avoid crashes.
Simply don't run system updates during a Firefox session and you're golden.
Yeah, it’s a linux distro issue. Alternatively, run NixOS that instead of swapping the running executable file under itself will create a new environment with a new firefox and start that one next time.
> When I open a program, I want to use that program. I don't want to update it, I don't want to see all the new features, I want to USE it.
Indeed. Microsoft Office I'm looking at you! I don't think I've ever actually looked at one of those "Hey cool new stuff for you" popups more than trying to identify how to get rid of it as quickly as possible.
And even worse is "Hey here's a new feature we like so we turned it on for you, good luck figuring out where to turn it off again lol"
Exactly. I mean, how hard is it to just give people a proper changelog? Am I the only one who's excited about the new features, when I get to read a proper list of them before installing a new version of the product?
Google Maps on Android is the worst offender I've ever seen with this. Practically every time I open the app I get spammed with some dialog box or extraneous UI elements. The worst part is Google Maps is kind of a "just in time" affair. I only open it when I'm going somewhere and I need it to function right now. Alas.
It didn’t used to be like that. But then people never updated their os/software and we ended up with lots of vulnerabilities.
I like where Windows is now, I get notified of required updates but I can defer it for a few days/week. For non-technical people who don’t know how to setup defers I’d imagine they would also be the crowd before who didn’t update. I’m totally fine with my parents occasionally grumbling about a forced reboot overnight.
Likewise all the software I use, besides online games, let me defer updates. Lots of stuff also now has the update next start, which I also like. I don’t even notice my browser updating most of the time until I open dev tools and see “what’s new”
> But then people never updated their os/software and we ended up with lots of vulnerabilities. <
Seems like we have a fundamental security issue that results in having to keep fixing vulnerabilities across most software, which sounds like applying bandaids and treating symptoms rather than coming up with a more secure approach.
> But then people never updated their os/software and we ended up with lots of vulnerabilities.
Perhaps the issue was that we insisted every program be internet connected. If everything were offline a la Battlestar Galactica, security exposure would be greatly reduced - pretty much only the standard USB stick attack vector would work.
> When I open a program, I want to use that program. I don't want to update it, I don't want to see all the new features, I want to USE it. I opened it because I had a task to complete and all this junk is getting in my way.
> And same when I close a program, as the author hits on very well.
The weird thing is, that is a solved problem. App Store apps (Mac, iOS) will automatically update in the background and, unless the developers build it into the app, the changelog if any will be on the store page. All platforms have something similar. It's just that a lot of developers opt to release and update their thing separately for a variety of reasons.
I agree on the OS updates though, some years ago there were a few... claims? Promises? Something that implied restarting to update would no longer be a thing. Dear reader, they were wrong.
> When I open a program, I want to use that program. I don't want to update it, I don't want to see all the new features, I want to USE it. I opened it because I had a task to complete and all this junk is getting in my way.
Jonathan Blow did a talk similar to this a few years ago, about how "software is terrible".
In a part of it, he double clicked on a .psd file to open in Photoshop and timed how long it took to open the image. It took around 8 seconds for Photoshop to display that image on screen. But the first thing the app did was show a splash screen image, almost instantly.
His argument was, "Why, when I double click this image file that I want to view, does it instantly load an image which isn't the one I want to view, and then take 8 seconds to load the one I do want to view. If it can instantly load an image when I double click the file, why isn't that image the one I double clicked?"
I’ve seen that talk too, and it struck me as a bad example. Photoshop is not primarily a tool for viewing images, but for editing them. It would be great if it could get me there faster, but as a comparison I just tried timing how long it takes to launch The Witness, and ended up with something like 13 seconds.
If it takes 8s to load the file, the better design is to take 8.05s instead to display the splash screen and a progress bar to indicate to the user that their request is being processed. Good interfaces are never unresponsive. So, bad example. :)
In a parallel world, the image loads first, alone on the screen, then the toolboxes, then the window frame. Then the splash screen for 8s because the marketing guys always have it ;)
Yeah and Windows 10 designers take note: there’s no situation where it’s OK to randomly decide you’re going to log me off in 5 minutes without a freaking cancel button. I lost 20+ hours of work on a process that can’t resume itself because of this insanity.
The essay did not convince me the need to rethink the desktop or sufficiently explain the idea of fragments versus work products.
Yes, search is great when it works. You know what also works? Organization. I used search within folders of very large category to rapidly narrow stuff down.
If the desktop ain't broke, it doesn't need fixing.
Instead, I am thinking about all the dark patterns and anti-patterns, as well as performance hog, endless constant update, as well naggers trying to upsell you shit.
There's a reason why I returned to linux. Microsoft, please fix your shit.
How many people are actually effectively organizing their data in files? If a system doesn't work for vast majority of users, then it does deserve rethinking. Its great that desktop model works for you, but I strongly suspect you are not representative of the greater user base.
Rethinking is fine, if it leads to action. If the desktop isn't working for the vast majority of users, then it's certainly the prerogative of anyone in the world to code up something which is guaranteed to make every one of those users happy.
>If a system doesn't work for vast majority of users, then it does deserve rethinking.
No, if a commercial for profit system doesn't work for the vast majority of users, then it does deserve rethinking. Linux is a great example of an operating system that was not written for the highest profitable denominator until recently.
I feel like the author’s proposed solution of better searching through tagging and semantic associations over manual organization also requires user care and effort. I don’t think the desktop model is broken so much as the average person isn’t very organized to begin with.
This tagging idea resurfaces every few years. I have to confess I don’t really see where the revolutionary improvement is. Filenames are already namespaced tags and symlinks allow for multiple tags. Not quite the same thing, I know, but close enough for tagging to appear to me to be a convenient enhancement rather than something game changing.
And as you imply, when you have a lot of files that you need to organise, you tend to start compiling them into directories.
So your solution to organizing files... is more files? How would multiple files use the same "tag" under that scheme, without duplicating it everywhere?
Tags are very powerful if used properly. They describe sets by definition and allow quick filtering with intersections and other set operations. If the filtering is a bit smarter it can support boolean operators, or use tag distance and order as a meaningful data point so that e.g. "discussion board" doesn't return the same results as "discussion snow board".
They're a more flexible way to organize data than hierarchical directories. Hierarchy can easily be expressed with tags (use any character as separator, e.g. "os.linux"), but files and directories are not nearly as expressive enough for all the use cases tags can be used for.
I've been working on a file organization system that incorporates tags, and I must say I agree with the GP. Tags improve display and search over hierarchies, but they require no less discipline on the part of the user. Without some way to automatically mass-assign meaningful tags to items, which is an insanely difficult problem in the general case, the user is forced to manually tag every single item they add to the system. AI could help do this, but not much. First, consider that mistagging an item can make it practically impossible to find again. Second, consider that semantic tagging can be almost arbitrarily abstract; imagine tagging a text document with "cyberpunk" or an image file with "parody".
The genius of Google search was leveraging hyperlinks to add semantics. The only way I can see something somewhat equivalent happening is by exposing all my interactions incl. e.g. the juggling and browsing of other documents beyond the one worked on to search. I would find this scary.
> So your solution to organizing files... is more files? How would multiple files use the same "tag" under that scheme, without duplicating it everywhere?
You could put the same file in multiple directories. You could have a file in ~/vat and symlink it to ~/urgent and ~/accountant.
You're right, that could work in theory. In practice it would be difficult to manage and keep track of all the links, update them if the file is moved, etc. I suppose hard links would avoid that, so that might be a reasonable way to implement tags, I agree. My main goal would be to manage this via a tag-like UI, so that I don't have to do this manually. And at that point I might as well just store the metadata in a proper DB instead of the filesystem...
I'm not dismissing the utility of tags, and I like your idea. I'd definitely install it as an application and give it a go.
I'm really addressing the argument that tags are a revolutionary change that should replace the directory-based filesystem entirely. The cost seems too high to justify the benefit.
Yeah, it still requires management and discipline from the user for it to be useful. FWIW I use Pinboard daily and finding something among thousands of bookmarks is a breeze. I can usually find what I'm looking for with a single tag or an intersection of just two tags. Finding anything on the filesystem is much more difficult, even with good directory structure discipline.
I'm not actually interested in building such a system, it's been done before[1,2]. Though I haven't actually used any extensively, since it does require a shift in how file management is done, and I'm quite familiar with filesystems to bother to change, but it's on my list. :)
The majority of users don't even realize they're interacting with files. The mantle falls entirely on developers to ensure that their programs are simple.
Most users have no idea of what is even possible with a computer, organization-wise.
I don't disagree that interfaces should be designed for users, but they should be designed to EMPOWER and teach users, not to just dumb everything down to the lowest common denominator. Because, let's face it, most people are awful at organizing stuff that materially matters a lot to their lives and well-being.
Except it does not work for those users because automatically managing vast unordered, uncategorized data sets is not a problem we know how to solve. If we knew how to solve that problem, we could just implement it in the existing hierarchical manually-organized paradigm by just having one hierarchical level and dumping all your data into it. Given that the new model fits in the old model, the only reason for demolishing the old model is for efficiency reasons and there is very little in the way of efficiency that can be gained by converting the relatively shallow organizational trees that are commonly used for a single-level store.
Why do I believe we do not know how to solve the problem? As the article inadvertently points out, the unorganized data they want is not accessible and Mac Spotlight, a tool that operates on unorganized data, does an "OK Job, but not a miraculous one". If Apple knew how to super search the vast trove of unorganized data and file formats for content-specific data and always get it right would there be any reason they would not do so? It would clearly be strictly superior to their existing offering. For that matter, they bring up browsing history in Safari which is an even easier problem and also claim it hardly works. For evidence outside of Apple, think of all the in-app search systems that can barely even search plaintext for things you know exist. I frequently have problems with Gmail not finding emails despite giving exact string matches. These problems are all subsets of the proposed problem, which must be solved to solve the harder problem, and which would offer immediate material benefits for their solution yet do not or barely exist.
The problem is not a mismatch between solution and user workflow. The problem is that we do not know how to solve the problem for all meaningful workflows. The best we have achieved is creating and supporting a workflow that allows the problem to be solved in many useful cases. Luckily, if the problem can actually be solved in the future, it can easily be bolted onto the existing solution to test viability before going all-in.
> It would clearly be strictly superior to their existing offering. For that matter, they bring up browsing history in Safari which is an even easier problem and also claim it hardly works. For evidence outside of Apple
For evidence outside of Apple, just try to use browser history in Chrome or Firefox. They're completely unreliable, entirely useless. For me, it's 50/50 chance I'll get a result when searching for a site that I visited few days earlier.
> think of all the in-app search systems that can barely even search plaintext for things you know exist
Exactly.
Most of the search systems I've worked with have one, big problem: they don't feel reliable. You type in a query, a system starts a search. You get some indicator of progress, which eventually expires. Typically, search systems don't tell you if the search was exhaustive - did it check every possible thing that could match, or did it bail out after hitting some time limit? They also often meddle with the query, modifying it or doing fuzzy matches, in ways not communicated to you in the user interface. With such systems, if the thing I'm looking for isn't in the result set, I don't feel confident it isn't there.
Manual file organization (or any direct data access) has this property of being exhaustive: a file is either there or it isn't. Direct file access means that if you don't trust your file searcher, you can always look for yourself.
There are many other challenges ahead if we want "universal search" to work, but a big step forward would be addressing these trust issues. It's entirely an UI issue. Instead of "0 results found", say "0 results found after searching contents of all text files in Documents folder (symbolic links not followed)". Instead of "about 123 results", say "123 results found, there may be more matches, [click here] to read about limitations of the search method".
(And on a general point: users aren't as dumb as the common claim is. Our industry is treating them as dumb, taking away every opportunity to learn and build mental models - and then complains that users "are dumb".)
You'll get a biased answer because you'll include a group of people who won't succeed no matter what approach you take. People have tried that approach and ended up with things like Microsoft Bob.
The real question is what is effective for individuals and business trying to accomplish real work, who are at least somewhat capable of learning or training staff.
This works great if you are dealing with files, and are disciplined enough to organise them, but in other cases it turns into a big mess. My wife is not disciplined in that way so her computer has many layers deep of temporary and non-temporary documents on the Desktop, and Windows is constantly complaining there is no disk space. Her iPhone is the same because of podcasts and WhatsApp groups that auto-download media but never clear out the old stuff.
The idea of fragments as TFA discusses really resonated with me, because most of my life is not in files. Giving a real example, a few months ago I read a blog post about some house planning software (I'm in the process of building a house), and later needed to refer back to it. I didn't save it anywhere (bookmark, save as PDF, Notion/Roam etc) because it didn't seem that important at the time.
Its the same if you watch a YouTube video or read an article here. Sure you could take notes and save those notes in a text file that you can later search, but who has the time to that for every single piece of content they consume?
Something like Spotlight is a good start, but it needs much more meta-data. All of your search and watch history needs to be there, but in a world that's becoming every more siloed (how do I record the photo a friend shared with me a few months ago on Facebook Messenger?) that's tricky.
The problem with magical solutions like the fragment idea is that they require magic to implement.
Most software can't be bothered to integrate rich paste support (e.g. the way you can paste an Excel spreadsheet into a Word document), and we expect them to implement a complex API to define these fragments in a way where the OS/Spotlight could actually build up that history?
This would be a massive undertaking requiring buy-in from every piece of software before it is even marginally usable. It is a pipe dream (and may even be a nightmare if it were realizable).
How would one organize better, by flooding the system with even more data? Fragments would be no different than files, just smaller, yet still objects to organize away. Whats neccessary are tools which need to make use if them, and for this there were many many attempts over the years. Several more are still going even now. But all of them fail, because the basic problem still can't be solved by software, which is the responsability of the user to organize their stuff.
> Its the same if you watch a YouTube video or read an article here. Sure you could take notes and save those notes in a text file that you can later search, but who has the time to that for every single piece of content they consume?
Those already exist. The browser has them all in it's history. Google similar has many if them stored for their services. To some degree they use them for the user, but there is simply limited use for those informations.
The biggest thing I miss in the file folder paradigm is dividers/sections. Like folders, but without nesting.
I used to have a tendency to over-categorize and nest things too deeply, which makes them hard to find again. Concrete example: nesting classes by semester. When looking back for something, I would usually remember what class it was, but I'd often forget the semester. So now I have to search through a bunch of folders (manually or automatically) to find it. Ugh. A flat structure is much easier to follow.
However, I still want all my classes grouped together when I'm listing them. Currently the only way I know to achieve this is by adding a prefix to the file or folder name. This works, but you end up with some grotesque names. The implementation could be regular folders with a flag to indicate their contents should be displayed inline one level above.
I've started putting timestamps at the start of filenames recently and is been working pretty well. yyyymmddhhmmss, then an optional filename if needed.
it might still be your idea of grotesque, and the timestamp does take up a bit of space unfortunately but at least its consistent.
going with your example above, it would allow you to just have folders for classes and then have files from all years in the same class folder. then you can sort of hack together a divider feature by adding some brightly coloured jpgs with a timestamp at the start of the year which would let you see at a glance where each year starts and ends.
it also helps if your file browser will remember to open each folder with the newest files show first at the top
Just a counterpoint: I literally save every document to one giant folder, and give every file a longer descriptive name so I'll be able to search for it easily.
I've been doing this for almost ten years, and it works great.
I think we are law the old desktop metaphor - but for different reasons.
Once upon a time there was a "manager" whose job primarily was to communicate via memo with his peers and superiors, and the cycle time for data to pass from his (yes, his) employees, to him, then he processed by him on his desktop and sent out to his peers etc was at least a day usually a week.
So there was plenty of time for him to arrange things in a single "document" called a spreadsheet, and maybe update a memo on Wordstar and send that via the typing pool etc etc
But the cycle time is now down to maybe hours if not immediate - and if the company is doing its job right in automation terms there is no need for manager to send out his documents - the data is in several warehouses already.
The desktop metaphor is as dead as middle management.
Want a new metaphor - look at Jupyter Notebooks - that's a layer on top of the existing data - kind of like middle managers were on top of their employees.
Personally, after all these years, I think the desktop metaphor is still ingenious. When I watch kids using it, and touch screen phones and tablets, it's pretty amazing how fast they get it.
I didn't read the the article but from others have said here they didn't offer a better one.
While I kind of like the idea of fragments, and them being universally searchable, IDK: it sounds like a pluggable search engine is what that OS needs, more than rethinking the FS.
Search is great, when it works. When it doesn't, it is frustrating. Github's file search regularly fails to find some files that I know exist (one of our YAML files at work, in particular, is invisible; I've learned to just not even try). "Shell" won't find the sea shell emoji in OS X. "sea" will. "Place of Interest" (the command key symbol) is also similarly frustrating.
> who cares, disks are big, save it all, forever
Except they're not. Laptop's preference for SSDs means my work laptop has <300 GiB, which was full within a year.
MacOS specifically does terrible job at visually managing apps.
I frequently end up with a bloated dock with a ton of icons signalling that the app behind them is open (the little dot on top of them).
When I close all the windows of an app why on earth does the app stay open? Why do I need to have Powerpoint open in the dock with no Powerpoint windows open? Especially today that we have SSDs and fast processors that can launch an app within a couple of seconds?
If an app needs to run in the background without UI, there is the menu bar for them.
Linux and Windows have much more rational UX regarding desktop usage.
It still might be doing something. Mail, for instance, is sitting there occasionally checking for new mail even if you have zero windows open.
And I dunno about you, but my 2017 Macbook Pro still takes a significant amount of time to launch Big Serious Apps with a ton of plugins. I like being able to tab over to Illustrator and hit command-n and be fucking around in a new canvas with absolutely no waiting. We have virtual memory, open apps in the background doing nothing but waiting around to be used will get frozen to disc, then get restored a lot faster than they boot up. I generally hate it when apps auto-close themselves without asking when I close the last document like Windows tends to.
And that's a terrible abstraction that, for some reason, happens for any application, whether they have a background job or not. System tray + taskbar is miles better.
I also rarely use the dock (unless I'm forced to — e.g. to navigate to the freakin' Trash/Bin folder) but that's separate to the point of applications staying open even when all their windows have been closed.
Wish the dock could be disabled completely. I have it set to the smallest size and hidden on the left side, but it still gets triggered occasionally. Having it standard size and chewing up space at the bottom of the screen seems insane to me - what a waste of screen real estate.
Like you, I use Cmd-Tab to know what I have open (and you can obviously Cmd-Q while there to close apps) and Cmd-Space to open apps. I never use the Dock or the grid of icons view or any equivalent (not sure what they're even called).
I don't have a mac anymore to check but there was a magic pref that I set from the commandline to adjust the auto-show delay. I set it to something like 10s which made sure that it effectively never appeared by accident. If you really don't want it I assume you could set the delay to a couple of hours.
The UI only offers a big red X button. You have no idea what it does, until you click it. Maybe it will close a window. Maybe it will close the last window leaving the app running in the background with no UI. Maybe it will quit the app.
In KDE/Gnome/Windows you know what the X buttons does. It closes an instance of an app. If it happens to be the only instance of the app, it will close the app as well. You don't have to babysit the open apps.
For the very few exceptions that an app needs to run in the backround, you will be notified that by pressing X the app will go to the taskbar.
MacOS also has a taskbar for apps that run in the background, but it also has apps running in the background in the dock. It made sense a decade ago with the slow hard drives, now it is just a peril of the past. Similar to the C drive in windows.
And it never leaves the app running with no UI either, because the menu is part of the UI, and it's still running.
This is probably not obvious if you're not used to macOS, but that's a bad reason not to do things this way IMHO. It's completely obvious to me.
The red dot closes windows. All three coloured dots are window commands.
Not that I use them much, I use Moom for window sizing and Cmd-W to close windows and tab (Shift-Cmd-W to close a window full of tabs). But that's just me: the dots are there if you want to use them, and what they do is completely consistent.
You're not used to what they do, but that's not the same thing.
Some apps definitely do behave the 'closing the last window closes the app' way, although this is obviously bad from a consistency point of view.
> the menu is part of the UI
I would argue that that global menu is not part of the application's UI. True, it's application-specific, but it's very easy for a novice user to miss the context switch and just be left with the impression that the app is some kind of 'phantom'.
It's not really up for debate, the menu is part of an application's UI in macOS, that is, part of the Interface which the User uses to interact with the application. I assume you're right about a novice user, I haven't been one in many years.
That's why the name of the application is always directly to the right of the apple icon, that tells you which application is in focus, and all the menu items next to it are application-specific. The global part of the menu is just that apple icon, and the menu tray off further to the right.
Can you point me to an example of a macOS app which closes when the last window is closed? I literally can't think of one.
I'll let it go because it's not a very interesting debate and it's not the main point anyway. I haven't been a novice user for ~10 years, but I can still remember what it was like moving from Windows to MacOS — quite confusing!
> Can you point me to an example of a macOS app which closes when the last window is closed?
Most apps that close when the windows closes are not document-oriented apps. For them, there is only one window and one function. The calculator app you mention is a good example. Once you close that window the app has no other purpose it is setup to auto-close the app.
Document-oriented apps expect that, after you close the document, you might want to open another one or start a new document.
This isn't just a difference in UI, but also in the way the OS handles processes. Under macOS, the vast majority of programs host all windows under the same process. In other words, windows do not represent instances of apps, even under the hood. You can spawn additional instances of an app with the terminal, which will give each instance its own dock icon, menubar, and set of windows.
So shifting window closing behavior to function like that of Linux or Windows would actually require a much more fundamental change than it might seem.
The Apple HIG says there's a difference between applications and documents. An application might have a bunch of utility windows but those are hidden unless the application is in the foreground. So an application with no open documents running in the background isn't visually cluttering the screen. Application launch tends to be (and definitely used to be twenty years ago) pretty expensive in terms of resources. So leaving an application open without documents tends to make opening new documents faster.
The red button on windows on macOS is meant to convey the action is potentially destructive to the window's contents. Even if the "destruction" of a utility window just means it goes away. It's not tied to quitting the application, with exception of single-window applications like System Preferences, for the above launch cost reasoning.
This has all gotten muddy over the past twenty years. The App Resume/Restore feature in Lion (peak Forstall) is terrible and I disable it on every Mac I use for more than a minute. I can see it being helpful for some people but it breaks the way I expect the system to behave after using Macs for 30+ years.
As a user of Macs since 1984, I love that most apps now save ongoing changes and document state so that I can close most apps and restart them later with the same document reloaded and any changes automatically saved. Documents are closed when I am done with them.
What you say makes logical sense, but I share some of the OP's frustration, and it was particularly confusing when I started using a Mac, having come from the Windows world. Heck, if we're being really logical, why isn't opening stuff the exact opposite of closing stuff? If that were true, opening a file would do nothing if its application weren't already running — and I don't think anyone wants that.
The specific use case, which I do fairly frequently, is to Cmd-W the last open window and then Cmd-N for a new document, or Cmd-O to open an existing document.
When I try that on Windows, the program closes, and I have to re-launch it. I daresay that's more annoying than discovering that a program hasn't quit when you think it should have.
Yeah, I see your point. It really was about initial expectations — now I'm used to it, it's fine, but it was incredibly confusing coming from the Windows world ("why's this application still open? i can't even 'see' it, what's it doing?")
Where do you type Cmd-N/Cmd-O "into" if you just closed the last open window? I am not aware of macOS continuing to give kbd focus to an application with no open windows, but maybe I just don't use macOS enough to realize that it works this way.
Well it depends on the program you are using but programs that follow a document-style layout usually allow you to close a document without quitting the program (in the File menu or Ctrl-W).
The big 'X' will always quit the program though as that's what the user would expect. Imagine Chrome/Firefox's big 'X' only closing the current tab (is that how it works on a Mac?).
An interesting sidebar does Mac handle swapping out applications better than Windows/Linux do? Both have a history of becoming unusable. I also suspect its more common for more expensive Mac machines to have more than minimally adequate RAM whereas many cheap machines are often sold with barely enough especially historically.
Someone who cut their teeth on other platforms may regard the death of an application with its last window as an essential part of their machine staying usable.
I don't know if you ever owned one of those really old windows ce devices but in a certain era it had the delightful workflow that closing them didn't kill them and after a while you could open as many applications as memory could hold and you would need to go into a different menu entirely to close unused applications or you couldn't open anything else. Like the worst of both worlds.
>MacOS specifically does terrible job at visually managing apps.
I'd say that Windows traditionally did a terrible job of allowing applications to have multiple documents open at once and visible on a large monitor.
The traditional Windows Multiple Document Interface UI was a nightmare if you wanted to have more than one document (especially documents from more than one app) visible at once on screen.
I do not follow. I have two excel documents open. Each is presented to the user like an independent excel app. So in my windows taskbar there will be two excel icons stacked. If I hover I will get a quick preview of all of the excel instances that are open.
If I close one document the excel instance that is running that window will close too. The other instance of excel with its document will remain unaffected.
Have you not noticed all the comments complaining that Macs see closing a document and closing a program as two separate things, while Windows still does not?
Edit: It wasn't until Office 2007 that some Microsoft apps (but not others) started breaking the Win32 MDI UI.
I remember feeling fancy as a teenager when I implemented MDI for a Windows application. Likely an HTML editor. Probably in VB6, maybe VC++. I just did it because I could and now I wonder how many big corps also did that because they could.
> When I close all the windows of an app why on earth does the app stay open?
Apple agrees and indeed many of its first-party apps work like that. Close the last window in Numbers, Keynote, Preview, and the app will disappear from the Dock.
This is opt-in by the app for compatibility reasons, and Powerpoint has not opted in, perhaps because there's no obvious benefit to the app for doing so.
The idea is that windows are documents, not the whole application. You can close all of the documents. Then you can start a new document, open an existing document or quite the app.
Someone who has worked with Macs for a while will just close the app with CMD-Q or use the menu. It seems weird to have to close the individual documents to close the app. Many of my apps are setup to reload the same documents when the app restarts do quitting the app doesn’t abandon the documents, it just files them away until the next time the app is opened.
There are non-document oriented apps that only use one window and when that window is closed, they are setup to close the app.
You obviously spent a long time on Windows where the windows were the app and closing the window closed the app. Documents are secondary.
I've thought about this a fair amount and have a working app/os that shares a lot of underlying ideas with this article here are my additive thoughts:
I'm building a ui from first principles, ostensibly in 2012 it started as an itch to scratch because I found that no note taking software met my needs, the way people used email sucked, jira et al sucked, and I couldn't wrangle non-nerds into interoperating with me on emacs.
Instead of the computer as desktop or some other abstraction I started with an interface predicated on the idea that reality itself has 3 first class citizens: Time, Space/Structure & People/Minds.
As an organizing principle applications are just metadata on data structures (_App_tributes on a node if you will) in the same way a function is a file in a directory or hosted on a cloud service. "Data first" happens when you get rid of the "container"/desktop metaphor.
First Class:
Nodes, People, Time
Second Class Enablers:
Namespaces, Fragments, Timestamped Messaging, Specialized sub-interfaces
The reason projects like chromebook try to hide or delete structure is because App based interfaces are more conducive to advertising and because people use APP as a visual reminder of "functionality". A person or org must have complete "write" control of their data if they are using a first class data/structure interface (MS Word can't have in doc advertising), apps are a weird abstraction that make it easier to sneak "ads" into your workflow.
I am nearing 80% of my time in this interface, the plan is to have a consumer friendly note taking/sharing app (the best damn cross platform note taking app) that becomes the core UI experience to replace existing OS interface in future. As an aside, I muse that the way computing evolved from TTY interfaces created strong adherence to single line CLIs and software engineers never really overcame that, and that's one of the core oversights of human interfaces in computing.
I also find this interesting. Should the data structure really the primary entity though? One can imagine the same data being organized in different data structures with different performance characteristics, functionality, etc. What if an App node wants to alter the data structure. Any other App node that is dependent on the data from a different node will then have to be rewritten.
What one wants is the ability to query the data of another program and send external commands to that program to alter the data. The data structure itself is somewhat irrelevant, don't you think?
Not some bad ideas in there, but it suffers a bit from not taking a universal perspective on computation.
The flexibility of computers means you don't have to try to come up with one thing that works for everyone. Something different can always be implemented for those who want that something different.
The article would be stronger if, in addition to prescribing some macro ideas, it grounded them in a first attempt at implementation. For this new type of non-desktop computer focused on tracking fragments in an air traffic controller model ... where is the code?
The idea was that the main element of a computer shouldn't be an application but a document... and a document is a composite of pieces like spreadsheet, video, etc.
At the time, the idea was to have an open standard to replace the Microsoft apps... and to be able to replace MS apps with any other, piece by piece. It didn't work out then but, in a way, we now have a kind of open standard to build composite document (even including applications inside): HTML (with javascript).
Maybe it could be a good time to give this idea a new look?
I see some analogues in Sandstorm.io, for the web: they’re self-hosted web apps, where instead of the app being the atomic unit, each document (“grain”) is separately managed by sandstorm, and there’s a separate instance of the app running for each document. It pulls things like security and access control up a level, and will have even more benefits as sandstorm grain management matures.
We have rethought the computer 'Desktop' as a concept and it is what we have with Android / iOS and it consists of two separate launchers.
The Applications that run on these devices also generally use a paradigm where they don't really store files but really store objects which can have Hierarchies. They do have search and some of them support a stylus as input.
Another aspect is the ability to use your voice to interact with computers which is still quite limited.
VR looks like it may offer something different eventually but it will have to be explored more.
The problem with replacing the computer 'Desktop' as a concept is that it generally is extremely hard to replace. It looked like a combination of a stream of information with the ability to search a stream or separate streams could have replaced it but we only see this in web applications (a good example is Facebook or Twitter).
I agree with most of these complaints, but only if you're speaking purely about MacOS. Everything is fine on Windows and Lubuntu (I use all three more or less daily.) Only MacOS treats my every instruction with either helplessness or malicious compliance. I think the author should try a different desktop before they give up on desktop computing entirely.
Fun fact: in Windows, the location of the Desktop is dynamic and can be changed via SHSetKnownFolderPath. This allows you to display the contents of any folder in the desktop.
Years ago I made a gadget that sat on the top right corner of the desktop[1]. It contained a stack of buttons, one for each folder that I was working on. You could add more folders by dragging them on the gadget.
It's liberating not having to keep a file explorer window to access the current project, and you can easily access it with the Windows+D hotkey that minimizes/restores all windows. Use it to open files, or drag stuff to/from other open applications.
Reminds me of Deskmate (on the Tandy 1000) which allowed you to choose a current directory. It would display files in the current directory under the icon for the relevant program.
What happens (on the desktop) when you have too many files to show? Many of my 'working' folders have 1,000s of files.
Personally, I have the complete opposite strategy:
Using Windows file/folder security, deny yourself access to your own 'Desktop' folder. Not only does doing this prevent you from lazily dropping/saving files onto it, it also has has the added effect of hiding ALL the desktop icons, so you end up with 100% clean desktop.
My main uses are writing software and reports, none of which creates 1,000's of files under the main folder. So I guess my gadget would not be appropriate for this use case.
> Not only does doing this prevent you from lazily dropping/saving files onto it
That's the thing, it's only considered "lazy" because it's faster but the files end up in a disorganized location. By pointing the desktop somewhere more useful, you get all the speed benefits without the disorganization downsides.
You do have to weight it against your love of your wallpaper, though.
God, I do not use my Mac in any way resembling this hell of URLs and meme gifs that this dude is complaining that it is badly suited for.
And if I wanted to hide the Preview window full of my porn for a video call (I'm assuming that's why he wants to close that Preview full of a bunch of stuff), I'd just hit f3 for Exposé or whatever they're calling it this year and switch to the desktop I keep tedious public-proper work shit on and leave Preview where it is.
Okay, I'm dating myself, but when I was in grad school, there was a campus computer store, and they gave out a little pamphlet: "Do I need a personal computer?" It listed a number of pro's and con's, but the message that has stuck with me is this one:
Don't expect your computer to organize you. If you have a messy desk, you will have a messy computer.
Decades later, I have both a messy desktop and a messy computer. I think there is something about personal organization that, if it eludes you, it will elude your computer too. I've made peace with the fact that I will never be a hyper organized person. The best thing I can do is to put my stuff somewhere and hope that it's searchable.
I'm incredibly annoyed by needing to think about where my files are, at all. It shouldn't matter. All I should need to do is tell how many times I want a file replicated on my personal device network, and optionally tag it.
Well, steps were made in exactly that direction, with ReiserFS and Microsoft was working on the same thing around the same time in the Longhorn days (called WinFS).
For some reason it never took off. ReiserFS was abandoned when Hans Reiser killed his wife but Microsoft also abandoned it with no (known) killings involved. Something must have not worked out.
It's a very interesting idea to revisit though. I do still think there's merit in it. Probably part of the issue was how to make it work gracefully with legacy apps.
However in this kind of scenario you totally absolutely want to tag it with multiple tags. Otherwise this'll become a haystack you'll never find anything back in. I bet this was another issue surrounding implementations.
I have all the stuff I work on on my desktop. When that gets full, I move everything into a folder "Old Desktop" which I place on the desktop. Of course this isn't the first time I did that. So this folder contains a chain of many such "Old Desktop" folders :')
It leads to interesting discussions sometimes such as "why do you have a 200GB roaming profile???". Organisationally though I can find stuff back really easily. While I traverse the chain of "Old Desktop"s I see other documents from the same timeframe which brings me back really easily.
In fact more organised people are often surprised how quickly I manage to dig up ancient stuff for them. They tend to lose track of things over time, probably when they move to a new PC or file hoster or whatever. I've really become the "Do you still have that inventory from 2007?" guy at work. I see no reason to change it at all.
I also found that the best system is having the first layer of folder organization be "which period of my time is this from?".
Conceptually, it's easier to think of "music from high school" than about the specific mix of subgenres from my playlist back then. Same for documents that I saved. Those ICQ logs from high school are there. They don't belong in the same folder as the stuff I wrote yesterday, even though they could be of a similar nature.
I have a command line tool `today` that creates and enters a directory based on today's date. Anything I do today goes in `today`, and I don't have to see yesterday, but it is easy to find. I wish my desktop were like that.
The desktop is broken not because of the file/folder paradigm but because we stopped using files to represent information. Figma, Slack, and Notion should save their information to disk. You should be able to open a Notion document, or a Figma design, from your desktop, instead of through their Web interface. You should be able to save a Facebook post or Tweet and their replies to disk.
Why can't you? Well, for one, social media companies don't want you to save stuff locally, because they can't serve ads with local content. Furthermore, browser APIs have never embraced the file system because there is still a large group of techies who think the browser should be for browsing documents and not virtualizing apps (spoiler: this argument is dead and nobody will ever go back to native apps again). Finally, the file system paradigm fails with shared content; you can't save a Google Doc to disk because then how can your friends or coworkers update it? It's much easier for Google to store the data on their server so that everyone can access it instead of you setting up some god-awful FTP-or-whatever solution so that your wife can pull up the grocery list at the store.
I'm hoping the new Chrome file system API will bring a new era of Web apps that respect the file system and allow you to e.g. load and save documents off your disk. However, this still won't be good enough for multiplayer apps, where many devices need to access the same content at the same time. I don't know if there is any real way we can go back to the P2P paradigm without destroying NAT - WebRTC tries but WebRTC itself resorts to server-based communication (TURN) when STUN fails.
> The desktop is broken [...] because we stopped using files to represent information.
This is it right here. Our entire world and notion of the internet is based on serving data stored in a file from one person to another. Once the developer started drawing too many conveniences and started to "move fast and break things", we thought it's good enough to just store everything in a database, or serve it as Javascript. These technologies are great, but they go completely against everything our computing paradigm stands for.
The file system is nice because it's the same database. I don't want all my programs to do their own database, since then how do I search and move stuff in bulk?
A local database will store data in a file, but I get what you're saying. Files are a common interface that allow you to pipe data around, keep it portable and malleable.
No, but all your programs can/could share the same database, and you could cross-reference anything whenever needed. At least that's how I manage it. I have a single postgresql database with per-program/per-instance schemas.
I just did my taxes and figuring out what to pay was just a single select over some tables in the paypal and various per-bank schemas + a schema that had a table of currency conversion rates from our central bank applicable for each month of the year for tax purposes, expected by the tax man (or woman). Quick and easy. I don't even bother with UI, for these once or twice a year needs, just like I wouldn't bother with writing UI for some mp3 conversion task. Just a simple script will do.
Filesystem is great for arbitrary data/files with no schema. Random pdf files, code, programs, etc. But anything that has some obvious schema and comes in large quantities and perhaps needs to be modified/synced with third party data source, I like having such things in the database. It's so much more useful that way, because it's much easier to do something with the data.
Yes. One with a generic schema, and to which the user has full access rights.
Fundamentally, it's not the files that make filesystem great. You could devise different models, perhaps a relational one, and paper complexity over with well-designed UIs. They'd probably still be more complex than the filesystem - files are about the simplest data storage abstraction you can invent[0] - but they'd be serviceable, and users would learn.
What makes the filesystem great is that it's an old abstraction, designed in the ancient days back when computing was still about enabling users. Bicycles for the mind and all that. People cared about making things useful to users, instead of just shamelessly exploiting them. So, designed back then, the filesystem grants users the vocabulary to manage their data and freedom to do so, and it's so ingrained that - despite their best efforts - companies weren't able to completely take it away.
Filesystem persists for the same reason e-mail persists. Despite its warts, it's one of those technologies made before the computing industry became exploitative.
--
[0] - Despite the frequent claims to the contrary, coming from the web and mobile world. But guess what, data magically held in app and "shared" by magic isn't easier to understand, it's just not understood at all - users have no mental model for this. The mobile app approach works only because it removed all data management features except the share button.
You are missing the point here by seeing only the technical aspect. You are misleading technical description with abstraction.
A database is hardly if not accessible to the user. The files are an abstraction that enables the user to owns its data. Once you have a file, you can do more than opening it in your app. You can store it wherever you want, edit it with any software you wish, arrange it the way you are confortable with.
As a user, you can’t do that with your SaaS database, you must rely on the « export / share » function of your SaaS provider, hoping it will export all data, in a readable format and that the import function exists and is reliable. You don’t own anything and as soon as you stop paying your subscription, you are stuck with nothing.
File formats like DOCX or PSD (fitting extension) are almost impossible to parse 100% correct and render without the (hired) software used to create them. While you may be able to copy your files, without the software they are quite useless.
You are right and it's a real issue, but you can share them with whoever you want, however you want. You can just keep them and be pretty confident that they will be readable again in years : even if it could become difficult as the time passes, if it is nothing too exotic, chances are you will be able to at least read them.
And I prefer a "95%" correct DOCX or PSD that I can recover and rework if needed than a "0% this App is not available in the WhateverStore anymore".
For popular formats that would be possible, but there are a lot of binary only formats that are completely impossible to parse these days. You're free to copy it but the bits are essentially useless.
Try to load a current ML model 20 years from now. Probably tied to proprietary software and if you're unlucky also hardware (like CUDA)
Perhaps the concept of file needs to evolve from a locally stored collection of bytes to a more generalized notion of locally identified collection of bytes, data links, and functional relations. All that should also have an ability of become fully localisable akin to 'clone'.
By now the spectrum of interactions using computers is visible enough to be able to generalize such meta-file formats. Should it be some form of database or a kind of system-level support for defining and assembling such meta-files is a question of experimentation.
It's more like an active-book paradigm vs a file, where one could tie together multiple contexts, yet being able to present it to user in some human perceivable form. Some analogies could be a project or an activity based collections of files, links, collaborations etc.
> allow you to e.g. load and save documents off your disk.
Isn't this trivial? A download button = "save" stuff from the app to disk. An upload button = "load" from disk to the app. AFAICT, webapps can already do this via existing file API's.
This isn’t the same: download/upload can be used to simulate a file system, but they don’t preserve file identities in exactly the way open/read/write does.
> spoiler: this argument is dead and nobody will ever go back to native apps again
I think in the world of app stores this is a little odd to argue. Native apps on the desktop do seem to be on the way out, but less so on tablet and mobile phone.
Most of my work is in native apps. It's just a better experience. The browser is great for communication, and it really shines for text based communication, but in my experience that's the only place where it outshines native apps. And remember, it's not like native apps can't back things up to the cloud, so there is a false dichotomy that you have to do everything in a browser that you want backed up to a cloud. I have no problem working with IntelliJ products and then pushing to a remote repo. My Photos, Music, etc are backed up to iCloud but aren't viewed in a browser either, etc. Zoom is launched with a browser link, but it opens a native app. MS Office has a cloud drive and is even sold as a service but I use the native Excel and Word rather than in-browser versions. I just don't see this migration to browser delivery for the apps I've been using.
It's 2021, people really aren't using the App Store like they used to, imo mainly due to the insane rise of subscription based applications for things as small as calculator apps
I don't think that writing a native app using Electron qualifies it as a web app. VSCode is not normally used from the browser, it is downloaded and used more or less fully disconnected from the MS infrastructure you used to download it (give or take some plugin updates).
I'd argue that in recent years, most people can't tell the difference between a native Swift app on iOS and a Kotlin app running on a midrange Android phone. I agree that Apple's approach is more technically correct here, but Android's approach is also pretty sustainable.
I think those are both the native app targets of their respective platforms though? The Kotlin app targeting Android APIs is not cross platform. I gathered they were more drawing a comparison between native and some HTML/JS/CSS thing.
Ah, so this takes us into the question of what "native" means.
Some people use the word native to mean "the way apps were written in the 90s and on Apple platforms, still are written". It's short hand for manual memory management, full commitment to the operating system vendor's APIs, and so on.
Apps written that way have some big advantages for end users - consistency, low memory usage, and so on. But they suck for developers. Manual memory management sucks, having your app market share be limited to the operating system's market share sucks, often the vendor APIs suck.
Some people use the word "native" just to mean "uses the operating system specific APIs". The other aspects like being written in an AOT compiled manually memory managed language don't count. For those people Android apps written in Kotlin running on a JVM are native, but the other people, not so much.
There is lots of good thoughts in your argument, but I disagree with the "should save their information to disk".
This may make sense for technical people with a specific goal, but for most users, they shouldn't care where it is saved, ala dropbox. They just want to access their files. Online, offline, everywhere, that's what they want.
It would be nice if they didn’t have to care where the information is stored. And maybe that is the case 90% of the time. But that other 10% matters a lot and I don’t see that changing anytime soon.
> but for most users, they shouldn't care where it is saved, ala dropbox. They just want to access their files.
Yes, but it does matter where it's saved, because the location and method confers ownership of the data. "Possession is nine-tenths of the law" is the rule of modern Internet. It shouldn't matter whether my photos live on my drive or in a third party's cloud, but it does - because in the cloud setting, the company dictates what I can and cannot do with my data, can pull shenanigans like applying strong lossy compression to uploaded photos, and they will eventually take my access away - either I cross the ever-expanding terms of service somehow, or they'll just go out of business.
In my experience of both managing my own data and helping non-tech people, filesystem vs. cloud data durability is really a wash. People seem just as likely to lose their local data due to drive failure or accidental deletion, as they are to lose access to the cloud storage (or have the company disappear from under them).
> Well, for one, social media companies don't want you to save stuff locally, because they can't serve ads with local content.
This i do not understand - mobile and web content has easily been monetized for a long time now, why would desktop software be any different?
For example, i use software called RaiDrive for mapping network drives on Windows (https://www.raidrive.com/). In their free version, they show ads on the main app window after you open it.
Why isn't this the norm on desktop - ad supported but free software? Why aren't there ad networks for desktop apps like there are for mobile apps and web content?
How would Facebook guarantee you use their app to look at their stuff? If the answer is "some proprietary format that only the app can read" then what's the point?
> Why aren't there ad networks for desktop apps like there are for mobile apps and web content?
Good lord, please, no. Desktop adware should remain a bad dream from the 90s and early 2000s. It ruined software like Opera, and was often bundled with spyware.
I'm glad advertisers mostly embraced the web, where I can run their code relatively sandboxed and easily block it. A desktop app has much less restrictions over the resources it can access, so allowing software that actively wants to track and manipulate you to run in that environment doesn't seem like a good idea. The fact it was acceptable in the 90s with the complete lack of security of the popular OSs of the era is a bit nutty, and while modern OSs are much more secure, I still wouldn't run anything ad supported. F/LOSS or paid apps only for everything under my control. Subscriptions are tolerable in some cases.
> It ruined software like Opera, and was often bundled with spyware.
Wait, I hate ads as much as the next person, but how did they ruin Opera? Opera was originally trialware-only, then for several years replaced the trial with an ad-supported version (with the full version still available for purchase), and then became entirely freeware.
I suppose the nuance of "ruined" is down to personal preference, but I was annoyed by the large banner ad placement and stopped using it shortly after they added it. Purchasing wasn't an option back then for me.
This was also done in other software like Go!Zilla and it made the UI unusable IMO. It was a very disruptive and obnoxious way to monetize a project. Not sure if they improved this later before the move to freeware, since soon after I switched to Phoenix/Firebird and never looked back.
Right, but if you couldn't purchase it, Opera wasn't "usable" prior to their ad-supported version either - it had to be purchased once the trial ran out.
Oh, I'm not necessarily advocating for it but the reasons behind it seem interesting, whatever they might be.
Is it a matter of differences in cultures, that people don't seem to mind ads as much online, or perhaps there'd be backlash from OS app distribution channels, were devs to attempt to monetize software in the Windows Store for example (I don't really use UWP apps so no idea), or perhaps it's something else entirely...
That said, I feel like the option not even being there is limiting in of itself. Suppose I'm a developer who wants to create software that's free to download and use, but ad supported. Now I cannot possibly do that. As for those who would prefer no ads, there would always be the possibility of a paid version with no ads, the possibility of altering the hosts file to block ads, or possibly downloading the source code of the app, removing the ad integration code and compiling the app themselves.
Though there are also interesting technical aspects as well, such as us not being able to sandbox most native apps (short of AppImage and Flatpak as well as Snaps, but even then there are other challenges), which may contribute to spyware in desktop apps. Plus I bet there's a large difference between showing an ad in an app and being able to mess around with the OS default browser settings and so on...
> Why isn't this the norm on desktop - ad supported but free software? Why aren't there ad networks for desktop apps like there are for mobile apps and web content?
My guess is because the desktop model doesn't assume live internet access. My understanding of ad networks is that they involve a live bidding process against interested parties at the moment you load the page. This allows integration of live geo data, what you just searched, what you just looked at previously, etc. And you don't need to reconcile what was served if an app goes offline then rejoins for charging the advertising account.
> this argument is dead and nobody will ever go back to native apps again
I agree with your post in general but not this. I see a lot more interest in self-hosting stuff lately, precisely because of the concern you mention that online services do ads and tracking. More and more people seem to be doing this.
And I personally really prefer native apps over web apps or electron stuff.
When self hosting is as easy (for your grandma who likes cats) as downloading a container from the Windows Store and double clicking it to open, install and start the server. Then we've truly made leaps and strides in fixing centralization.
Self hosting is hard because ops is hard [1]. People aren't yet in the mentality that you should provide an official modular deployment every time you provide a server binary. Everything-as-a-container wouldn't be the worst way to take the desktop [2]. Isn't that kind of how Apps work on OS X?
[1]: The ironic part is that most people don't keep anything long enough for a hard drive or any other component to fail anymore. So the argument about the cloud abstracting away the physical hardware maintenance for every day consumers like yourself or I is ... dubious.
[2]: Yes.. I just spent the weekend learning nix-build. Goodness, it's super easy to container all the things! :) I'm feeling like a zealot when I start using nix to do what I could have done with a zip file. But there's something magic to having a zip file of assets with its own shell.
True, I was mainly thinking about the HN community (and the more technical people around me) instead. This is not for my grandma who likes cats (PS: So do I!)
Yes this is kinda how apps work on macOS, but not all apps yet. The new sandboxed container model isn't mandatory yet. Some apps are just a folder of files with no kind of containerisation at all (other than the .app itself being a folder rather than a file). More modern apps store all their data in a containerised filesystem though.
It leads to some cool things you can do like easily capturing the icon of an app or even changing it without having to change the app itself.
But on the self-hosting side, docker is making big strides there. Almost everyone deploying something like Home Assistant for example will do it through a tree of managed docker containers, in many cases without even knowing it :) It comes with a supervisor (which is also dockerised) which manages that part very well.
I think most consumers I know keep their computers for long enough by the way.. Phones come and go, but desktops and even laptops tend to stick around until they do break and I can't fix them anymore or just heave a sigh and go like "NO this time you really have to get a new one, Windows Vista hasn't been supported for years"
> But on the self-hosting side, docker is making big strides there.
Docker is only part of the puzzle. Even being proficient with Docker (and running services in a traditional way), there was always a big barrier to self-hosting for me in networking. If you lose all of your cloud-equivalent functionality once you leave your home network, it isn't a realistic alternative. I'm not a network whiz and the builtin VPN functionality of my NAS is sadly not up to par either.
In comes Tailscale[0], which made it dirt easy to self-host my stuff and have it available anywhere (given there is a Tailscale client for it which has been the case for all my devices). Since I started using it, I've completely migrated my contacts, calendar, zettelkasten (Trilium) to self-hosting and started some home automation projects. For someone who tried and was stuck at the networking part in the past, it truly is a game changer (and I'd like to think I'm not the only one that is held back by that).
Self hosting is hard because we are limited by our ISPs and what they allow us to do with our connections. Why don't they allow people to self host and when traffic starts to get big have an option to migrate that data to the cloud instead of clogging the municipal pipes if that's really the problem. The way companies like Comcast and DSL providers can succeed in this arena is to make self hosting easier. Why do I as an end user need to understand the infrastructure when all I am trying to do is share data or information?!?! I am playing the role of an uneducated user here and not as a Software Engineer as a career. It's disheartening that basic things like this aren't solved for people on the ISP level. I should have to find a service like Weebly or, DO or AWS, etc. I just want to be able to share my info and my ISP at the very least should be able to provide the basic framework for me to do it. When my content becomes populate then adjust accordingly.
I don't think that anyone self-hosting is able to make a single dent in the consumer internet infrastructure. Usually when you're self-hosting I guess you're handling either just your friends and family or perhaps at most up to 1000 strangers that follow your hobby.
Hypothetically in a future where self hosting is non hostile, will you see people self-hosting startups and the like? Yeah, maybe feasible. I think at that scale you start to care about things like uptime and maintenance. But I think the biggest winner to self hosting is the photographer who saves $5/mo on the blog that people rarely read or the kid who doesn't have to pay $10 to play Minecraft with their friends, or the family friend with 2TB of family data that doesn't want to pay $20/mo for Dropbox or the like when they already have the hard drive to store it. Yes it needs to be simpler for these people! There's a whole economy in making it difficult for these!
" I think at that scale you start to care about things like uptime and maintenance."
I guess none of members of your mentioned groups will ever grow to care about a scale. And thats a good thing because they are distributed. And i think it creates a better internet, which is kind of wide network instead of shallow graph of couple mega nodes.
The biggest win we could achieve for self-hosting doesn't involve people actually self-hosting. The idea of personally maintaining your own infrastructure is unlikely to scale to general population - but the thing we're really after is ownership of data and the ability to own infrastructure.
So, I think, the ideal situation would be to have a combination of big and small companies offering storage and compute as a commodity. You'd pay a fee to keep your stuff hosted somewhere; any time you see a better offer, you can migrate to a different provider without much hassle, and with near-zero downtime. Cloud services would work by shipping their code to your data, not the other way around[0]. And if you were so inclined, you could just build your own infra, or even buy a turn-key "self-hosting in a box" kit.
Pieces of that vision are already here. Compute providers are plenty. You can order "self-hosting in a box" kits. Internet architecture makes everyone's computer equal (at least in theory, ISPs mess it up with NAT, and their T&Cs). The only thing missing is the part where you own your data, and SaaS vendors serve you - the bit that makes SaaS truly be Software as a Service, instead of Serfdom as a Service.
--
[0] - Preferably with homomorphic encryption preventing SaaS vendors from putting their hands in the cookie jar, if we can get that to work without creating another blockchain-level environmental disaster.
You mean good old webhosting?
What I don't get about the HN crowd is making every simple, already existing, already proven, and already solved problem so damn hard.
I'm in EU, I host my websites at multiple local webhosting companies. They're small enough to care about support and big enough to guarantee speedy and reliable service. By law they're not allowed to go through my data (ofcourse they can and I have no way of proving that they did), so the legal deal between me and them is crystal clear. Who do you call when your Amazon Web Shit serverless thingy doesn't work no more?
I can and did move several webapps and websites from one webhosting company to the other. It works flawless. And besides waiting a couple of hours for a DNS change, it's almost instant. I get it, you can't do that easily with a system with million users.
This so called problem was already solved decades ago. It was called personal computers and the internet. When people started calling the internet 'the cloud' then things went downhill.
Excuse me for the slight rant. I should go outside and see some more sun. ;)
Yes, this is solved. I'm saying that there's another problem that needs to be solved too: control over data.
Regardless of what you use for hosting your own stuff, if you want to use a third-party SaaS as a user, they own the data. Want to make a document on Google Docs? That document lives on Google's servers, it's forever tied to their service and mined by them. There's no artifact you can hold on to, other than your user account.
What we need is a system where the data for that Google Docs document lives in a place you control - be it your own hardware, or some hosting you rent somewhere. It's the SaaS that should come to the data, and operate on it there. That way, if you lose your Google Docs account, or decide to edit the document with something else, you actually have that document, in its canonical form. Same for all other SaaS.
In an ideal world, yes. In practice, that's impossible to do up front, so the next best thing would be open formats - i.e. openly and fully documented ones. The goal is to break the leverage a vendor has over the users when using a closed, proprietary format.
> There's a whole economy in making it difficult for these!
And there is your niche right there. Individual companies or persons do not need to make 'dents in markets' all by themself. A host of people doing the same might. But for the individual - especially when having sustainable income objectives, not hockeystick growth - there's a good place in the market I think.
> Hypothetically in a future where self hosting is non hostile, will you see people self-hosting startups and the like?
Huh, is that not a thing anymore for startups today? In my experience, starting in 2003, across two companies, was that if you need any service fast and on the cheap, you're forced to host it yourself. Run your own mail server, web server, DNS, server housing, all the web apps, etc. and of course spend most of the day developing your actual product. Have the hosted options actually gotten so cheap and reliable these days? Is it a mindset thing?
My gripe with the cloud or SaaS solutions I've used over the years is always that management of them and backup is difficult tending towards impossible and without those you can't rely on these services, it's just voluntary vendor lock-in. When self-hosting, your actually (forced to) learn how they work and be able to fix them. Self-hosting, to me, is the simpler, more reliable option, if you depend on a service for your business and it enables you to get it fixed yourself, when it is not working. It doesn't prevent you to out source the work, if you have the money, but worst case, you still have direct access to your property.
With the hosted options, in my experience, you get all these fancy promises on availability and it being the latest, smartest tech and then the service is down for half a day, your data got restored from days old backups (if at all) and there is nothing you can do except tell your customers that "were sorry and working on it" while you wait for it to come back. :-(
>and then the service is down for half a day, your data got restored from days old backups (if at all)
It's not unheard of for the same thing to happen with in-house systems.
The difference is that you may have a wider range of options to avoid and respond to any outage if you run things yourself. That seems to be a rather theoretical advantage though. Every time there's a new ransomware attack, it's always those in-house deployments that are hit hardest and take the longest to recover.
I think under optimal conditions self-hosting is superior. But conditions are rarely optimal. As soon as you have to convince non-technical management to invest in non-productive necessities or in contingency planning you're already in a sub-optimal position.
Self-hosting isn't hard, it's currently impossible.
The real problem is who owns your data. Because if you use Word or Photoshop, your files are locked inside Word and Photoshop. And this is still true if you use FOSS alternatives, because there's only very limited support for metadata-aware sharing between applications of all kinds.
It would be super-useful to have (for example...) seamless links between text editors, web design applications, web hosting systems, and even video editors and ebook publishing tools. But that's not where we are now. There's some limited interchange, but most cross-domain transfers are difficult and fragile, and some are impossible.
Cloud is just the online version of the same model. When you have proprietary control of user data through proprietary file formats which actively frustrate open sharing of data between applications, it doesn't matter of the data is stored locally or in the cloud. It also doesn't matter if you're using a mobile or desktop UI.
The FOSS people have always been looking through the wrong end of the telescope. The real revolution would be open data which is wholly and exclusively owned by users (or user groups for collaboration) and loaned to proprietary software for specific limited tasks.
Which is the opposite of things work now. Applications and products own your data and they let you access it - but only if you ask them nicely. And - increasingly - if you pay annually for the privilege.
So containerisation or self-hosting or whatever is a non-solution unless it also gives data back to users.
Which is also why the fragments idea won't work. There's limited use in trying to automate or manage or otherwise AI-ify access to data that you don't truly own anyway.
In fact a new kind of shared Internet would be a very useful thing. But it would need a ground-up redesign of everything, including browsers, mobile apps, desktop applications, operating systems, search, and the financial and legal frameworks surrounding them.
I'd love to see that happen. But right now in 2021 it just doesn't seem likely.
> The real revolution would be open data which is wholly and exclusively owned by users (or user groups for collaboration) and loaned to proprietary software for specific limited tasks.
How would that work in practice? By its very nature open data would also be accessible to proprietary programs although the reverse need not be the case.
Seems like we will need open data and code. Either one open will not do.
One example for this that i have been thinking of is chat. Instead of having 15 different apps, we should be able to choose which UI we want to use, and then that opens the chat streams. Kind of like email, where you can use any client.
However most big companies would fight this every step as they loose control.
Edit: I envision it a bit like streams of data that you can subscribe / push to. Think RSS mixed with a pub/sub type of model. You would subscribe to the hackernews datastream, and submitting articles and comments are done using push. The push message would have some predefined metadata fields that are obligatory (article url, title, summary or comment text).
This is centralisation from the bottom up! You don’t want this. If everything talks the same protocol, some giant will eventually own the protocol in the same way Google stole the web with Chrome.
Can you imagine if Android licensed iMessage instead of building Hangouts? Yes, we’d all be texting on the same protocol, and yes we’d have a choice of clients, but at what cost?
> How would that work in practice? By its very nature open data would also be accessible to proprietary programs
That is a good thing. If program X works best on my data I want to use it. There are a few examples where people do mix programs from different companies. Musicians use MIDI to connect their favorite keyboard to a synthesizer from a different company all the time - sure it is tied to hardware, but it need not be and is a perfect example of what should be possible for any user data: mix and match.
> although the reverse need not be the case.
It doesn't have to be, but if users demand it, it will be.
> Seems like we will need open data and code. Either one open will not do.
Open data means we can create the code. Closed data is a lot harder to deal with than closed code.
The reason MIDI is a success is the actual data is quite simple. It's just a stream of keypress and numeric control updates. And there's no incentive for a synthesizer manufacturer to block access to incoming or outgoing data.
When your data is complex, the processing done to it will be complex, especially if you need to guarantee invariants (eg. referential integrity or database constraints).
While self-hosting as commonly understood is not for everyone, I really hope and think that small-community hosting as a service will become a thing. Basically there's a number of places like https://syntaxserver.io/ which will host (for example) nextcloud for you. You should be able to get that as a supported service from a local company/organisation/group for a price comparable to what huge SaaS businesses would charge. With the difference that you can move the backup anywhere you want, and your data does not touch other people's data.
Selfhosting these days is actually a breeze with docker.
I don't like using docker for delivery or for deployment of saas, but as a delivery mechanism, it's really great
In reddit, colleagues around me etc. Hacker News posts/initiatives. 2-3 years ago everyone was all "Hey look at my new Office 365 setup". Now the cool new thing is more self hosting, often driven by a desire for more privacy. There's also new businesses around this usecase. Look at https://www.beeper.com/ for example. It's a hosted matrix service but all the bridges containing your private data are self-hosted.
> My money's on your anecdata being 100% from a techie bubble.
Absolutely. But this is where things start before they get mainstream. Things pick up traction here. Then they mature and commoditise and make their way to the mainstream.
> Absolutely. But this is where things start before they get mainstream. Things pick up traction here. Then they mature and commoditise and make their way to the mainstream.
1. Where is the money in that aka is there more money in that than in services?
2. Will it be braindead easy to use?
My money is on no and no so I don't see how the chasm crossing will happen.
>spoiler: this argument is dead and nobody will ever go back to native apps again)
Not with that attitude it won't. Yeah. 90% of tech offerings only work based on monetization and hostage taking of consumer data. Normal people are starting to pick up on this. All the techbros looking to score that hot, sweet -aaS money are blind to it and desperately hoping their market dominance and spend can keep people from digging through the native computing stack.
Need end to end encrypted file transfer? VPN and NFS is your friend. Need chat? IRC, at your service. Also exposable through VPN, so you can limit the audience. Want Doc updates where your secrets and in progress stuff is guaranteed to not get pored over by some intern or Admin somewhere? See above. Want no bloody ads and not to be snooped on? Set that stuff up homey. I've got a young'un whose mind is blown away at the fact games used to even exist that didn't need n internet connection.
The desktop metaphor is fine. What isn't fine is the normal person's technical education/on ramping. The old approach was teach programs first, then the protocols and problem classes they solve. Now it seems to stop at just teaching programs, because there is so much out there that is doing the same exact thing, but different branding, there's never enough time to dig into what is going on under the covers.
I use IRC; it is good. I also use NNTP is also good. There are other protocols can be good too. They can be good for different purposes.
There is also I can store all of the files on my own computer. I don't need to store them elsewhere, except to make backups. I use DVDs for local private backups. For public files, I also store them on DVDs, but also on other internet services (such as chiselapp), too.
There are many computer games that don't need internet connection. Some of them, but not all of them, are designed for older computer systems such as NES/Famicom, which can be emulated on many computers, so it doesn't matter what operating system you are on, it will likely work.
Better documentation is helpful. Describe the program, the protocols, file formats, etc. This is how to learn working with computer. Other programs doing same kind of things can differ in many more ways other than only the branding though; some have different features, source code availability, etc.
Just.. no. Please stop pushing IRC. It's had decades to evolve and still today lacks really basic QoL things like a good mobile story (always-on connections won't fly, bouncers are limited hacks), permissions, or user registration that doesn't look like an 80s xterm.
Matrix is carrying that torch now. IRC is an evolutionary dead-end that will only ever be used by techies.
> (spoiler: this argument is dead and nobody will ever go back to native apps again)
Ahaha, I don't touch web apps unless I really really have to. And even then it's lighter stuff, like chats. Can you imagine using an actual productivity application in the browser?? No thanks. The thought that Slack/Ms Teams/Discord all run slower than MSN Messenger did in 2005 despite my having a computer ~50x more powerful is depressing enough (and each of them consuming as much RAM as I had on my desktop back in the day!).
> Can you imagine using an actual productivity application in the browser?
I'm not sure what type of applications you're referring to, but if you're including word processing in that, then I can't imagine not using either Google Docs, or whatever might one day come along and be a reasonable alternative. If I'm using a word processor, it's because I want someone else to be able to read and, quite often, contribute to what I'm creating. That is far, far less painful using Google Docs than Pages or whatever the alternative might be.
Most likely. It's not the best IDE but it is likely the best free one. Out of the box VS Code is pretty much good to go while others are either paid or take a lot of config.
I have attempted to use vim but I just can't be bothered working out how to turn it in to VS code. If I have to decide between multiple ways to install plugins with their own tradeoffs, its already too much work when vs code just works.
Photopea is a browser based photoshop; it is very good. VS Code is an electron based IDE, also very good (and there are various web variants as well). There was some kind of high quality online video editor my old landlord (who has a small video production company) used to edit 4k video with his macbook air. I don't know about audio, though I suspect there are more than a few options - yet probably less than for everything else, I'm not sure how good those physical device interfaces are now.
Aa for 3D stuff; it looks like solid works have some kind of cloud platform. How much of the workstation load is there I don't know.
Those are not productivity applications, they are all tailored to specific purposes. The only one that I can say might be considered a productivity application is text editors/IDEs, but even then it's tenuous. No one is going to call Blender or Ableton a productivity application
You can collaborate on office docs in Office365, Teams and Sharepoint. Also, Google will convert Word. Quite a few people and organizations still prefer the richer feature set and combined suite in Office, or even iWork. Excel is still king of the spreadsheet and doesn't look to be going anywhere.
Electron apps definitely have performance issues and I do not defend them. I just also want to make sure we're recognizing that apps like MS Teams are doing a lot more than MSN Messenger did back then. Whether you use/need those features or not, the apps are much more capable. Our computers have gotten an order of magnitude faster for sure, but the workloads they're tackling have not stayed flat.
> I just also want to make sure we're recognizing that apps like MS Teams are doing a lot more than MSN Messenger did back then.
Can you elaborate? MSN Messenger did text chat, voice chat, video chat. I don't see what more features MS teams has that explain the order-of-magnitude increase in footprint.
It's more than one OOM, closer to two. From what I remember, MSMSGS used few dozen MB at most, since typical machines of the time had between 64 and 256MB of RAM. Meanwhile, I've seen Teams go over 4GB simply being idle, and others have reported much worse.
Teams does have quite a few extra features: multiplatform, easy meeting recording, media embedded in text chat (quite useful for my current work), shared editing of Word or Excel documents within calls, sharing of Powerpoint presentation controls within calls, per-channel wiki (a bit anemic, but it's there), pretty extensive Sharepoint integration, crazy extensibility...
The downside is of course that you pay for all of that even if you don't use it.
>Teams does have quite a few extra features: multiplatform, easy meeting recording, media embedded in text chat (quite useful for my current work), shared
I work at Google and I do all my work in chrome, email, chat, IDE, ssh, docs/slides/sheets, etc. I used to use iterm and vim but during wfh I converged all my work into the browser and it's been pretty convenient accessing everything from the same interface.
I know Google is not like most places and that a lot of web apps suck, but when the web apps work well, it's pretty nice, at least for my workflow
I am curious if people would generally consider an editor / IDE a productivity app. If so, VS Code's popularity seems to be more than "many people do", in certain segments, it's the leading development environment [1].
And oddly, if we consider it an IDE (I would, if the relevant extensions are installed for whatever you are doing), it seems to use less resources than most of the others I use on a regular basis, while seeming more performant. It's really an odd app.
Personally I don't view browser based and Electron apps as equivalent. I don't really use any Electron apps, but to me they aren't as annoying as software which run within my browser window.
Sometimes I just close my browser, because to many tabs have built up. I also want a Dock icon, PWAs and Electron apps will provide that and allow normal cmd+tab to work.
PWAs are worse than Electron apps, because they die when you exit your browser. Google Chat is the worst, they had a standalone app, but now it's a PWA. So I either have to have Chrome running (a browser I don't actually use) or a window or tab open with the web-version.
Electron apps are generally fine, from my perspective, they use more RAM and don't feel completely native, but in lack of better options they're completely fine.
Under the hood, Electron is powered by the Chromium rendering engine and NodeJS. So why do you view browser based and electron apps as different? Because you cant see the browser menu bar?
Because they run as separate processes. I frequently just close all my browser windows, which would exit any browser based apps. Electron app are their own thing, and lives outside my browser window. Electron apps also have their own dock icon and exist independently when I tab through my open applications.
That's also why I strongly dislike PWAs, they DO NOT exist independently of my browser. They are very much tied to the browser (well Chrome), which seem illogical, given that they have their own icons/launch thingy and pretend to exist as their own process.
I get that Electron and browser based apps work more or less the same, but I interact with the two types applications in a very different way. That's what I care about, the interaction, the underlying technology is irrelevant.
Yes, I can get behind this argument, it's significantly different from the standard opinion that Electron apps are trash quality in terms of performance. VS Code is generally either seen as a counter to that argument, or as the exception that proves the rule; nevertheless I am frequently left unsatisfied with such arguments. My core point is: the norm seems to be lazily written native apps, to the point that well written Electron apps can compete, assuming that the app is non-trivial. Clearly having an Electron app for a task list is unlikely to be a good idea, but as a core productivity tool that is open for months at a time, it's fine.
Coincidentally, I stumbled upon StackBlitz [1] a long time ago, and was generally very impressed with it. It is essentially a very slick, online version of VS Code optimized for rapid prototyping, or small team projects. I could easily see people working with it as a main IDE. The argument then would be whether your browser of choice provides a nice enough environment for it to rival your OS when it comes to pinning tabs, navigating between them, etc. I would agree that it's unlikely to be an awesome experience, but with some work, it could be good enough. I mean, I guess a large percentage of people use Gmail via the web interface, and what is email if not the quintessential productivity app.
Yes, I want to save the files locally to the disk. I don't use Figma, Slack, Notion, Facebook, Twitter (except sometimes for reading, using Nitter), or Google Docs. You could save the HTML, but that isn't always ideal. Having defined file formats can help, which is the case when using email, NNTP, ActivityPub, IRC, etc.
FTP is no good. There are better protocols, such as HTTP, Gopher, Gemini, Plan9, etc. I had made up a file format for serving directory listings by HTTP (but I don't know how to configure Apache, or to write an extension for Apache, to be able to use it).
About "who think the browser should be for browsing documents and not virtualizing apps", it is badly designed for virtualizing apps. (I have thought of some better ways.)
Also, the file system paradigm does not fail with shared content; you could have the program to mount a remote file system and then access it using local programs, if wanted. (You can then also easily to copy files between your computer and remotely, in this way, by using the standard operating system commands for doing so, and will work just as well with command-line or GUI. Similarly, for SQL databases, you can have an extension to expose remote data as a virtual table, and you can then easily copy data between locally and remotely.)
Not that I disagree with your overall point, but there are multiple products in that space. It's clearly not a deal-breaker for most; but if anyone's lamenting the lack of a GoogleDocsFS, they can get one:
It's probably less that they suck, and more that they aren't designed for the workload the developers want. Files are a good idea when you have exclusive write access to them at any given moment; less so, when you want to support concurrent access. Real-time collaborative creation happens at a finer level of granularity - people are manipulating individual aspects of documents, objects in the application's internal model. This doesn't work well when your atomic unit of synchronization is entire database.
>Sounds good. Where is such program? This is surely not a very novel idea, but where is it?
Every office in the nineties. Windows 95 + Office on the desktop and a Windows NT Server sharing the files. I'm not saying we should try and wind the clock back but it was a solved problem.
I mount a cloud drive containing about 3 TB data on my laptop using rclone and it works great. And the cloud provider does not even have a native Linux client. I am so happy with rclone and will totally recommend it.
> FTP is no good. There are better protocols, such as HTTP, Gopher, Gemini, Plan9, etc. I had made up a file format for serving directory listings by HTTP (but I don't know how to configure Apache, or to write an extension for Apache, to be able to use it).
WebDAV is actually fine for this use case and supported everywhere (e.g. you can enable WebDAV for a certain directory in Apache, map it as a network drive in Windows, and everything will just work).
There are some things that I don't really like about WebDAV, including the use of XML.
However, the HTTP directory listing specification that I made has been described as being like a simpler and better (in some ways) version of WebDAV by some of the other people who have seen it. (It does do a few more things than only directory listings, but directory listings is its main intention.)
Maybe, maybe not, but even then, wouldn’t implementing those be easier (for both you and the rest of the world) than creating a completely new protocol?
> It still leaves the issue of it using multiple ports.
Aren’t multiple ports only an “issue” if you assume NAT (and CGNAT, shudder) as a natural state of things?
I for one want nothing to do with this. File system access is for good actors only, and the advertising assholes have poisoned the well for a web browser being anything other than a dumb document browser with the privacy settings turned up to the max for me.
When you think about it, the modern internet resembles a welfare state. Everyone's day to day sustenance is sponsored by a few wealthy benefactors, meanwhile they essentially hoover up what remaining potentials there is. There could be so much more than what we think is possible now.
A neutral file system and standardized file formats are a huge part of what has made computing able to do interesting things in the past 40 years. The fact that one application can output a file, and another can open it and operate on it is basically at the core of the unix philosophy, and the reason we can have things like developer workflows.
If I, as an application author, can only work on data in ways that are intended and officially blessed by another application, we basically have the situation we have on mobile where everything is siloed, and the state of the art is limited by the imagination individual application developers.
How then are web apps supposed to become part of a more durable workflow (i.e. opening/saving/moving/backing up files) if we do not permit them the same privileges as native apps? I don't think web apps should have total control over your filesystem, but why not at least allow them to operate within a folder?
They aren't. Web apps can't be trusted with access to barely anything on your system, lest they copy it to sell as advertising. As long as the internet is fueled by advertising, essentially all web apps are adware.
BTW both Safari and Firefox are not going to implement the File Access non-standards that Chrome pushes. They expose too much, there are no good ways to limit the exposure etc.
That can be a better idea. (Unfortunately the HTML file input in any web browser that I have tried does not allow the user to change the file name to a different name than the local file name. This ought to be fixed.)
When it asks the user for a file, can also specify the wanted access: read, write, read+seek, or read+write+seek. Requested format can also be specified, but the user should be allowed to ignore the requested format if wanted and instead specify an arbitrary file. For writes, estimated file size can also be specified as a hint, which can also be ignored. Then the user can type in a file name, or for the non-seeking modes, a pipe is also possible. For write non-seeking, the user can specify append or overwrite. For seekable files, a pipe is not valid. For writing to files, the user can also optionally specify the maximum size that the file is allowed to have.
That's basically what file system access is like in Android, unless you give an app Storage permission. Seems sandboxed enough if no other web apps can view it.
We are living in a multi-device, instant-access, access-anywhere, cloud-based world, and the desktop file-based paradigm has trouble with this reality. The vast majority of non-technical people would struggle with desktop-based files when they want everything everywhere all the time on every device at any moment.
Is that what they want, though? Most people that work an office job, at least, still deal with Excel, Word, and Outlook. Maybe they’ll setup work email on their phone, but that’s probably it. I’ve noticed a pushback (true for myself, too) ever since the push from work-supplied devices to BYOD.
People are realizing mixing private and work communications on the same device is a bad idea. The kicker is, this isn't even some kind of corporate conspiracy. It's just human nature - if you hook up your business e-mail to your private phone, you are going to be checking it after work hours, you will start responding to e-mails, and your work habits will shift to account for that.
That's why I just don't do that first step. The only connection between my current smartphone and my work is some TOTP keys in the authenticator app, to enable more convenient login to some cloud services the employer makes us use. I talked with a co-worker recently, who made the mistake of installing work communications on their personal smartphone, and they very much regret it - not because the company is exploiting it, but because they can't discipline themselves to not check business messages after work.
That depends what you mean by local files: On the Mac, at least, it will keep local backups. See the Backups menu item. Admittedly, the backups are not in a convenient format, rather being json files containing encrypted blobs. But there is a utility for decrypting all the files. So if you are merely worried about losing access, you're covered. So long as you don't lose your password, that is.
But for sure, other solutions work better if you have less stringent security requirements.
> don't know if there is any real way we can go back to the P2P paradigm without destroying NAT
I think it's time for NAT to go for residential ipv6 and the numbers I've seen show that TURN isn't required for most connections. Unfortunately universities and businesses will probably never remove NAT as there is limited incentive to do so.
I think the best we can do is have somewhat decentralized networks with limited yet trusted centralized authorities (the need for discoverability will always remain, even when using otherwise decentralized networks like SSB). This could be IPFS with bootstrap nodes for their DHT, or as I have been using to circumvent NAT when latency is unimportant, Tor directory authority to host ephemeral, local onion services.
> Finally, the file system paradigm fails with shared content; you can't save a Google Doc to disk because then how can your friends or coworkers update it?
Just curious, does anyone know of any hybrid file formats that store information both locally and online?
It seems like one solution to this problem would be a document that stores an editable copy locally and a revision hash in its metadata, then decides whether to serve up the local or cloud copy depending on whether the user is connected to the internet.
Sure, this could cause conflicts between online / cloud files if someone else edits the file at the same time as you, but that's true of any cloud sync service like iOS Notes.
I guess in retrospect I'm just describing Dropbox which, while it's more a container for standard files than a file format in itself, has largely the same effect.
Yes, filesystem sync protocols like rsync do it at the FS level and if you want to go deeper than the FS level, you get into the realm of operational transform and other rather complex algorithms.
A very insightful comment up thread observes that filesystem-centric computing worked for as long as collaboration was very limited. Once apps needed to move beyond that to collaboration at a finer grained level it fell apart and apps started needing databases, and in particular, databases that could link data from different users together, implying a shared privacy domain.
Was this change inevitable? The long since exiled and forgotten Hans Reiser wrote about this problem a lot back in the day (he murdered his wife and obviously his ideas lost any traction at that point). His thesis predated a lot of the concerns about privacy and central control that we see today, but briefly, he argued a part of why this was happening was that filesystem technology was not good enough because it couldn't handle very small files and because POSIX had some unnecessary limitations. Due to this lack, apps were constantly forced to invent filesystem-within-a-file formats, e.g. OLE2 and OpenDoc were both centred around this concept, SQLite obviously is one too, ZIP yes, but really most file formats can be viewed as a collection of small files within a file.
The idea was, if you upgrade filesystem tech, you can radically change how apps are written.
The problem is that operating system tech on servers and desktops has been stagnant for years. Microsoft and Apple lost interest in their primary operating systems and the open source world has never really been interested in going beyond 1970s design ideas, largely because cloning and adding small elaborations to commercial designs is the way the community stays unified. Look at the mass hysteria that followed systemd, which is one of the only upgrades to the core UNIX OS design patterns in decades. Actually making changes to the core of POSIX isn't something that's going to come out of that community. It'll probably take some company that wants to innovate on the core ideas again.
> > Finally, the file system paradigm fails with shared content; you can't save a Google Doc to disk because then how can your friends or coworkers update it?
> Just curious, does anyone know of any hybrid file formats that store information both locally and online?
I'm sure there are better ways to do it, but MS Office can, AFAICS, at least kind of do that: Documents stored in -- wossname, OneNote? SharePoint? One of those, I think -- can be edited in-place by Office Web apps, or downloaded for editing in the regular desktop apps and then saved back on-line and/or locally. If they can do that, I'm sure other apps can also do it (and probably better).
I have trouble believing that this is the fault of the techie lobby, considering that said lobby otherwise has no meaningful accomplishments under its belt. My explanation would be that the web is massively successful because it enables user to navigate safely without being in danger of leaking their files. If a user isn't willing to install an app to do a task, it is precisely because they fear that such an app will be able to do unknown damage to their computer. Allowing the same thing of web apps eliminates their advantage and endangers users.
It's not only ads. Autodesk I believe does online rendering now, and for most CAD drawings even a cheap APU can handle that level of geometry, but it's harder to justify a recurring revenue model for a fully local application.
As someone who has been designing stuff in native file-based apps for 30 years, I consider Figma a godsend -- because of their collaboration / multiplayer features. And I don't miss files at all, though of course I understand that I do not control my data stored in Figma.
It points to the need for native software to allow collaboration and this is actually happening slowly.
I still hate Figma though. It's too primitive and I'm sick of being given Figma links where the necessary resources are 50% chance not isolated, or not vector, or not exposed at all.
I'm not really sure how Slack saving documents to disk would really make sense. IRC was around before SaaS took off and webapps replaced desktop apps, but I can't think of a client that implemented "IRC documents" saved to disk.
Sure, most clients let you automatically save logs, but they were just text files you opened in any text editor. They weren't in a special IRC format, and you didn't open them with your IRC client. Hell, you couldn't open them with your IRC client. There's no reason you can't just ctrl-C a bunch of stuff out of a Slack chat and ctrl-V it into your text editor. Only difference between that and IRC logging is that you have to do it manually.
> they were just text files you opened in any text editor. They weren't in a special IRC format
Of course they are! Using anything other than text files to store chat logs would be idiotic. The main point is that slack is a user-hostile application that does not even allow you to do that. Why people put up with this is beyond me.
> Sure, most clients let you automatically save logs, but they were just text files you opened in any text editor.
Right, my point is why doesn't Slack do that? Then you could use `grep` or `find` to search across all your messages and avoid paying a monthly fee to access your entire message history and...oh, right.
You can only search a log for the time that you were logged in and saving it. You can search the entire history of many Slack channels from the very first message posted in it onwards, even before you'd ever joined it. That's a significant advantage over a local file.
I'm not particularly keen on Slack but suggesting search would be better locally is plain silly. Search is obviously better done at the server.
> You can only search a log for the time that you were logged in and saving it.
That ignores the possibility of the data being synced between local system and the server. Slack is already in the cloud, so cloud options are on the table. And so is syncing data.
> suggesting search would be better locally is plain silly. Search is obviously better done at the server.
The reverse is obvious to me. Slack search, like all web SaaS search tools, is really bad. I could do better with grep - and it would work faster, and I could actually trust that it searches through all the messages, instead of giving me some eventually-consistent view into results of a query that is only tangentially related to what I requested. And they wouldn't be able to tell me which properties I can or can not search by.
And I'm not talking theory - in the past, I did some spelunking in many years' worth of IRC logs in a folder on my drive, and the experience was much better than searching for anything in Slack.
> Sure, most clients let you automatically save logs, but they were just text files you opened in any text editor. They weren't in a special IRC format, and you didn't open them with your IRC client.
Yes, that's exactly the point. You owned this data, you could do whatever you wanted with it, and it was stored in a format that was both trivial and most fitting for the data stored.
> Hell, you couldn't open them with your IRC client.
I'm pretty sure you could in some clients, and some definitely pulled stored logs to backfill the chat after restart. Though I haven't done that myself (instead I relied on a bouncer to supply the backlog on connection).
> There's no reason you can't just ctrl-C a bunch of stuff out of a Slack chat and ctrl-V it into your text editor. Only difference between that and IRC logging is that you have to do it manually.
That's a world of a difference. In Slack, it's painful to do, and if you haven't done it when you first saw a message, it's going to be even more painful to do after the fact.
> (spoiler: this argument is dead and nobody will ever go back to native apps again)
Oh god, please, no. I don't really understand the disconnect between your love of filesystems and yet disdain for native apps. The exact same arguments apply; can't serve ads locally, don't autoupdate (a feature! they rot slower), can access any time, don't need a network.
Why would you want a webapp? Because it has flashier animations and SVG? There's a long conversation to be had about this, but the summary is no, no, god no, please give me back my native applications with drop-down menus and boring file picker dialogs. As long as they have decent keyboard shortcuts, I'll manage.
Who said they disdain native apps? They simply believe that web apps have/will continue to take over. You aren't going to get back native applications for every product just because you prefer it or that to you it is better. There are factors more powerful than that which are determining that web apps are more suitable.
For example: ability to serve ads, autoupdate, AB testing, tracking
Maybe those things are bad for you but are they bad for the people who make the product? No, they're pretty good things for the company, maybe even expected in 2021. Your preference against those things doesn't change that fact
Those social media contents you've listed there is nothing anybody wants to keep. Let's be real here. This is throwaway information. While outside of the edgy cool startup bubble the rest of the professional information is still being saved somewhere. Sometimes even saved AND printed. No matter if it was on Slack, Teams or wherever.
Here’s an interesting example of an app that runs in browser and opens/saves SQLite GeoPackage files on the computer running the browser instead of a remote server.
> this argument is dead and nobody will ever go back to native apps again
I don't see this. The native program ecosystem is alive and well as far as I'm concerned. All the programs on my computers are native, despite noone "going back".
> Finally, the file system paradigm fails with shared content; you can't save a Google Doc to disk because then how can your friends or coworkers update it? It's much easier for Google to store the data on their server so that everyone can access it instead of you setting up some god-awful FTP-or-whatever solution so that your wife can pull up the grocery list at the store.
Now go and check out syncthing, you're in for a really good time.
I keep repeating this argument in different forums, but: if you every lived in China you would realize that the native app is the past and the future. Since governments can block websites, that means they can block your web apps too. When I came to China I completely lost access to Google Docs, Gmail, Facebook, etc. Relying on web apps is exactly like giving governments the right to uninstall applications on your computer.
Right now this is not a big deal in most countries. Right now. But as the web becomes increasingly balkanized (and I believe it will) and as countries become less democratic (always a possibility) the native app with local data will reassert its prominence in people's lives.
> Relying on web apps is exactly like giving governments the right to uninstall applications on your computer.
To some extent, governments, across the globe, are already exercising this right in some form. Quite often we hear that some government has banned some app and it becomes illegal to use that app in that country.
This is an important point, but then "native" iOS has the same vulnerability. Apple arguably has more power to block iOS apps than China has to block the Web, so China just tells Apple to block what they want blocked, and Apple does it.
If it makes you feel better, efforts are being made to bring non-tyrannical operating systems to mobile in a braindead-easy, consumer-friendly fashion. You can search up loads of articles about the amazing stuff that the peeps running organizations like Pine64 and LineageOS have been up to.
Some other reasons for saving files in the cloud not mentioned:
- lets you access them cross-device more easily (replicating the files on each device could be could, but uploading to the cloud seems easier);
- backup, in case my device breaks or is lost
Yeah, well, it's not 100 % his fault. Browsers should default to "Ask every time" for download file location, in stead of just bunging everything into a default "Downloads" folder.
But that's really fucking easy to change, so still 90 % his fault. (Or 95, 99...?)
> we stopped using files to represent information. Figma, Slack, and Notion should save their information to disk. You should be able to open a Notion document, or a Figma design, from your desktop
A good observation, but I think it conflates two different trends:
1. Some software platforms deliberately limit what data is stored on your local machine under your control
2. There's been a shift in UI/UX away from using files as a first-class abstraction
There's a good case to be made that a UI should generally hide the specifics of its data storage. As an example, it's a good thing that most email clients present the user with their emails, rather than with a raw folder of files. (Internally, the email client might make use of a database rather than a directory, so it might make good back-end sense too.) Of course, that's not the same thing as the email client being hostile to data-portability.
iOS strongly commits to this ideal, even at the expense of constraining user actions. The podcast app doesn't let you upload your downloaded podcast episodes to your desktop computer, for instance.
Aside: iOS has very poor support for dealing with files in the usual ways, to the point that you pretty much need to use a third-party app to do so. I've found the freeware Documents app by Readdle to be very good for this.
> this argument is dead and nobody will ever go back to native apps again
I agree that the web as a GUI toolkit is here to stay, but native apps are alive and well too. There's a trend to try to push users off the mobile web and onto native apps (Facebook, Gmail, reddit), rather than the other way round.
> this argument is dead and nobody will ever go back to native apps again
This snippet has really lit the touchpaper. A long time ago, I predicted that the world was course to deliver insta-compiled applications through a browser, as though we'd have a Visual Basic runtime environment plugin. However, we're now there, essentially, with XHR and many-megabyte JS bundles, manipulating the DOM through the browser's "widget" engine.
There's really a tipping point for each application, where the application's functionality determines where it is better served. For instance, no one's going to make a web app out of Logic Pro any time soon. However, if someone comes up with a stateful protocol to implement in current browsers, then that tipping point flips to the web for a whole bunch of applications.
Not just that. We have a lot more metadata these days and not everything can be a file. If you keep all the metadata and database-like files accessible to the user, how do you handle store corruption?
EG, a video recording/playback app that allows the user to save bookmarks/timestamps. You'd need to have some place to store those bookmarks, extract frames, generate multiple resolutions for both the video and frames (for gallery previews etc), possibly add some more metadata...
It's much easier to hide the actual files from the user and give them the option to export the data in some user-readable format.
Apple is notorious for this. Everything is a soup of folders and files with hashes and .plist files. Similar story with iOS and Android.
Nearly everything this article takes issue with could be fixed by treating rich metadata at the filesystem level as a first class citizen, and enhancing basic dialog functions to reflect that metadata.
Unrelated, but could you please stop creating accounts for every few comments you post? We ban accounts that do that. This is in the site guidelines: https://news.ycombinator.com/newsguidelines.html.
You needn't use your real name, of course, but for HN to be a community, users need some identity for other users to relate to. Otherwise we may as well have no usernames and no community, and that would be a different kind of forum. https://hn.algolia.com/?sort=byDate&dateRange=all&type=comme...
I'm not a mod, but they almost certainly track the IP addresses of people who create accounts. It's basically impossible to do spam prevention otherwise.
I think that most people don't have static IPs and then there are proxies and VPNs... I don't think that IP is a meaningful identifier. From my experience IP bans never really work, except maybe for range IP bans, but then you might affect other users too and of course you could still circumvent it with a VPN.
I once created a throwaway on HN for something sensitive, and I happened to be on a VPN at the time. My comment started out dead and I had to vouch for it on my main account.
So I think that's just the tradeoff they make, in order for HN to be able to exist. It probably gets reversed if you email the support link.
605 comments
[ 3.1 ms ] story [ 381 ms ] threadWhen was this the case? Not in the "1980s and 1990s"
Also helps because it's 1280x1024 so I'm not pushing the 4K pixels of my main screen over Teams.
I found he didn’t know what he was talking about.
Files can be accessed by typing in their full path (with tab completion in some cases). (Some programs insist to use the GUI to select/list files rather than you can just type them in, and I hate this.) For searching files by name, ordering, etc, there is such commands as ls, and stuff that can be used.
For downloads, I will always type in what I want to save it as and in what directory, and usually I will use curl to download and redirect output to a file, or sometimes to another program is useful.
For screenshots, again I can use command-line programs; a program can make the screenshot, and then piped to the one that encodes it as PNG, and redirect its output to a file in order to save it to disk.
Command line interface is better, I think.
When I open a program, I want to use that program. I don't want to update it, I don't want to see all the new features, I want to USE it. I opened it because I had a task to complete and all this junk is getting in my way.
And same when I close a program, as the author hits on very well.
Basically, the computer/program/etc always wants me to do something for it, but it never asks for those things at an opportune time.
No, I don't want to update my computer right now, and no, updating overnight tonight isn't good either because I need to keep this program running until tomorrow. I understand that your new UX is better for me, and I'm sure I'll love it, but forcing that on me right now is preventing me from doing what I need to do. I see your error dialog describing some odd issue, but I don't have time to triage that right now and decide to take the time to fix it.
I wish software would respect the human element more. My time and attention is valuable, please don't interrupt it carelessly.
Source: I own a Pinephone and has tried both Phosh-based and KDE-based offerings, there is also Sailfish though. Out of these Sailfish is the only one close to usable as of now.
Ignoring this advice might lead to application termination.
Note I'm not saying it's good, but good enough for me. I've been using Arch, as I find the rate of improvement shows in a rolling release distro, and in my experience, Mobian is no more stable.
And since Android is also a Linux distro, then there are alternative forks based on it too (e.g. LineageOS).
It's not that hard to respect users more than W10
Windows 10 isn't even the best Windows, let alone the best software in its field.
We don't always have a choice.
But for example Steam updates on boot, which is a (albeit minor) pain when I want to use it. Similar with Spotify. There aren't really any great alternatives to either of them that have equivalent libraries of content.
Or going right to the core, Windows and it's annoyingly frequent updates. Sure I could use Linux (and I do on a few machines), but that isn't possible on my work machines, and introduces incompatibilities on my personal machines.
I’m sure the author has a point but I’m just distracted by this strange use case.
Maybe some applications could have an alert mode, similar to logging levels. But then it will probably get more buggy.
Honestly, I rarely get annoyed by the number of popups in most of my software. I’ll happily take a few extra dialog boxes for extra control.
The extreme alternative to "device, please don't ask me when you want to update something, just do it" is losing control of your computer. If you're comfortable, like the author mentions, having your digital "home" be away from your devices, to "live in the cloud", I guess this doesn't matter (at least, while your favorite cloud providers and services don't shut down taking all your data with them, decide to hike prices, or ban you for breaking some ToS rule).
If you want to fully own your computer, it matters. You don't want to give away all control over it.
But what about security updates, though?
A flaw in my browser is extremely high risk and I require it fixed and updated quickly. But a flaw in my SSH server that is only accessible from behind a VPN is lower. And the risk is lower still if it's a flaw in a feature which I do not use.
I don't see an easy solution of course, it's a hard problem. But I wish that I had more granular control over what and when I update, and was given a clearer way to see the impacts of the update so I could weigh risk.
How did we update software in the 80s? Simple, by taking an action: inserting the floppy with the new software, starting the update program, etc.
Why can't it be like that? (Except the floppies replaced by opening a menu and clicking "update")
Why do updates have to be performed at a pace controlled by the vendor of the software and why do I need to be reminded about updates?
I'll just install them when I think I need them, thank you.
This includes browsers, where I let the auto updates handle it, and programming environments (Python, R, Node), where I often use their specific updaters.
I don’t think it’s realistic to expect a global curated package manager to stay on top of the bleeding edge all the time.
I'm a programmer and still this makes no sense to me. Windows and Mac somehow let me use the latest OpenOffice even if I haven't updated my OS in forever.
So naturally when all applications depend on the same shared libraries and configuration files, they need to be updated on a full swoop.
Yeah, when one knows their way around UNIX it is possible to actually install new software that works around this, but that is exactly the problem for most desktop users, "one knows their way around UNIX".
No.
I hate that you are correct, at least to some extent. In that analogy, the / directory is really C:/Windows, with everything attached under that.
What have we done. Perhaps Mac OS got at least one thing right: /Applications and /Users at the top level.
Well, yes, that's the flipside of updating everything at the same time. You have to update everything :)
And if you're using an LTS version of an OS, you'll usually get a related LTS version of the apps from the same era, especially for the older OS versions. Because they prioritise production stability. If you just use it as a working desktop you'd be better off using the bi-yearly versions.
I also wonder if there is a liability component to this that makes force updating a common pattern.
Though setting aside practicality for a bit I wish we would design software to be more backwards compatible so old versions of things could continue to work for longer. I shouldn't have to buy a new phone every three years, for example.
Also for a tool like Audacity, I rarely need to update it. It doesn't depend on a service, so I don't need to worry about an API falling out of support and he security risks are much lower. I wish we could design more of our software to work this way.
Obviously for internet connected things like browsers this isn't possible as the security impacts are significantly higher, but why should I need to update Word every month if I don't plan to use the online components, for example.
I'm imagining some automated tooling where changelogs are tied to specific git commits, and when you go down a code path that has a changelog entry tied to it in this way, it pops up the dialog. The program downloads the changelogs in the background (if the user chooses), but doesn't pop up a notification unless it's relevant to the user.
I think what we need is another way of architecturing software. I'm thinking of Erlang's actors and hot reloading: the whole language and its environment were built to allow upgrading parts of the app without turning the whole thing off, thanks to actors that compartmentalize state and minimize the places where it can change. That's extremely useful for servers, but why can't I have the same for desktop apps ? For your example again, maybe have some "actor" that can give me a sort, and when updates come the old instance is killed and the new instance takes its place. No need to turn down the app, to lose my current work, to waste dozens of minutes.
Unfortunately desktop apps are pretty much dead for the masses, and webapps solve both the problem of not updating (next time you come it'll be updated) and atomic updates (a client side app can load some javascript when needed). If we want desktop apps to come back (I do) we need to find a way to do the same
It might, if you did it like GP posted:
>> a little note pops up informing me that there's a bug in sorting non-ascii characters that was fixed recently
>> The program downloads the changelogs in the background (if the user chooses)
Note the stark deviation from standard practice: GP would like the popups to actually tell you what's in the update.
In my experience with both techies and non-techies alike, the main reason everyone hates updates is that it's always a cat in a bag. You'll likely get some bug fixes. You may get some new features. Some of those may even be useful. It's more likely the app will become slower instead of faster. It's quite likely there will be disruptive UI changes. Often completely gratuitous ones.
Random recent example: I noticed my wife has an OS update on her phone pending for the past three months. I asked, she agreed, I did the update round. Told her, "wow, you're getting a version bump, I envy you". I immediately noticed some user-set icons were wrong[0], but quickly corrected it without saying anything. I though that's the worst of it. Couple hours later, she comes back to me complaining that the update messed up notification sounds and the new keyboard has changed scaling, breaking her muscle memory for touch typing. Also the battery life dropped significantly.
Updates today are like loot boxes in games, except most of the "rewards" make your life worse.
One solution to this problem would be to have a separate stream for feature updates, and a separate one for bugfixes and security updates - and only ever bother the user about the latter. But that would increase the costs for the software vendor, and we can't have that. Who are you, the user, to complain about what your lord does? SaaS stands for Serfdom as a Service.
--
[0] - The ones you assign to your SIM cards in dual-SIM use scenario. The update added new icons to the set, and apparently the OS must have been storing user choice as an index into that set, instead of using icon ID.
> SaaS stands for Serfdom as a Service
It's interesting that the SaaS term was born from the Cloud, but its tenets still apply to desktop applications
I'd agree in most cases, but I'd still leave some grace period for updates that require rebooting the app or the OS. Nag and cajole the user all you want, but don't ever lose their data, or interrupt them during a meeting.
> SaaS term was born from the Cloud, but its tenets still apply to desktop applications
There are two main facets of SaaS - a nice one, and a nasty one. The nice one is that it outsources ops/maintenance. You're just using the software, someone else is keeping it running and up to date - and it's more efficient this way. The nasty one is, the party controlling the software is in position of power - they can make you pay rent, lock you in and hold your data ransom, and exploit your data in ways you don't want - and you can't do anything to stop it.
Desktop apps relinquish most of the benefits of SaaS, but the drawbacks were backported to local software by means of normalizing subscriptions and automatic updates.
Grandpa goes: Sorting? Wha? Non-ASCII? What's ASCII? Characters? Like on TV??
But that introduces issues where if Google adds some shitty new feature to Chrome I sorta get forced into it instead of having an opportunity to choose, so there's definitely a tradeoff and also a responsibility on the part of the vendor to make sure they aren't abusing their ability to install things on my computer.
My comment above is more of a rant than a recommendation.
You'd clear away all the stubs of work, and the computer would say "Hi! Did you have a good work day? Here are a few things that would be great for you to do:
1. Upgrade these two apps
2. Do you want to check out how Dark Mode works? No? Ok
3. You've had these 46 tabs open since that one day six weeks ago you got into the idea of building your own treehouse. Want me to save them all in a notebook entry and remind you about it next summer?
Perhaps the problem is, as you allude to, that software is hostile to the user now. There's always something more than simply being a tool that you buy, use, and close. Now most programs are merely portals for "services".
More like three legs on that stool. The sale price, the services upsell, and then they leverate insights gained from capturing telemetry about you.
Eg Windows is all three.
That’s because the application would straight up lose the files without prompting.
Also pretty sure text editors had something similar 50 years back, that’s why you :q! from vim, :q would tell you that you have unsaved buffers (or whatever the lingo is) and refuse.
TFA is literally abusing a crash-resistance feature out of laziness, and will no doubt complain when it fails them. 20 years back we’d all trained ourselves to save with regularity to avoid issues, that feature would be considered manna from the heavens, and tfa absolutely mental.
Completely stupidly too, I must add:
> This is the dialog that I see every time I want to close the Preview app to clear my desktop of all that clutter in a hurry for a video call.
MacOS has a shortcut to minimize all windows! It even has a shortcut to hide all aplications but the current one! You don’t need to close anything to “clear your desktop in a hurry”!
However this was never brought to the desktop, largely because native desktop APIs are dead and none of the companies that fund them are interested in improving them. We get the web and if it sucks, well too bad.
Funny, because I think the exact opposite. "Hide" means, "stop showing it for now, but keep it around". "Quit" means, "I'm done with you and I expect you to not be doing any work until I start you again". It's a very significant usability difference.
> On mobile it doesn't happen, and we can thank Android for that
To this day I consider it to be the worst, most dumb idea Android ever had. I hate it. It's the reason I hated my first smartphone. It's the reason why, from the second phone on, I only ever buy top-of-the-line most overpriced flagships available - I have to overprovision resources to ensure the phone works smoothly, because there are countless of background processes doing god knows what, that cannot be killed and prevented from restarting.
I know best when I'm done with an app. I want to be able to kill it, and all its background processes, and I want them to stay dead until I change my mind. If I were designing a mobile OS, I'd make the distinction between "hide" and "quit" as clear as day, and make it an app store policy violation for an app to execute anything in the background after being "quitted" by the user (polling for notifications would be handled by the system).
1. There are times I want to make sure an app is not running (think zoom/hangouts with video access), or a work app that records location
2. The single best way to fix a problem, any problem, is still 'turn it off and back on again'.
I don't want to kill the current activity and hope that the background jobs stop at some point in the nearish future with absolutely no feedback or insight. I want "killall <root app process>" then give the app 5ish seconds to cleanup and if it's still around "killall -9 <root app process>".
Too many apps abusing resources and affecting UI speed is a separate issue, and mobile OS's developed a lot of techniques and technologies to allow apps to work in the background without bothering the user, and without overloading the device's resources. It's a nice set of systems, really, and I would be happy if desktops worked the same way. Nobody would be taking force quit away from me, even if such a system were to be implemented.
Yes, and this turns my phone into an amnesiac the moment I have a hundred tabs and fifteen apps open. Switch to a different app, switch back... Oops, all gone! Enjoy recreating the state from history manually, if that's even possible.
There are no words to express how unhappy this makes me. We've got gigabytes of memory on our handhelds these days, why can't the phone just deal with it?
For whatever reasons, non-graphical software seems to suffer less from this problem.
Forfeiting control of a system doesn't really bite as hard when you didn't understand the system enough to control it much anyway.
Not sure if that’s relevant but it feels like it should be
I especially love when Firefox decides that he really needs to update, and I cannot open any new tab until I do so. Who cares if I am on a crappy connection and the download that I need to finish will take 20 minutes more; it's either restart it or wait until I finish. And that other thing in that tab that I need time to finish but I cannot really save ? Who cares.
Simply don't run system updates during a Firefox session and you're golden.
Indeed. Microsoft Office I'm looking at you! I don't think I've ever actually looked at one of those "Hey cool new stuff for you" popups more than trying to identify how to get rid of it as quickly as possible.
And even worse is "Hey here's a new feature we like so we turned it on for you, good luck figuring out where to turn it off again lol"
I like where Windows is now, I get notified of required updates but I can defer it for a few days/week. For non-technical people who don’t know how to setup defers I’d imagine they would also be the crowd before who didn’t update. I’m totally fine with my parents occasionally grumbling about a forced reboot overnight.
Likewise all the software I use, besides online games, let me defer updates. Lots of stuff also now has the update next start, which I also like. I don’t even notice my browser updating most of the time until I open dev tools and see “what’s new”
Seems like we have a fundamental security issue that results in having to keep fixing vulnerabilities across most software, which sounds like applying bandaids and treating symptoms rather than coming up with a more secure approach.
Perhaps the issue was that we insisted every program be internet connected. If everything were offline a la Battlestar Galactica, security exposure would be greatly reduced - pretty much only the standard USB stick attack vector would work.
> And same when I close a program, as the author hits on very well.
The weird thing is, that is a solved problem. App Store apps (Mac, iOS) will automatically update in the background and, unless the developers build it into the app, the changelog if any will be on the store page. All platforms have something similar. It's just that a lot of developers opt to release and update their thing separately for a variety of reasons.
I agree on the OS updates though, some years ago there were a few... claims? Promises? Something that implied restarting to update would no longer be a thing. Dear reader, they were wrong.
/me clicks the MacOS update thing away again
Jonathan Blow did a talk similar to this a few years ago, about how "software is terrible".
In a part of it, he double clicked on a .psd file to open in Photoshop and timed how long it took to open the image. It took around 8 seconds for Photoshop to display that image on screen. But the first thing the app did was show a splash screen image, almost instantly.
His argument was, "Why, when I double click this image file that I want to view, does it instantly load an image which isn't the one I want to view, and then take 8 seconds to load the one I do want to view. If it can instantly load an image when I double click the file, why isn't that image the one I double clicked?"
Yes, search is great when it works. You know what also works? Organization. I used search within folders of very large category to rapidly narrow stuff down.
If the desktop ain't broke, it doesn't need fixing.
Instead, I am thinking about all the dark patterns and anti-patterns, as well as performance hog, endless constant update, as well naggers trying to upsell you shit.
There's a reason why I returned to linux. Microsoft, please fix your shit.
No, if a commercial for profit system doesn't work for the vast majority of users, then it does deserve rethinking. Linux is a great example of an operating system that was not written for the highest profitable denominator until recently.
And as you imply, when you have a lot of files that you need to organise, you tend to start compiling them into directories.
Tags are very powerful if used properly. They describe sets by definition and allow quick filtering with intersections and other set operations. If the filtering is a bit smarter it can support boolean operators, or use tag distance and order as a meaningful data point so that e.g. "discussion board" doesn't return the same results as "discussion snow board".
They're a more flexible way to organize data than hierarchical directories. Hierarchy can easily be expressed with tags (use any character as separator, e.g. "os.linux"), but files and directories are not nearly as expressive enough for all the use cases tags can be used for.
You could put the same file in multiple directories. You could have a file in ~/vat and symlink it to ~/urgent and ~/accountant.
I'm really addressing the argument that tags are a revolutionary change that should replace the directory-based filesystem entirely. The cost seems too high to justify the benefit.
I'm not actually interested in building such a system, it's been done before[1,2]. Though I haven't actually used any extensively, since it does require a shift in how file management is done, and I'm quite familiar with filesystems to bother to change, but it's on my list. :)
[1]: https://tmsu.org/
[2]: https://www.tagsistant.net/
I don't disagree that interfaces should be designed for users, but they should be designed to EMPOWER and teach users, not to just dumb everything down to the lowest common denominator. Because, let's face it, most people are awful at organizing stuff that materially matters a lot to their lives and well-being.
Why do I believe we do not know how to solve the problem? As the article inadvertently points out, the unorganized data they want is not accessible and Mac Spotlight, a tool that operates on unorganized data, does an "OK Job, but not a miraculous one". If Apple knew how to super search the vast trove of unorganized data and file formats for content-specific data and always get it right would there be any reason they would not do so? It would clearly be strictly superior to their existing offering. For that matter, they bring up browsing history in Safari which is an even easier problem and also claim it hardly works. For evidence outside of Apple, think of all the in-app search systems that can barely even search plaintext for things you know exist. I frequently have problems with Gmail not finding emails despite giving exact string matches. These problems are all subsets of the proposed problem, which must be solved to solve the harder problem, and which would offer immediate material benefits for their solution yet do not or barely exist.
The problem is not a mismatch between solution and user workflow. The problem is that we do not know how to solve the problem for all meaningful workflows. The best we have achieved is creating and supporting a workflow that allows the problem to be solved in many useful cases. Luckily, if the problem can actually be solved in the future, it can easily be bolted onto the existing solution to test viability before going all-in.
For evidence outside of Apple, just try to use browser history in Chrome or Firefox. They're completely unreliable, entirely useless. For me, it's 50/50 chance I'll get a result when searching for a site that I visited few days earlier.
> think of all the in-app search systems that can barely even search plaintext for things you know exist
Exactly.
Most of the search systems I've worked with have one, big problem: they don't feel reliable. You type in a query, a system starts a search. You get some indicator of progress, which eventually expires. Typically, search systems don't tell you if the search was exhaustive - did it check every possible thing that could match, or did it bail out after hitting some time limit? They also often meddle with the query, modifying it or doing fuzzy matches, in ways not communicated to you in the user interface. With such systems, if the thing I'm looking for isn't in the result set, I don't feel confident it isn't there.
Manual file organization (or any direct data access) has this property of being exhaustive: a file is either there or it isn't. Direct file access means that if you don't trust your file searcher, you can always look for yourself.
There are many other challenges ahead if we want "universal search" to work, but a big step forward would be addressing these trust issues. It's entirely an UI issue. Instead of "0 results found", say "0 results found after searching contents of all text files in Documents folder (symbolic links not followed)". Instead of "about 123 results", say "123 results found, there may be more matches, [click here] to read about limitations of the search method".
(And on a general point: users aren't as dumb as the common claim is. Our industry is treating them as dumb, taking away every opportunity to learn and build mental models - and then complains that users "are dumb".)
Most people, in their jobs, every day.
Just as they did before the advent of computers, too.
The real question is what is effective for individuals and business trying to accomplish real work, who are at least somewhat capable of learning or training staff.
The idea of fragments as TFA discusses really resonated with me, because most of my life is not in files. Giving a real example, a few months ago I read a blog post about some house planning software (I'm in the process of building a house), and later needed to refer back to it. I didn't save it anywhere (bookmark, save as PDF, Notion/Roam etc) because it didn't seem that important at the time.
Its the same if you watch a YouTube video or read an article here. Sure you could take notes and save those notes in a text file that you can later search, but who has the time to that for every single piece of content they consume?
Something like Spotlight is a good start, but it needs much more meta-data. All of your search and watch history needs to be there, but in a world that's becoming every more siloed (how do I record the photo a friend shared with me a few months ago on Facebook Messenger?) that's tricky.
Most software can't be bothered to integrate rich paste support (e.g. the way you can paste an Excel spreadsheet into a Word document), and we expect them to implement a complex API to define these fragments in a way where the OS/Spotlight could actually build up that history?
This would be a massive undertaking requiring buy-in from every piece of software before it is even marginally usable. It is a pipe dream (and may even be a nightmare if it were realizable).
> Its the same if you watch a YouTube video or read an article here. Sure you could take notes and save those notes in a text file that you can later search, but who has the time to that for every single piece of content they consume?
Those already exist. The browser has them all in it's history. Google similar has many if them stored for their services. To some degree they use them for the user, but there is simply limited use for those informations.
I used to have a tendency to over-categorize and nest things too deeply, which makes them hard to find again. Concrete example: nesting classes by semester. When looking back for something, I would usually remember what class it was, but I'd often forget the semester. So now I have to search through a bunch of folders (manually or automatically) to find it. Ugh. A flat structure is much easier to follow.
However, I still want all my classes grouped together when I'm listing them. Currently the only way I know to achieve this is by adding a prefix to the file or folder name. This works, but you end up with some grotesque names. The implementation could be regular folders with a flag to indicate their contents should be displayed inline one level above.
going with your example above, it would allow you to just have folders for classes and then have files from all years in the same class folder. then you can sort of hack together a divider feature by adding some brightly coloured jpgs with a timestamp at the start of the year which would let you see at a glance where each year starts and ends.
it also helps if your file browser will remember to open each folder with the newest files show first at the top
I've been doing this for almost ten years, and it works great.
I personally seek to intentionally stay away from walled-gardens, reduced reliance on huge corporations seems like a winning move in the long run.
Once upon a time there was a "manager" whose job primarily was to communicate via memo with his peers and superiors, and the cycle time for data to pass from his (yes, his) employees, to him, then he processed by him on his desktop and sent out to his peers etc was at least a day usually a week.
So there was plenty of time for him to arrange things in a single "document" called a spreadsheet, and maybe update a memo on Wordstar and send that via the typing pool etc etc
But the cycle time is now down to maybe hours if not immediate - and if the company is doing its job right in automation terms there is no need for manager to send out his documents - the data is in several warehouses already.
The desktop metaphor is as dead as middle management.
Want a new metaphor - look at Jupyter Notebooks - that's a layer on top of the existing data - kind of like middle managers were on top of their employees.
I didn't read the the article but from others have said here they didn't offer a better one.
Search is great, when it works. When it doesn't, it is frustrating. Github's file search regularly fails to find some files that I know exist (one of our YAML files at work, in particular, is invisible; I've learned to just not even try). "Shell" won't find the sea shell emoji in OS X. "sea" will. "Place of Interest" (the command key symbol) is also similarly frustrating.
> who cares, disks are big, save it all, forever
Except they're not. Laptop's preference for SSDs means my work laptop has <300 GiB, which was full within a year.
I frequently end up with a bloated dock with a ton of icons signalling that the app behind them is open (the little dot on top of them).
When I close all the windows of an app why on earth does the app stay open? Why do I need to have Powerpoint open in the dock with no Powerpoint windows open? Especially today that we have SSDs and fast processors that can launch an app within a couple of seconds?
If an app needs to run in the background without UI, there is the menu bar for them.
Linux and Windows have much more rational UX regarding desktop usage.
Because you said so in System Preferences.
edit: Is there an option now in the MacOS Big Sur to enable this? I have a 3rd party app to achieve so.
There is only the opposite: "Set all app windows to close when quitting apps"
I currently use a 3rd party app to close for me apps when I close all of their windows.
And I dunno about you, but my 2017 Macbook Pro still takes a significant amount of time to launch Big Serious Apps with a ton of plugins. I like being able to tab over to Illustrator and hit command-n and be fucking around in a new canvas with absolutely no waiting. We have virtual memory, open apps in the background doing nothing but waiting around to be used will get frozen to disc, then get restored a lot faster than they boot up. I generally hate it when apps auto-close themselves without asking when I close the last document like Windows tends to.
Like you, I use Cmd-Tab to know what I have open (and you can obviously Cmd-Q while there to close apps) and Cmd-Space to open apps. I never use the Dock or the grid of icons view or any equivalent (not sure what they're even called).
If you want to close a window, that's Cmd-W.
Why would you expect a Cmd-W to turn into a Cmd-Q if it's the last window open? That makes no sense to me. Just close the program you aren't using.
In KDE/Gnome/Windows you know what the X buttons does. It closes an instance of an app. If it happens to be the only instance of the app, it will close the app as well. You don't have to babysit the open apps.
For the very few exceptions that an app needs to run in the backround, you will be notified that by pressing X the app will go to the taskbar.
MacOS also has a taskbar for apps that run in the background, but it also has apps running in the background in the dock. It made sense a decade ago with the slow hard drives, now it is just a peril of the past. Similar to the C drive in windows.
And it never leaves the app running with no UI either, because the menu is part of the UI, and it's still running.
This is probably not obvious if you're not used to macOS, but that's a bad reason not to do things this way IMHO. It's completely obvious to me.
The red dot closes windows. All three coloured dots are window commands.
Not that I use them much, I use Moom for window sizing and Cmd-W to close windows and tab (Shift-Cmd-W to close a window full of tabs). But that's just me: the dots are there if you want to use them, and what they do is completely consistent.
You're not used to what they do, but that's not the same thing.
> the menu is part of the UI
I would argue that that global menu is not part of the application's UI. True, it's application-specific, but it's very easy for a novice user to miss the context switch and just be left with the impression that the app is some kind of 'phantom'.
That's why the name of the application is always directly to the right of the apple icon, that tells you which application is in focus, and all the menu items next to it are application-specific. The global part of the menu is just that apple icon, and the menu tray off further to the right.
Can you point me to an example of a macOS app which closes when the last window is closed? I literally can't think of one.
I'll let it go because it's not a very interesting debate and it's not the main point anyway. I haven't been a novice user for ~10 years, but I can still remember what it was like moving from Windows to MacOS — quite confusing!
> Can you point me to an example of a macOS app which closes when the last window is closed?
Calculator
Document-oriented apps expect that, after you close the document, you might want to open another one or start a new document.
Documents <> Apps
So shifting window closing behavior to function like that of Linux or Windows would actually require a much more fundamental change than it might seem.
The red button on windows on macOS is meant to convey the action is potentially destructive to the window's contents. Even if the "destruction" of a utility window just means it goes away. It's not tied to quitting the application, with exception of single-window applications like System Preferences, for the above launch cost reasoning.
This has all gotten muddy over the past twenty years. The App Resume/Restore feature in Lion (peak Forstall) is terrible and I disable it on every Mac I use for more than a minute. I can see it being helpful for some people but it breaks the way I expect the system to behave after using Macs for 30+ years.
When I try that on Windows, the program closes, and I have to re-launch it. I daresay that's more annoying than discovering that a program hasn't quit when you think it should have.
The big 'X' will always quit the program though as that's what the user would expect. Imagine Chrome/Firefox's big 'X' only closing the current tab (is that how it works on a Mac?).
Someone who cut their teeth on other platforms may regard the death of an application with its last window as an essential part of their machine staying usable.
I don't know if you ever owned one of those really old windows ce devices but in a certain era it had the delightful workflow that closing them didn't kill them and after a while you could open as many applications as memory could hold and you would need to go into a different menu entirely to close unused applications or you couldn't open anything else. Like the worst of both worlds.
I'd say that Windows traditionally did a terrible job of allowing applications to have multiple documents open at once and visible on a large monitor.
The traditional Windows Multiple Document Interface UI was a nightmare if you wanted to have more than one document (especially documents from more than one app) visible at once on screen.
https://docs.microsoft.com/en-us/windows/win32/winmsg/about-...
That terrible interface is the reason Windows conflates closing an app with closing a document.
https://docs.microsoft.com/en-us/cpp/mfc/sdi-and-mdi?view=ms...
If I close one document the excel instance that is running that window will close too. The other instance of excel with its document will remain unaffected.
Edit: It wasn't until Office 2007 that some Microsoft apps (but not others) started breaking the Win32 MDI UI.
Thanks for the nostalgia run there.
Apple agrees and indeed many of its first-party apps work like that. Close the last window in Numbers, Keynote, Preview, and the app will disappear from the Dock.
This is opt-in by the app for compatibility reasons, and Powerpoint has not opted in, perhaps because there's no obvious benefit to the app for doing so.
Someone who has worked with Macs for a while will just close the app with CMD-Q or use the menu. It seems weird to have to close the individual documents to close the app. Many of my apps are setup to reload the same documents when the app restarts do quitting the app doesn’t abandon the documents, it just files them away until the next time the app is opened.
There are non-document oriented apps that only use one window and when that window is closed, they are setup to close the app.
You obviously spent a long time on Windows where the windows were the app and closing the window closed the app. Documents are secondary.
I'm building a ui from first principles, ostensibly in 2012 it started as an itch to scratch because I found that no note taking software met my needs, the way people used email sucked, jira et al sucked, and I couldn't wrangle non-nerds into interoperating with me on emacs.
Instead of the computer as desktop or some other abstraction I started with an interface predicated on the idea that reality itself has 3 first class citizens: Time, Space/Structure & People/Minds.
As an organizing principle applications are just metadata on data structures (_App_tributes on a node if you will) in the same way a function is a file in a directory or hosted on a cloud service. "Data first" happens when you get rid of the "container"/desktop metaphor.
First Class: Nodes, People, Time
Second Class Enablers: Namespaces, Fragments, Timestamped Messaging, Specialized sub-interfaces
The reason projects like chromebook try to hide or delete structure is because App based interfaces are more conducive to advertising and because people use APP as a visual reminder of "functionality". A person or org must have complete "write" control of their data if they are using a first class data/structure interface (MS Word can't have in doc advertising), apps are a weird abstraction that make it easier to sneak "ads" into your workflow.
I am nearing 80% of my time in this interface, the plan is to have a consumer friendly note taking/sharing app (the best damn cross platform note taking app) that becomes the core UI experience to replace existing OS interface in future. As an aside, I muse that the way computing evolved from TTY interfaces created strong adherence to single line CLIs and software engineers never really overcame that, and that's one of the core oversights of human interfaces in computing.
What one wants is the ability to query the data of another program and send external commands to that program to alter the data. The data structure itself is somewhat irrelevant, don't you think?
The flexibility of computers means you don't have to try to come up with one thing that works for everyone. Something different can always be implemented for those who want that something different.
The article would be stronger if, in addition to prescribing some macro ideas, it grounded them in a first attempt at implementation. For this new type of non-desktop computer focused on tracking fragments in an air traffic controller model ... where is the code?
The idea was that the main element of a computer shouldn't be an application but a document... and a document is a composite of pieces like spreadsheet, video, etc.
At the time, the idea was to have an open standard to replace the Microsoft apps... and to be able to replace MS apps with any other, piece by piece. It didn't work out then but, in a way, we now have a kind of open standard to build composite document (even including applications inside): HTML (with javascript).
Maybe it could be a good time to give this idea a new look?
The Applications that run on these devices also generally use a paradigm where they don't really store files but really store objects which can have Hierarchies. They do have search and some of them support a stylus as input.
Another aspect is the ability to use your voice to interact with computers which is still quite limited.
VR looks like it may offer something different eventually but it will have to be explored more.
The problem with replacing the computer 'Desktop' as a concept is that it generally is extremely hard to replace. It looked like a combination of a stream of information with the ability to search a stream or separate streams could have replaced it but we only see this in web applications (a good example is Facebook or Twitter).
Years ago I made a gadget that sat on the top right corner of the desktop[1]. It contained a stack of buttons, one for each folder that I was working on. You could add more folders by dragging them on the gadget.
It's liberating not having to keep a file explorer window to access the current project, and you can easily access it with the Windows+D hotkey that minimizes/restores all windows. Use it to open files, or drag stuff to/from other open applications.
[1]: The magic incantation was:
Personally, I have the complete opposite strategy:
Using Windows file/folder security, deny yourself access to your own 'Desktop' folder. Not only does doing this prevent you from lazily dropping/saving files onto it, it also has has the added effect of hiding ALL the desktop icons, so you end up with 100% clean desktop.
> Not only does doing this prevent you from lazily dropping/saving files onto it
That's the thing, it's only considered "lazy" because it's faster but the files end up in a disorganized location. By pointing the desktop somewhere more useful, you get all the speed benefits without the disorganization downsides.
You do have to weight it against your love of your wallpaper, though.
And if I wanted to hide the Preview window full of my porn for a video call (I'm assuming that's why he wants to close that Preview full of a bunch of stuff), I'd just hit f3 for Exposé or whatever they're calling it this year and switch to the desktop I keep tedious public-proper work shit on and leave Preview where it is.
Don't expect your computer to organize you. If you have a messy desk, you will have a messy computer.
Decades later, I have both a messy desktop and a messy computer. I think there is something about personal organization that, if it eludes you, it will elude your computer too. I've made peace with the fact that I will never be a hyper organized person. The best thing I can do is to put my stuff somewhere and hope that it's searchable.
For some reason it never took off. ReiserFS was abandoned when Hans Reiser killed his wife but Microsoft also abandoned it with no (known) killings involved. Something must have not worked out.
It's a very interesting idea to revisit though. I do still think there's merit in it. Probably part of the issue was how to make it work gracefully with legacy apps.
However in this kind of scenario you totally absolutely want to tag it with multiple tags. Otherwise this'll become a haystack you'll never find anything back in. I bet this was another issue surrounding implementations.
I have all the stuff I work on on my desktop. When that gets full, I move everything into a folder "Old Desktop" which I place on the desktop. Of course this isn't the first time I did that. So this folder contains a chain of many such "Old Desktop" folders :')
It leads to interesting discussions sometimes such as "why do you have a 200GB roaming profile???". Organisationally though I can find stuff back really easily. While I traverse the chain of "Old Desktop"s I see other documents from the same timeframe which brings me back really easily.
In fact more organised people are often surprised how quickly I manage to dig up ancient stuff for them. They tend to lose track of things over time, probably when they move to a new PC or file hoster or whatever. I've really become the "Do you still have that inventory from 2007?" guy at work. I see no reason to change it at all.
I use a fast, local search app to find things sometimes. Often, I only need the time, place, project though.
Conceptually, it's easier to think of "music from high school" than about the specific mix of subgenres from my playlist back then. Same for documents that I saved. Those ICQ logs from high school are there. They don't belong in the same folder as the stuff I wrote yesterday, even though they could be of a similar nature.
Why can't you? Well, for one, social media companies don't want you to save stuff locally, because they can't serve ads with local content. Furthermore, browser APIs have never embraced the file system because there is still a large group of techies who think the browser should be for browsing documents and not virtualizing apps (spoiler: this argument is dead and nobody will ever go back to native apps again). Finally, the file system paradigm fails with shared content; you can't save a Google Doc to disk because then how can your friends or coworkers update it? It's much easier for Google to store the data on their server so that everyone can access it instead of you setting up some god-awful FTP-or-whatever solution so that your wife can pull up the grocery list at the store.
I'm hoping the new Chrome file system API will bring a new era of Web apps that respect the file system and allow you to e.g. load and save documents off your disk. However, this still won't be good enough for multiplayer apps, where many devices need to access the same content at the same time. I don't know if there is any real way we can go back to the P2P paradigm without destroying NAT - WebRTC tries but WebRTC itself resorts to server-based communication (TURN) when STUN fails.
This is it right here. Our entire world and notion of the internet is based on serving data stored in a file from one person to another. Once the developer started drawing too many conveniences and started to "move fast and break things", we thought it's good enough to just store everything in a database, or serve it as Javascript. These technologies are great, but they go completely against everything our computing paradigm stands for.
I just did my taxes and figuring out what to pay was just a single select over some tables in the paypal and various per-bank schemas + a schema that had a table of currency conversion rates from our central bank applicable for each month of the year for tax purposes, expected by the tax man (or woman). Quick and easy. I don't even bother with UI, for these once or twice a year needs, just like I wouldn't bother with writing UI for some mp3 conversion task. Just a simple script will do.
Filesystem is great for arbitrary data/files with no schema. Random pdf files, code, programs, etc. But anything that has some obvious schema and comes in large quantities and perhaps needs to be modified/synced with third party data source, I like having such things in the database. It's so much more useful that way, because it's much easier to do something with the data.
A filesystem is a database.
Fundamentally, it's not the files that make filesystem great. You could devise different models, perhaps a relational one, and paper complexity over with well-designed UIs. They'd probably still be more complex than the filesystem - files are about the simplest data storage abstraction you can invent[0] - but they'd be serviceable, and users would learn.
What makes the filesystem great is that it's an old abstraction, designed in the ancient days back when computing was still about enabling users. Bicycles for the mind and all that. People cared about making things useful to users, instead of just shamelessly exploiting them. So, designed back then, the filesystem grants users the vocabulary to manage their data and freedom to do so, and it's so ingrained that - despite their best efforts - companies weren't able to completely take it away.
Filesystem persists for the same reason e-mail persists. Despite its warts, it's one of those technologies made before the computing industry became exploitative.
--
[0] - Despite the frequent claims to the contrary, coming from the web and mobile world. But guess what, data magically held in app and "shared" by magic isn't easier to understand, it's just not understood at all - users have no mental model for this. The mobile app approach works only because it removed all data management features except the share button.
A database is hardly if not accessible to the user. The files are an abstraction that enables the user to owns its data. Once you have a file, you can do more than opening it in your app. You can store it wherever you want, edit it with any software you wish, arrange it the way you are confortable with.
As a user, you can’t do that with your SaaS database, you must rely on the « export / share » function of your SaaS provider, hoping it will export all data, in a readable format and that the import function exists and is reliable. You don’t own anything and as soon as you stop paying your subscription, you are stuck with nothing.
The file system won't save you there.
And I prefer a "95%" correct DOCX or PSD that I can recover and rework if needed than a "0% this App is not available in the WhateverStore anymore".
Try to load a current ML model 20 years from now. Probably tied to proprietary software and if you're unlucky also hardware (like CUDA)
By now the spectrum of interactions using computers is visible enough to be able to generalize such meta-file formats. Should it be some form of database or a kind of system-level support for defining and assembling such meta-files is a question of experimentation.
It's more like an active-book paradigm vs a file, where one could tie together multiple contexts, yet being able to present it to user in some human perceivable form. Some analogies could be a project or an activity based collections of files, links, collaborations etc.
Isn't this trivial? A download button = "save" stuff from the app to disk. An upload button = "load" from disk to the app. AFAICT, webapps can already do this via existing file API's.
I think in the world of app stores this is a little odd to argue. Native apps on the desktop do seem to be on the way out, but less so on tablet and mobile phone.
Got any figures on this decline?
To be fair others exist. Element (Riot.im) saves your backup keys to disk on demand.
I agree. More of this please.
Maybe not the biggest factor, but the difference is certainly percievable.
Some people use the word native to mean "the way apps were written in the 90s and on Apple platforms, still are written". It's short hand for manual memory management, full commitment to the operating system vendor's APIs, and so on.
Apps written that way have some big advantages for end users - consistency, low memory usage, and so on. But they suck for developers. Manual memory management sucks, having your app market share be limited to the operating system's market share sucks, often the vendor APIs suck.
Some people use the word "native" just to mean "uses the operating system specific APIs". The other aspects like being written in an AOT compiled manually memory managed language don't count. For those people Android apps written in Kotlin running on a JVM are native, but the other people, not so much.
This may make sense for technical people with a specific goal, but for most users, they shouldn't care where it is saved, ala dropbox. They just want to access their files. Online, offline, everywhere, that's what they want.
Yes, but it does matter where it's saved, because the location and method confers ownership of the data. "Possession is nine-tenths of the law" is the rule of modern Internet. It shouldn't matter whether my photos live on my drive or in a third party's cloud, but it does - because in the cloud setting, the company dictates what I can and cannot do with my data, can pull shenanigans like applying strong lossy compression to uploaded photos, and they will eventually take my access away - either I cross the ever-expanding terms of service somehow, or they'll just go out of business.
In my experience of both managing my own data and helping non-tech people, filesystem vs. cloud data durability is really a wash. People seem just as likely to lose their local data due to drive failure or accidental deletion, as they are to lose access to the cloud storage (or have the company disappear from under them).
This i do not understand - mobile and web content has easily been monetized for a long time now, why would desktop software be any different?
For example, i use software called RaiDrive for mapping network drives on Windows (https://www.raidrive.com/). In their free version, they show ads on the main app window after you open it.
Why isn't this the norm on desktop - ad supported but free software? Why aren't there ad networks for desktop apps like there are for mobile apps and web content?
Good lord, please, no. Desktop adware should remain a bad dream from the 90s and early 2000s. It ruined software like Opera, and was often bundled with spyware.
I'm glad advertisers mostly embraced the web, where I can run their code relatively sandboxed and easily block it. A desktop app has much less restrictions over the resources it can access, so allowing software that actively wants to track and manipulate you to run in that environment doesn't seem like a good idea. The fact it was acceptable in the 90s with the complete lack of security of the popular OSs of the era is a bit nutty, and while modern OSs are much more secure, I still wouldn't run anything ad supported. F/LOSS or paid apps only for everything under my control. Subscriptions are tolerable in some cases.
Wait, I hate ads as much as the next person, but how did they ruin Opera? Opera was originally trialware-only, then for several years replaced the trial with an ad-supported version (with the full version still available for purchase), and then became entirely freeware.
This was also done in other software like Go!Zilla and it made the UI unusable IMO. It was a very disruptive and obnoxious way to monetize a project. Not sure if they improved this later before the move to freeware, since soon after I switched to Phoenix/Firebird and never looked back.
Is it a matter of differences in cultures, that people don't seem to mind ads as much online, or perhaps there'd be backlash from OS app distribution channels, were devs to attempt to monetize software in the Windows Store for example (I don't really use UWP apps so no idea), or perhaps it's something else entirely...
That said, I feel like the option not even being there is limiting in of itself. Suppose I'm a developer who wants to create software that's free to download and use, but ad supported. Now I cannot possibly do that. As for those who would prefer no ads, there would always be the possibility of a paid version with no ads, the possibility of altering the hosts file to block ads, or possibly downloading the source code of the app, removing the ad integration code and compiling the app themselves.
Though there are also interesting technical aspects as well, such as us not being able to sandbox most native apps (short of AppImage and Flatpak as well as Snaps, but even then there are other challenges), which may contribute to spyware in desktop apps. Plus I bet there's a large difference between showing an ad in an app and being able to mess around with the OS default browser settings and so on...
My guess is because the desktop model doesn't assume live internet access. My understanding of ad networks is that they involve a live bidding process against interested parties at the moment you load the page. This allows integration of live geo data, what you just searched, what you just looked at previously, etc. And you don't need to reconcile what was served if an app goes offline then rejoins for charging the advertising account.
I agree with your post in general but not this. I see a lot more interest in self-hosting stuff lately, precisely because of the concern you mention that online services do ads and tracking. More and more people seem to be doing this.
And I personally really prefer native apps over web apps or electron stuff.
Self hosting is hard because ops is hard [1]. People aren't yet in the mentality that you should provide an official modular deployment every time you provide a server binary. Everything-as-a-container wouldn't be the worst way to take the desktop [2]. Isn't that kind of how Apps work on OS X?
[1]: The ironic part is that most people don't keep anything long enough for a hard drive or any other component to fail anymore. So the argument about the cloud abstracting away the physical hardware maintenance for every day consumers like yourself or I is ... dubious.
[2]: Yes.. I just spent the weekend learning nix-build. Goodness, it's super easy to container all the things! :) I'm feeling like a zealot when I start using nix to do what I could have done with a zip file. But there's something magic to having a zip file of assets with its own shell.
Yes this is kinda how apps work on macOS, but not all apps yet. The new sandboxed container model isn't mandatory yet. Some apps are just a folder of files with no kind of containerisation at all (other than the .app itself being a folder rather than a file). More modern apps store all their data in a containerised filesystem though.
It leads to some cool things you can do like easily capturing the icon of an app or even changing it without having to change the app itself.
But on the self-hosting side, docker is making big strides there. Almost everyone deploying something like Home Assistant for example will do it through a tree of managed docker containers, in many cases without even knowing it :) It comes with a supervisor (which is also dockerised) which manages that part very well.
I think most consumers I know keep their computers for long enough by the way.. Phones come and go, but desktops and even laptops tend to stick around until they do break and I can't fix them anymore or just heave a sigh and go like "NO this time you really have to get a new one, Windows Vista hasn't been supported for years"
Docker is only part of the puzzle. Even being proficient with Docker (and running services in a traditional way), there was always a big barrier to self-hosting for me in networking. If you lose all of your cloud-equivalent functionality once you leave your home network, it isn't a realistic alternative. I'm not a network whiz and the builtin VPN functionality of my NAS is sadly not up to par either.
In comes Tailscale[0], which made it dirt easy to self-host my stuff and have it available anywhere (given there is a Tailscale client for it which has been the case for all my devices). Since I started using it, I've completely migrated my contacts, calendar, zettelkasten (Trilium) to self-hosting and started some home automation projects. For someone who tried and was stuck at the networking part in the past, it truly is a game changer (and I'd like to think I'm not the only one that is held back by that).
[0] https://tailscale.com/
There's also ZeroTier and Nebula. Mesh VPN is definitely here to stay!
Hypothetically in a future where self hosting is non hostile, will you see people self-hosting startups and the like? Yeah, maybe feasible. I think at that scale you start to care about things like uptime and maintenance. But I think the biggest winner to self hosting is the photographer who saves $5/mo on the blog that people rarely read or the kid who doesn't have to pay $10 to play Minecraft with their friends, or the family friend with 2TB of family data that doesn't want to pay $20/mo for Dropbox or the like when they already have the hard drive to store it. Yes it needs to be simpler for these people! There's a whole economy in making it difficult for these!
I guess none of members of your mentioned groups will ever grow to care about a scale. And thats a good thing because they are distributed. And i think it creates a better internet, which is kind of wide network instead of shallow graph of couple mega nodes.
So, I think, the ideal situation would be to have a combination of big and small companies offering storage and compute as a commodity. You'd pay a fee to keep your stuff hosted somewhere; any time you see a better offer, you can migrate to a different provider without much hassle, and with near-zero downtime. Cloud services would work by shipping their code to your data, not the other way around[0]. And if you were so inclined, you could just build your own infra, or even buy a turn-key "self-hosting in a box" kit.
Pieces of that vision are already here. Compute providers are plenty. You can order "self-hosting in a box" kits. Internet architecture makes everyone's computer equal (at least in theory, ISPs mess it up with NAT, and their T&Cs). The only thing missing is the part where you own your data, and SaaS vendors serve you - the bit that makes SaaS truly be Software as a Service, instead of Serfdom as a Service.
--
[0] - Preferably with homomorphic encryption preventing SaaS vendors from putting their hands in the cookie jar, if we can get that to work without creating another blockchain-level environmental disaster.
Regardless of what you use for hosting your own stuff, if you want to use a third-party SaaS as a user, they own the data. Want to make a document on Google Docs? That document lives on Google's servers, it's forever tied to their service and mined by them. There's no artifact you can hold on to, other than your user account.
What we need is a system where the data for that Google Docs document lives in a place you control - be it your own hardware, or some hosting you rent somewhere. It's the SaaS that should come to the data, and operate on it there. That way, if you lose your Google Docs account, or decide to edit the document with something else, you actually have that document, in its canonical form. Same for all other SaaS.
And there is your niche right there. Individual companies or persons do not need to make 'dents in markets' all by themself. A host of people doing the same might. But for the individual - especially when having sustainable income objectives, not hockeystick growth - there's a good place in the market I think.
Huh, is that not a thing anymore for startups today? In my experience, starting in 2003, across two companies, was that if you need any service fast and on the cheap, you're forced to host it yourself. Run your own mail server, web server, DNS, server housing, all the web apps, etc. and of course spend most of the day developing your actual product. Have the hosted options actually gotten so cheap and reliable these days? Is it a mindset thing?
My gripe with the cloud or SaaS solutions I've used over the years is always that management of them and backup is difficult tending towards impossible and without those you can't rely on these services, it's just voluntary vendor lock-in. When self-hosting, your actually (forced to) learn how they work and be able to fix them. Self-hosting, to me, is the simpler, more reliable option, if you depend on a service for your business and it enables you to get it fixed yourself, when it is not working. It doesn't prevent you to out source the work, if you have the money, but worst case, you still have direct access to your property.
With the hosted options, in my experience, you get all these fancy promises on availability and it being the latest, smartest tech and then the service is down for half a day, your data got restored from days old backups (if at all) and there is nothing you can do except tell your customers that "were sorry and working on it" while you wait for it to come back. :-(
It's not unheard of for the same thing to happen with in-house systems.
The difference is that you may have a wider range of options to avoid and respond to any outage if you run things yourself. That seems to be a rather theoretical advantage though. Every time there's a new ransomware attack, it's always those in-house deployments that are hit hardest and take the longest to recover.
I think under optimal conditions self-hosting is superior. But conditions are rarely optimal. As soon as you have to convince non-technical management to invest in non-productive necessities or in contingency planning you're already in a sub-optimal position.
The real problem is who owns your data. Because if you use Word or Photoshop, your files are locked inside Word and Photoshop. And this is still true if you use FOSS alternatives, because there's only very limited support for metadata-aware sharing between applications of all kinds.
It would be super-useful to have (for example...) seamless links between text editors, web design applications, web hosting systems, and even video editors and ebook publishing tools. But that's not where we are now. There's some limited interchange, but most cross-domain transfers are difficult and fragile, and some are impossible.
Cloud is just the online version of the same model. When you have proprietary control of user data through proprietary file formats which actively frustrate open sharing of data between applications, it doesn't matter of the data is stored locally or in the cloud. It also doesn't matter if you're using a mobile or desktop UI.
The FOSS people have always been looking through the wrong end of the telescope. The real revolution would be open data which is wholly and exclusively owned by users (or user groups for collaboration) and loaned to proprietary software for specific limited tasks.
Which is the opposite of things work now. Applications and products own your data and they let you access it - but only if you ask them nicely. And - increasingly - if you pay annually for the privilege.
So containerisation or self-hosting or whatever is a non-solution unless it also gives data back to users.
Which is also why the fragments idea won't work. There's limited use in trying to automate or manage or otherwise AI-ify access to data that you don't truly own anyway.
In fact a new kind of shared Internet would be a very useful thing. But it would need a ground-up redesign of everything, including browsers, mobile apps, desktop applications, operating systems, search, and the financial and legal frameworks surrounding them.
I'd love to see that happen. But right now in 2021 it just doesn't seem likely.
How would that work in practice? By its very nature open data would also be accessible to proprietary programs although the reverse need not be the case.
Seems like we will need open data and code. Either one open will not do.
Edit: I envision it a bit like streams of data that you can subscribe / push to. Think RSS mixed with a pub/sub type of model. You would subscribe to the hackernews datastream, and submitting articles and comments are done using push. The push message would have some predefined metadata fields that are obligatory (article url, title, summary or comment text).
Can you imagine if Android licensed iMessage instead of building Hangouts? Yes, we’d all be texting on the same protocol, and yes we’d have a choice of clients, but at what cost?
That is a good thing. If program X works best on my data I want to use it. There are a few examples where people do mix programs from different companies. Musicians use MIDI to connect their favorite keyboard to a synthesizer from a different company all the time - sure it is tied to hardware, but it need not be and is a perfect example of what should be possible for any user data: mix and match.
> although the reverse need not be the case.
It doesn't have to be, but if users demand it, it will be.
> Seems like we will need open data and code. Either one open will not do.
Open data means we can create the code. Closed data is a lot harder to deal with than closed code.
When your data is complex, the processing done to it will be complex, especially if you need to guarantee invariants (eg. referential integrity or database constraints).
Previously discussed here: https://news.ycombinator.com/item?id=24027663
Where do you see this?
> More and more people seem to be doing this.
Which people?
My money's on your anecdata being 100% from a techie bubble.
In reddit, colleagues around me etc. Hacker News posts/initiatives. 2-3 years ago everyone was all "Hey look at my new Office 365 setup". Now the cool new thing is more self hosting, often driven by a desire for more privacy. There's also new businesses around this usecase. Look at https://www.beeper.com/ for example. It's a hosted matrix service but all the bridges containing your private data are self-hosted.
> My money's on your anecdata being 100% from a techie bubble.
Absolutely. But this is where things start before they get mainstream. Things pick up traction here. Then they mature and commoditise and make their way to the mainstream.
1. Where is the money in that aka is there more money in that than in services?
2. Will it be braindead easy to use?
My money is on no and no so I don't see how the chasm crossing will happen.
Not with that attitude it won't. Yeah. 90% of tech offerings only work based on monetization and hostage taking of consumer data. Normal people are starting to pick up on this. All the techbros looking to score that hot, sweet -aaS money are blind to it and desperately hoping their market dominance and spend can keep people from digging through the native computing stack.
Need end to end encrypted file transfer? VPN and NFS is your friend. Need chat? IRC, at your service. Also exposable through VPN, so you can limit the audience. Want Doc updates where your secrets and in progress stuff is guaranteed to not get pored over by some intern or Admin somewhere? See above. Want no bloody ads and not to be snooped on? Set that stuff up homey. I've got a young'un whose mind is blown away at the fact games used to even exist that didn't need n internet connection.
The desktop metaphor is fine. What isn't fine is the normal person's technical education/on ramping. The old approach was teach programs first, then the protocols and problem classes they solve. Now it seems to stop at just teaching programs, because there is so much out there that is doing the same exact thing, but different branding, there's never enough time to dig into what is going on under the covers.
There is also I can store all of the files on my own computer. I don't need to store them elsewhere, except to make backups. I use DVDs for local private backups. For public files, I also store them on DVDs, but also on other internet services (such as chiselapp), too.
There are many computer games that don't need internet connection. Some of them, but not all of them, are designed for older computer systems such as NES/Famicom, which can be emulated on many computers, so it doesn't matter what operating system you are on, it will likely work.
Better documentation is helpful. Describe the program, the protocols, file formats, etc. This is how to learn working with computer. Other programs doing same kind of things can differ in many more ways other than only the branding though; some have different features, source code availability, etc.
Just.. no. Please stop pushing IRC. It's had decades to evolve and still today lacks really basic QoL things like a good mobile story (always-on connections won't fly, bouncers are limited hacks), permissions, or user registration that doesn't look like an 80s xterm.
Matrix is carrying that torch now. IRC is an evolutionary dead-end that will only ever be used by techies.
Always-on can fly. Blame Apple for shitting on that idea.
Ahaha, I don't touch web apps unless I really really have to. And even then it's lighter stuff, like chats. Can you imagine using an actual productivity application in the browser?? No thanks. The thought that Slack/Ms Teams/Discord all run slower than MSN Messenger did in 2005 despite my having a computer ~50x more powerful is depressing enough (and each of them consuming as much RAM as I had on my desktop back in the day!).
I'm not sure what type of applications you're referring to, but if you're including word processing in that, then I can't imagine not using either Google Docs, or whatever might one day come along and be a reasonable alternative. If I'm using a word processor, it's because I want someone else to be able to read and, quite often, contribute to what I'm creating. That is far, far less painful using Google Docs than Pages or whatever the alternative might be.
> If I'm using a word processor, it's because I want someone else to be able to read and, quite often, contribute to what I'm creating.
Well, the vast majority of things I write, I write by myself. When I have to collaborate I (begrudgingly :)) use Overleaf / Google Docs.
I have attempted to use vim but I just can't be bothered working out how to turn it in to VS code. If I have to decide between multiple ways to install plugins with their own tradeoffs, its already too much work when vs code just works.
1. Visual Studio
2. Eclipse
3. VS Code
Aa for 3D stuff; it looks like solid works have some kind of cloud platform. How much of the workstation load is there I don't know.
I decided to convert it to ePub, and edit it in the Calibre ePub Editor.
Fast again. Responsive.
I will convert it back to .DOC when I finish.
Can you elaborate? MSN Messenger did text chat, voice chat, video chat. I don't see what more features MS teams has that explain the order-of-magnitude increase in footprint.
The downside is of course that you pay for all of that even if you don't use it.
So like Kopete in 2005?
I know Google is not like most places and that a lot of web apps suck, but when the web apps work well, it's pretty nice, at least for my workflow
I can't, yet many people do.
And oddly, if we consider it an IDE (I would, if the relevant extensions are installed for whatever you are doing), it seems to use less resources than most of the others I use on a regular basis, while seeming more performant. It's really an odd app.
[1] https://insights.stackoverflow.com/survey/2019#technology-_-...
Sometimes I just close my browser, because to many tabs have built up. I also want a Dock icon, PWAs and Electron apps will provide that and allow normal cmd+tab to work.
PWAs are worse than Electron apps, because they die when you exit your browser. Google Chat is the worst, they had a standalone app, but now it's a PWA. So I either have to have Chrome running (a browser I don't actually use) or a window or tab open with the web-version.
Electron apps are generally fine, from my perspective, they use more RAM and don't feel completely native, but in lack of better options they're completely fine.
That's also why I strongly dislike PWAs, they DO NOT exist independently of my browser. They are very much tied to the browser (well Chrome), which seem illogical, given that they have their own icons/launch thingy and pretend to exist as their own process.
I get that Electron and browser based apps work more or less the same, but I interact with the two types applications in a very different way. That's what I care about, the interaction, the underlying technology is irrelevant.
Coincidentally, I stumbled upon StackBlitz [1] a long time ago, and was generally very impressed with it. It is essentially a very slick, online version of VS Code optimized for rapid prototyping, or small team projects. I could easily see people working with it as a main IDE. The argument then would be whether your browser of choice provides a nice enough environment for it to rival your OS when it comes to pinning tabs, navigating between them, etc. I would agree that it's unlikely to be an awesome experience, but with some work, it could be good enough. I mean, I guess a large percentage of people use Gmail via the web interface, and what is email if not the quintessential productivity app.
[1] https://stackblitz.com/
Have you heard out The holochain framework?
FTP is no good. There are better protocols, such as HTTP, Gopher, Gemini, Plan9, etc. I had made up a file format for serving directory listings by HTTP (but I don't know how to configure Apache, or to write an extension for Apache, to be able to use it).
About "who think the browser should be for browsing documents and not virtualizing apps", it is badly designed for virtualizing apps. (I have thought of some better ways.)
Also, the file system paradigm does not fail with shared content; you could have the program to mount a remote file system and then access it using local programs, if wanted. (You can then also easily to copy files between your computer and remotely, in this way, by using the standard operating system commands for doing so, and will work just as well with command-line or GUI. Similarly, for SQL databases, you can have an extension to expose remote data as a virtual table, and you can then easily copy data between locally and remotely.)
Sounds good. Where is such program? This is surely not a very novel idea, but where is it?
Hint:
- remote file systems suck. see: sshfs
- the feature set you think are important are maybe not important enough to that many people
https://mountainduck.io
https://cloudmounter.net
https://www.expandrive.com/desktop/
https://github.com/pranavmk98/gDocsFS
Every office in the nineties. Windows 95 + Office on the desktop and a Windows NT Server sharing the files. I'm not saying we should try and wind the clock back but it was a solved problem.
https://github.com/rclone/rclone
WebDAV is actually fine for this use case and supported everywhere (e.g. you can enable WebDAV for a certain directory in Apache, map it as a network drive in Windows, and everything will just work).
But tbh, it’s underrated because of the crappy Windows implementation causing explorer to hang as soon as a fly causes interference.
It’s sad because WebDAV could have been (with some added ergonomics) the missing link between the filesystem-desktop metaphor and the cloud apps.
However, the HTTP directory listing specification that I made has been described as being like a simpler and better (in some ways) version of WebDAV by some of the other people who have seen it. (It does do a few more things than only directory listings, but directory listings is its main intention.)
Maybe, maybe not, but even then, wouldn’t implementing those be easier (for both you and the rest of the world) than creating a completely new protocol?
> It still leaves the issue of it using multiple ports.
Aren’t multiple ports only an “issue” if you assume NAT (and CGNAT, shudder) as a natural state of things?
Maybe. One the other hand, WebDav and SFTP may be more widely supported than those extensions already.
>Aren’t multiple ports only an “issue” if you assume NAT (and CGNAT, shudder) as a natural state of things?
NAT is unfortunately something ubiquitous. And the multiple ports makes FTP harder to tunnel.
If they were like cars, only bulletproof armored personnel transports need apply.
The modern Internet is basically a failed state.
If I, as an application author, can only work on data in ways that are intended and officially blessed by another application, we basically have the situation we have on mobile where everything is siloed, and the state of the art is limited by the imagination individual application developers.
BTW both Safari and Firefox are not going to implement the File Access non-standards that Chrome pushes. They expose too much, there are no good ways to limit the exposure etc.
How about just subfolder access? Limit facebook.com's permissions to only the user/facebook/ folder.
When it asks the user for a file, can also specify the wanted access: read, write, read+seek, or read+write+seek. Requested format can also be specified, but the user should be allowed to ignore the requested format if wanted and instead specify an arbitrary file. For writes, estimated file size can also be specified as a hint, which can also be ignored. Then the user can type in a file name, or for the non-seeking modes, a pipe is also possible. For write non-seeking, the user can specify append or overwrite. For seekable files, a pipe is not valid. For writing to files, the user can also optionally specify the maximum size that the file is allowed to have.
That's why I just don't do that first step. The only connection between my current smartphone and my work is some TOTP keys in the authenticator app, to enable more convenient login to some cloud services the employer makes us use. I talked with a co-worker recently, who made the mistake of installing work communications on their personal smartphone, and they very much regret it - not because the company is exploiting it, but because they can't discipline themselves to not check business messages after work.
But for sure, other solutions work better if you have less stringent security requirements.
I think it's time for NAT to go for residential ipv6 and the numbers I've seen show that TURN isn't required for most connections. Unfortunately universities and businesses will probably never remove NAT as there is limited incentive to do so.
I think the best we can do is have somewhat decentralized networks with limited yet trusted centralized authorities (the need for discoverability will always remain, even when using otherwise decentralized networks like SSB). This could be IPFS with bootstrap nodes for their DHT, or as I have been using to circumvent NAT when latency is unimportant, Tor directory authority to host ephemeral, local onion services.
Just curious, does anyone know of any hybrid file formats that store information both locally and online?
It seems like one solution to this problem would be a document that stores an editable copy locally and a revision hash in its metadata, then decides whether to serve up the local or cloud copy depending on whether the user is connected to the internet.
Sure, this could cause conflicts between online / cloud files if someone else edits the file at the same time as you, but that's true of any cloud sync service like iOS Notes.
I guess in retrospect I'm just describing Dropbox which, while it's more a container for standard files than a file format in itself, has largely the same effect.
A very insightful comment up thread observes that filesystem-centric computing worked for as long as collaboration was very limited. Once apps needed to move beyond that to collaboration at a finer grained level it fell apart and apps started needing databases, and in particular, databases that could link data from different users together, implying a shared privacy domain.
Was this change inevitable? The long since exiled and forgotten Hans Reiser wrote about this problem a lot back in the day (he murdered his wife and obviously his ideas lost any traction at that point). His thesis predated a lot of the concerns about privacy and central control that we see today, but briefly, he argued a part of why this was happening was that filesystem technology was not good enough because it couldn't handle very small files and because POSIX had some unnecessary limitations. Due to this lack, apps were constantly forced to invent filesystem-within-a-file formats, e.g. OLE2 and OpenDoc were both centred around this concept, SQLite obviously is one too, ZIP yes, but really most file formats can be viewed as a collection of small files within a file.
The idea was, if you upgrade filesystem tech, you can radically change how apps are written.
The problem is that operating system tech on servers and desktops has been stagnant for years. Microsoft and Apple lost interest in their primary operating systems and the open source world has never really been interested in going beyond 1970s design ideas, largely because cloning and adding small elaborations to commercial designs is the way the community stays unified. Look at the mass hysteria that followed systemd, which is one of the only upgrades to the core UNIX OS design patterns in decades. Actually making changes to the core of POSIX isn't something that's going to come out of that community. It'll probably take some company that wants to innovate on the core ideas again.
> Just curious, does anyone know of any hybrid file formats that store information both locally and online?
I'm sure there are better ways to do it, but MS Office can, AFAICS, at least kind of do that: Documents stored in -- wossname, OneNote? SharePoint? One of those, I think -- can be edited in-place by Office Web apps, or downloaded for editing in the regular desktop apps and then saved back on-line and/or locally. If they can do that, I'm sure other apps can also do it (and probably better).
Then don't. Software was plenty profitable when we were just selling licenses.
I still hate Figma though. It's too primitive and I'm sick of being given Figma links where the necessary resources are 50% chance not isolated, or not vector, or not exposed at all.
Sure, most clients let you automatically save logs, but they were just text files you opened in any text editor. They weren't in a special IRC format, and you didn't open them with your IRC client. Hell, you couldn't open them with your IRC client. There's no reason you can't just ctrl-C a bunch of stuff out of a Slack chat and ctrl-V it into your text editor. Only difference between that and IRC logging is that you have to do it manually.
Of course they are! Using anything other than text files to store chat logs would be idiotic. The main point is that slack is a user-hostile application that does not even allow you to do that. Why people put up with this is beyond me.
Right, my point is why doesn't Slack do that? Then you could use `grep` or `find` to search across all your messages and avoid paying a monthly fee to access your entire message history and...oh, right.
I'm not particularly keen on Slack but suggesting search would be better locally is plain silly. Search is obviously better done at the server.
That ignores the possibility of the data being synced between local system and the server. Slack is already in the cloud, so cloud options are on the table. And so is syncing data.
> suggesting search would be better locally is plain silly. Search is obviously better done at the server.
The reverse is obvious to me. Slack search, like all web SaaS search tools, is really bad. I could do better with grep - and it would work faster, and I could actually trust that it searches through all the messages, instead of giving me some eventually-consistent view into results of a query that is only tangentially related to what I requested. And they wouldn't be able to tell me which properties I can or can not search by.
And I'm not talking theory - in the past, I did some spelunking in many years' worth of IRC logs in a folder on my drive, and the experience was much better than searching for anything in Slack.
Yes, that's exactly the point. You owned this data, you could do whatever you wanted with it, and it was stored in a format that was both trivial and most fitting for the data stored.
> Hell, you couldn't open them with your IRC client.
I'm pretty sure you could in some clients, and some definitely pulled stored logs to backfill the chat after restart. Though I haven't done that myself (instead I relied on a bouncer to supply the backlog on connection).
> There's no reason you can't just ctrl-C a bunch of stuff out of a Slack chat and ctrl-V it into your text editor. Only difference between that and IRC logging is that you have to do it manually.
That's a world of a difference. In Slack, it's painful to do, and if you haven't done it when you first saw a message, it's going to be even more painful to do after the fact.
Oh god, please, no. I don't really understand the disconnect between your love of filesystems and yet disdain for native apps. The exact same arguments apply; can't serve ads locally, don't autoupdate (a feature! they rot slower), can access any time, don't need a network.
Why would you want a webapp? Because it has flashier animations and SVG? There's a long conversation to be had about this, but the summary is no, no, god no, please give me back my native applications with drop-down menus and boring file picker dialogs. As long as they have decent keyboard shortcuts, I'll manage.
For example: ability to serve ads, autoupdate, AB testing, tracking
Maybe those things are bad for you but are they bad for the people who make the product? No, they're pretty good things for the company, maybe even expected in 2021. Your preference against those things doesn't change that fact
I do. It's a chunk of my life. These are memories. Much like a paper journal and paper letters I may have been writing instead.
https://ngageoint.github.io/geopackage-js/
I don't see this. The native program ecosystem is alive and well as far as I'm concerned. All the programs on my computers are native, despite noone "going back".
> Finally, the file system paradigm fails with shared content; you can't save a Google Doc to disk because then how can your friends or coworkers update it? It's much easier for Google to store the data on their server so that everyone can access it instead of you setting up some god-awful FTP-or-whatever solution so that your wife can pull up the grocery list at the store.
Now go and check out syncthing, you're in for a really good time.
Right now this is not a big deal in most countries. Right now. But as the web becomes increasingly balkanized (and I believe it will) and as countries become less democratic (always a possibility) the native app with local data will reassert its prominence in people's lives.
To some extent, governments, across the globe, are already exercising this right in some form. Quite often we hear that some government has banned some app and it becomes illegal to use that app in that country.
I'm carefully optimistic!
Mobile phones, tablets and IoT native apps say Hello.
But that's really fucking easy to change, so still 90 % his fault. (Or 95, 99...?)
A good observation, but I think it conflates two different trends:
1. Some software platforms deliberately limit what data is stored on your local machine under your control
2. There's been a shift in UI/UX away from using files as a first-class abstraction
There's a good case to be made that a UI should generally hide the specifics of its data storage. As an example, it's a good thing that most email clients present the user with their emails, rather than with a raw folder of files. (Internally, the email client might make use of a database rather than a directory, so it might make good back-end sense too.) Of course, that's not the same thing as the email client being hostile to data-portability.
iOS strongly commits to this ideal, even at the expense of constraining user actions. The podcast app doesn't let you upload your downloaded podcast episodes to your desktop computer, for instance.
Aside: iOS has very poor support for dealing with files in the usual ways, to the point that you pretty much need to use a third-party app to do so. I've found the freeware Documents app by Readdle to be very good for this.
> this argument is dead and nobody will ever go back to native apps again
I agree that the web as a GUI toolkit is here to stay, but native apps are alive and well too. There's a trend to try to push users off the mobile web and onto native apps (Facebook, Gmail, reddit), rather than the other way round.
This snippet has really lit the touchpaper. A long time ago, I predicted that the world was course to deliver insta-compiled applications through a browser, as though we'd have a Visual Basic runtime environment plugin. However, we're now there, essentially, with XHR and many-megabyte JS bundles, manipulating the DOM through the browser's "widget" engine.
There's really a tipping point for each application, where the application's functionality determines where it is better served. For instance, no one's going to make a web app out of Logic Pro any time soon. However, if someone comes up with a stateful protocol to implement in current browsers, then that tipping point flips to the web for a whole bunch of applications.
EG, a video recording/playback app that allows the user to save bookmarks/timestamps. You'd need to have some place to store those bookmarks, extract frames, generate multiple resolutions for both the video and frames (for gallery previews etc), possibly add some more metadata...
It's much easier to hide the actual files from the user and give them the option to export the data in some user-readable format.
Apple is notorious for this. Everything is a soup of folders and files with hashes and .plist files. Similar story with iOS and Android.
You needn't use your real name, of course, but for HN to be a community, users need some identity for other users to relate to. Otherwise we may as well have no usernames and no community, and that would be a different kind of forum. https://hn.algolia.com/?sort=byDate&dateRange=all&type=comme...
So I think that's just the tradeoff they make, in order for HN to be able to exist. It probably gets reversed if you email the support link.