It's so cool to hate on Ubuntu, but it's the best desktop linux experience. You did yourself a disservice.
What shines for linux is the package manager as a 1rst class citizen. I've had all sorts of issues with `brew` and no issues with `apt`
For a work machine, it comes down to reliability and a hassle-free experience for me.
The other one is the limitations of the Finder. There are better third-party apps but they don't integrate as first-class citizens.
Last time I used Solaris, around 2004, it had single application packages, like rpm before yum, meaning I had to manually track down the dependencies from Sun repositories.
There's nothing really bad about Finder. It's just sort of meh for a tool that one uses all the time.
This tends to show up if you're trying to tweak/customize preferences (e.g. from the command line or editing plists directly), since you usually have to duplicate the effort for both places.
Even to call it a "system" dialog is misleading, since it's just a system-provided library that each individual app is, technically, free to use or not use.
I certainly agree that it's annoying when the look, feel, and fucntion of all the apps' common interactions don't match each other. I do recall a time, though, when the system library features were so anemic, that I was actually glad of app's departure from the norm if it provided a useful new feature (e.g. "New Folder" button in a "Save" dialog).
I also agree that makes the suggestion of "use a Finder replacement app" not a solution to your real problem.
Maybe I'm suggesting that, to a nerdy-enough audience, you might have to state your real problem as being with "the Finder and all the system provided file-picking dialogs other apps tend to use".
1. Try to dragndrop content from a child folder to the parent folder. There is a very VERY small area at the top of the window where you can drop your files. (got worse on 10.13)
2. Transfer of multiple files (multiple actions) is not managed successivly but simultaniously.
3. Constant loss of sidebar content, i.e. mounted drives.
4. Info about folder/s inconsistency: Open info for one folder 'Cmd+i', for multiple folders 'Cmd+Alt+i' if you want the overall size (and it doesnt' get highlighted) | Close info window for one folder 'Cmd+w', for multiple folders 'Cmd+Alt+i'.
5. No option to edit file/folder names in Save As... dialog
6. Save As... dialog again: click on a file by accident and your initial file name is gone.
7. I don't understand how people can use the columns sorting but that's personal taste I guess.
8. Missing native window snapping (half size, full size etc.).
MBP 2009 OS X 10.11 & Hackintosh macOS 10.13.4 and my background is years and years of M$.
There are things I love about the Finder, too. :)
MacOS descended from NeXT, which had Application Bundles, but even before that MacOS Classic did the sensible thing and just used folders. You want to install an application, you just put the folder somewhere on your disk. No library conflicts, no web of dependencies to break, and it integrates easily with the file management metaphor personal computers have had since forever. Want two copies of the same application, but different versions? No problem. Want to move the application to another disk? No problem. Uninstallation is one delete away. Want to put it on a floppy and take it to a friend's computer and run it? You get the idea.
Turns out you don't need a package manager unless you intend to over-engineer application management to the insane level that the open source community has.
I almost wrote and didn't, but it's also true, that app stores (whether iOS or MacOS) are also effectively a form of application virtualization/package management.
>Turns out you don't need a package manager unless you intend to over-engineer application management to the insane level that the open source community has.
You don't necessarily need a package manager, but you can't solve the problem with simple folders either.
A.k.a drivers. The app is just a control panel. MacOS classic used "extensions" for this, which were basically just app folders you put in a specially designated folder.
So the modern version of that could just be dropping a folder into a special location there kernel knows to search for drivers, and include a control panel app.
> Or the app itself is a shared library.
A.k.a not an app at all. Shared libraries only really make sense as part of a stable base system that developers can target and depend on, otherwise you get DLL hell and require something like a package manager and all its associated limitations for basically no benefit at all.
If your application uses a library and you don't want to compile it statically, just include a copy in the app folder, secure in the knowledge that it will never cause a conflict or break your application due to an update or some other application replacing it.
> Or multiple users on the same system use the app, etc.
Desktops, a.k.a "Personal Computers", don't really have much of a multi-user use case. They did briefly in the time after the internet became a big deal but before smart phones were invented, but that time is over. Know what we did on Windows 98? We just shared the system, it wasn't a big deal.
Even so, it's not like you need two copies of the application to have two different configurations.
None of this is anywhere near as complicated as the people who promote it like to pretend it is.
Do you mean the kernel is going to load random files from a user writable location? That sounds like a security nightmare TBH. Also, then you can't safely lazy-load kernel drivers because you never know what the user has done to the folder. Or if the OS has to lock access to the folder then the user has no feedback as to why they can't "uninstall" stuff by simply deleting folders, etc, etc. There are dozens of problems. Turns out, people have already thought over those problems and proposed solutions :)
>otherwise you get DLL hell and require something like a package manager and all its associated limitations for basically no benefit at all.
You claiming there is no benefit to being able to install/remove/update third party shared libraries doesn't solve anything.
>just include a copy in the app folder, secure in the knowledge that it will never cause a conflict or break your application due to an update or some other application replacing it.
That assumes you have the rights to distribute the library and that the library is small enough.
>Desktops, a.k.a "Personal Computers", don't really have much of a multi-user use case.
Maybe not for you. For millions of other users, its a very important use case.
>None of this is anywhere near as complicated as the people who promote it like to pretend it is.
Well its certainly not complicated if you re-define the problems as non-problems.
On a server, sure, but on a PC? It's their computer, they should be able to do that. You're confused because permission systems on Desktop OSs are currently based around user accounts, which is silly. If they were based around applications instead it wouldn't be a problem.
> That assumes you have the rights to distribute the library and that the library is small enough.
If you don't, then why is your application using it? As for size, multi-GB applications are pretty common. It's not libraries that bring that size up, it's assets. Some applications have icons larger than most libraries. Otherwise, if your application isn't valuable enough to be worth the size of that library, then maybe you shouldn't use such a huge dependency in the first place.
> Maybe not for you. For millions of other users, its a very important use case.
Apparently not one you're willing to elaborate on. Besides, as mentioned, I believe there are better and simpler solutions to the problem than package management. In fact, how the hell does package management even help here?
A user-writable location should never be used to load kernel modules. This is a privilege escalation vulnerability.
>You're confused because permission systems on Desktop OSs are currently based around user accounts, which is silly. If they were based around applications instead it wouldn't be a problem.
I prefer to deal with the real world design of operating systems rather than imagined ones.
>If you don't, then why is your application using it?
Using an API doesn't give you distribution rights. Copyright law assigns that to the creator of the application/shared library/. Depending on the license you will get different rights to either include a copy of the library, include a separate installer of the library, let the user install it separately, etc.
In other cases, patent law can disallow distribution. To give you an example off the top of my head - MP3 encoding is under US patent law and Audacity (an audio editing software that I use) does not allow you to save to the MP3 format till you install the shared library separately and point the software to its location.
>Apparently not one you're willing to elaborate on.
What is there to elaborate on? Are you not aware that millions of computers used in schools, colleges, corporate offices, server farms, homes, etc rely on multi-user features?
Solving a general problem involves solving it seamlessly for a large number of usecases. Otherwise you end up with a fragmented system that is confusing.
I would prefer they solve it in a perfect manner with perfect compatibility and perfect code with zero bugs, but they wouldn't listen to me. ;)
> I believe there are better and simpler solutions to the problem than package management.
Okay?
In any case, your folder based idea doesn't solve many of the real problems that users and creators face w.r.t. distributing, installing, and updating software. Before you reject them, its worth thinking about them. Bye!
After an hour of trying to figure out how to connect to my WiFi I gave up -- I was hoping to get a non-technical friend onto Linux on her very old laptop, and I though if I as a nerd can't figure out the most basic thing, the first thing you'd want to do with the OS, well...
Still looking for a Linux for older hardware that will not completely freak out non-technie folks from a Mac background. Xubunto was the same, with better icons.
All you need to do is click on the little wifi icon in the status bar (or go to preferences -> network connections).
This is extremely subjective. I'm a full-time EXWM (Emacs as a window manager) on NixOS user and my environment is customized[1][2] to work the way I want it to.
Default desktops can work great for you if your mindset and workflow align with the designer(s) of the UI - but in my opinion it is much more valuable to be able to (note: not forced to) customize everything about your environment to slowly tailor it to your needs.
TL;DR - there's no single "best desktop experience".
[1]: https://github.com/tazjin/nixos-config [2]: https://github.com/tazjin/emacs.d
We're keeping this aura of mysticism around customized computer setups (obviously also because there's commercial interests against them).
I think many "average" people would have no greater difficulty learning a fast, simple, customizable mail client instead of Outlook for example.
Really? I feel like writing the article "The decline of Ubuntu".