ZDoom

ramon.dexter is ultimately right. You should not have "full access" to your entire filesystem, and the only way you can get that on Linux is when you log in as root (or do "sudo"/related utility). Even in Windows the entire user document space should be in specific folders. We no longer live in 1993.

Also - if you hate compiling things - good news, you only have to do a full compile once, most of the time. After that, compiling all the minor changes is a lot quicker than waiting for a new devbuild to appear.

I don't agree on this. If I want to edit /etc/hosts from the GUI I should be able to. Sure, it needs to pop up something confirming that I want to elevate (a GUI version of "sudo"), but I shouldn't have to open a terminal window to do it.

As for suggesting anyone but a developer to compile things.. I think that's the textbook example of when something isn't newbie-friendly.

dpJudas wrote:Sure, it needs to pop up something confirming that I want to elevate (a GUI version of "sudo"), but I shouldn't have to open a terminal window to do it.

That's what gksudo / gksu is for.

Marisa Kirisame wrote:That's what gksudo / gksu is for.

And I evoke that some easy way ala shift-click the application and select "Run as administrator", right?

Some desktop environments have a right-click option to open a folder as root without going to the terminal. Cinnamon and Mate do at least, and I use it frequently. Alternatively, make a shortcut to "gksudo [texteditor] /etc/hosts"

As far as compiling I think Rachael was just referring to GZDoom specifically, since there doesn't appear to be anyone doing Linux devbuilds at the moment. It's certainly not the suggested solution for everything on Linux, nor should it be.

The main problem under Windows is that the user directory it is somehow made to feel like a hostile place to many people. On my system there's 49(!) subdirectories and directory links. The majority of these isn't even relevant stuff but confguration directories from lazy software that didn't bother to properly place their garbage into AppData where it should be (of course the same problem is just as pervasive on my work Mac thanks to some inane Unix convention that it's ok to put 'hidden' config directories into the most convenient but also most annoying places.) Another large batch is the localized directory name aliases.

And to top it off, Explorer doesn't even offer a direct link there - all it has is links to some selected subdirectories. So while on the one hand it is properly implemented in the system, the presentation of that place leaves a lot to be desired.

So yes, as a result of this I tend to do most of my work in directories that are placed right in C:\ to shield myself from that place's unfriendliness.

The user folder in windows has always felt like a weird abstraction, a fake layer over the real filesystem. Like you said, a hostile place where I don't really want to be. Compared to Linux, where /home often behaves as a root unto itself (it even can be, if you put it on a separate partition!), makes the root filesystem feel weird, obscure, and hostile. The difference is night and day.

It doesn't help at all that nobody can agree on where anything belongs in the users folder. If I were to Ctrl+F in my own Users folder and search for "Electronic Arts", I'd find game save folders in users/weasel/Documents, users/weasel/My games, users/weasel/documents/My Games, users/weasel/AppData/Local, the list goes on and on.

Yes, but that's not an exclusive Windows problem. I see the same chaos on macOS as well. I blame the OS makers because their path getter interfaces are an utter abomination. If they offered a simple function 'GetPath(PATH_TYPE)' I'd guess everybody would use it. But no, you have to call some obtuse function from some obtuse system component and pass even more obtuse parameters to get what you need (Just look at GZDoom's i_specialpaths implementations to see what I mean.) And again, that applies to both Windows and Mac. Apple even made it worse by deprecating a somewhat crusty but ultimately usable API with one of the most misguided pieces of shit I have ever seen.

TBH on Linux there is also a problem about user data folders. You could have a program store its data in a hidden folder on your home, in a folder inside .config (which is the currently enforced standard, at least by the freedesktop people), in a folder inside .local/share, or god forbid, in a folder on your home that's NOT hidden (I'm looking at you, UT4).

True, that is a problem. Overall though, I find Linux programs tend to be a little better in this regard, and I'm less inclined to show hidden folders all the time because I'm less worried about... whatever I was worried about not being able to see on Windows, I suppose.

Well, I do not trust ANYTHING that uses hidden data. In a well designed environment that app data should be stored in some place by the wayside you do not need to visit, but can if you need. But no, it has to be some stupid dotted directory right under home. I wonder who cooked up that idiotic convention. It even gets worse if such software tries to impose the stupid convention of one OS onto the others because the devs are too lazy to implement it correctly. But ultimately - see my previous rant about the directory getters - THAT'S the true root of all the problems here.

The dotted hidden file/folder I suspect came from UNIX back in the '70's (or so). "ls -a" reveals them, though, and almost any Unix-based file browser (even Finder on Mac OS) will show it if instructed to.

Rachael wrote:and almost any Unix-based file browser (even Finder on Mac OS) will show it if instructed to.

... that's why they are so annoying. Instead of being stashed away in a non-intrusive place, they are stuffing the user's home directory and making it hard to navigate.

I'd prefer to have all that stuff under ~/config myself, rather than ~/.config and various ill-behaving ~/.<name of program>s, but it's out of the way enough most of the time.