>>2572
Wholeheartedly agree (although this sentiment has already been shared in a few other threads). I've never really had any issues with applications on either windows or osx. Every time I need to install something on linux I find myself either fighting the package manager or wrangling dependency hell.

And especially fuck anything that builds using autoconf and make. If that goes wrong it's almost impossible to debug. I honestly wish that people would move to Bazel or something since it's actually a sane build system compared to the inscrutable mess that autoconf+make is.

There are as many build systems as there are stars in the sky.

>>2572
>So does Arch, through the AUR. Arch is unstable as hell and for people that want to treat their operating system like a part time job. Nobody bills it as the easy option.
I feel like this is a bit of an undeserved reputation. I've been using Arch for years and the only woes I've ever remember of were NVidia driver-related (of which I'm stuck on an old and now unsupported version due to my card being dropped, which has caused additional issues of its own; but even if I weren't, the lack of a stable kernel ABI is unfortunate and the mess that has been built to work around it makes it easy to corner yourself if you don't know how the whole system interacts, though this is true of any distribution); even system maintenance is almost non-existent. The installation process is pretty simple as well, all things considered.

>So what do you do in this situation if you're using the super duper friendly Ubuntu? You compile from source.
You shouldn't; Having arbitrary uncoordinating programs spread their tentacles all over system state in an uncontrolled manner is a recipe for disaster, and it's not hard to see why. Unfortunately for you, FreeDesktop is this unholy mess of cargo-culted UNIX brain damage carried on to absurdity that expects programs to do just that, and so distributions usually delegate to package managers the responsibility of arbitrating this space and keeping things somewhat sane. Assuming you haven't clobbered anything important, and that your program managed to find it's way into the right places on the quasi-standard folder structure for your distro, and that your package manager doesn't clobber some part of it whenever, you hopefully get a working program; until some months down the line you update your system and ABI differences cause it to now fail with a cryptic error message, and repeat. And I hope whoever wrote the build system thought of writing an uninstall procedure, and that it actually works, if you ever feel like uninstalling that.

I wish GNUstep had gotten more traction back in the day, so that we could at least have had nice self-contained NeXTSTEP-style app bundles that ship with everything and are location independent and whatnot; or so I'd have hoped anyway, it's more likely it'd have ended up similar to our current "distribution-independed packaging" mess, which believes it is acceptable to ship applications bundled with it's own version of half of the operating system.

>Oh wait, what about PPAs? Finding them, adding them, it's impossible, There is no up-to-date information on how to do that shit with launchpad or whatever the fuck. It's impossibly cumbersome. It's shit.
There's instructions on adding the PPA on the launchpad's PPA page itself; not that I ever found them whenever I actually needed them, or that you should be trusting arbitrary, potentially unverifiable third-parties to package software you want out of their own good-will or something.

>I fucking hate it. I hate it so much. If you make a piece of software, DO NOT expect people to build it from source you pile of shit.
I think this is the wrong attitude. In an ideal system (or my vision of one, anyway), build, packaging and distribution machinery (not *package managers* as UNIX currently understands them) nicely handle the specifics of building and packaging software in a way that makes installing a binary package vs. building from source just a matter of something like not wanting to wait for the compile-times, and having a suitable package from a trusted source (the software vendor usually, but generating binary packages should be simple for anybody; so should be verifying trust and provenance from such packages out of the source code and whatnot). Genera's System Construction Tool is a nice, if incomplete, base model for what I'd think, even if I don't see how something of the same nature would adapt to a non-image based system (but, if we're speaking of ideals, should I?). "Purely-functional package managers" like Nix or Guix feel like a step in the right direction to me, but they're still stiff and overcomplicated, and are still a pile of hacks on top of UNIX, which is itself a pile of fossilized hacks perpetuated out of who knows. One can dream.

>>2577
>I feel like this is a bit of an undeserved reputation.
It's rolling release and "bleeding edge". One of its main selling points is that it's unstable and forces you to "learn linux". So they perpetuate that reputation themselves. I'm inclined to believe them.

>we could at least have had nice self-contained NeXTSTEP-style app bundles
Why is extra infrastructure necessary? Is it not possible to build something so every file is linked relative to an executable? That would instantly make an application portable and self-contained.

>There's instructions on adding the PPA on the launchpad's PPA page itself;
Out of date and inaccurate.
>Visit the PPA's overview page in Launchpad and look for the heading that reads Adding this PPA to your system. Make a note of the PPA's location
As you can clearly see, there is nothing like that on this page or any sub-page.
https://launchpad.net/ubuntu/+source/neko

>I think this is the wrong attitude. In an ideal system
Wrong attitude? Because I want people to do what's been proven to work instead of waiting for some hypothetical, pie in the sky solution? That's how it's successfully been done on windows for decades. Building will always require more machine resources too, so it's a waste of energy and limiting factor in adoption if nothing else. Most software on windows is built one time(per version) for everybody.

>a suitable package from a trusted source
This is the wrong attitude in my opinion. Practical freedom requires a bit of faith in other users.

Post edited on 23rd Jan 2022, 9:04am

>>2577
>undeserved reputation
From an arch user of 5+ years.

>>2580

>>2581
You know, posting PMs without consent is pretty distasteful.

>>2582
There is nothing sensitive about this information in the slightest.

>>2583
I said distasteful, not in violation of the GDPR.

>>2579
>Why is extra infrastructure necessary? Is it not possible to build something so every file is linked relative to an executable? That would instantly make an application portable and self-contained.
It's possible, but it wouldn't be standardized. Go and Rust already so similar where the default is usually statically linked single-file elf executables. This only works because they _don't_ use glibc, which for some reason absolutely hates being statically linked and will do everything in its power to throw a hissy fit if you try to do so.

So then let's say that we standardize on musl libc instead (which is already asking a lot). Great, now how will we handle gui apps – we could statically link the entire Qt framework, if we don't mind large binary sizes. But wait Qt licensing means that you cannot statically link unless you either release your own code as open source or pay some license fee. But oh well, we're making an open source app anyway so we'll just go ahead and do it. Finally we've got a nice binary, but we want to include some assets in there, and also persist a preference file somewhere. We could just keep everything self contained in a single folder, but then some segment of the linux user population will start claiming that you're violating the holy unwritten laws of the x desktop group by not spewing files into the sacred directories.

The reason why this will never happen on linux is a lack of standardization. It works on osx because you have limited choices in what to use (e.g. you only get to use their libc unless you want to make your own syscalls), and there are prescribed defaults that everyone follows (because you're incentivized to do so, and penalized if you don't). The .app container format is standardized format that you must follow if you want to be able to do code-signing for your resources (and you better do so, because in recent releases OSX will throw a hissy fit if you don't have a valid signature). Similarly you better limit your writes to the designated "Application Support" or "Preference" directory, because if you don't, the OS _will_ require the user to explicitly approve file system writes. No surprise then that the experience is uniform and predictable (it should be noted though, that even before these restrictions developers did a remarkably good job of following the de facto rules).

So I don't think GNUstep itself would really solve anything, the issue is lack of standardization that you will never get the linux community to adopt because their whole ethos and culture is against it.

>>2580
>>2579
>It's rolling release and "bleeding edge". One of its main selling points is that it's unstable
Means just that it is a lot more eager to adopt new upstream releases (which, depending on the specific project's release culture, may mean yet unpolished or underdeveloped, yes) than other distributions, but it's not like there isn't care in keeping people's systems working reasonably stably. Anecdotal evidence of course, but as I said, besides Nvidia woes I've never had any major issues with an Arch installation in over 4 years of using it.

>and forces you to "learn linux". So they perpetuate that reputation themselves. I'm inclined to believe them.
I keep hearing that and it always strikes me as odd, as "learning linux" in this context seems to me to mean installing some packages, editing some configuration files, enabling some services and maybe installing a bootloader or something (all of which the Arch wiki usually babysits you through for the most part anyway). Sure, not something I'd recommend to anybody who has never touched UNIX before, but hardly complicated, nor what I'd call "learning linux"; and there's barely a maintenance burden besides installing updates afterwards anyway. Though if you didn't found Void "acceptable", I don't believe you would Arch either.

>Why is extra infrastructure necessary?
Assuming the end goal is a desktop system comparable with other platforms, extra infrastructure would be needed anyway; you'd need somewhere to be able to specify things like the application icon, the kinds of files and protocols it can handle and whatnot, be that embedded in the executable, a .plist inside your application bundle or a .desktop file somewhere, and given the issues intersperse themselves, it feels natural to tackle resource packaging and management while at that.

>Is it not possible to build something so every file is linked relative to an executable? That would instantly make an application portable and self-contained.
The thought hadn't passed my mind when I wrote that, but I could see it working with enough discipline (and I do like the fact that this means that applications are not a separate concept, but rather just executables that happen to display a GUI). One issue I could see is that the semantics of interacting with a resource embedded into the executable could be potentially different from interacting with files (I'd imagine embedded resources would look like external symbols in your language), and that such differences for achieving effectively the same end result could discourage application developers from using them (this might be especially critical in cases where bundled resources are just the special case of something the application normally handles but happens to be bundled with it; say, the HTML files for special pages on a web browser, or source code for bundled extensions for an application). And then you have things like scripting languages, where the executable is not the application but an interpreter for the application, which is in separate source files; maybe you could have scripting languages have some sort of dump functionality, that generates an interpreter executable which bundles the source code as a resource rather than an external file, but that's yet another burden due to semantic differences, this time placed upon language implementations. More issues that crop up are probably solvable as well, but then application bundles sidestep all of them by just being normal folders, were applications ship and interact with their resources like average files, but also can (and are largely guaranteed to) behave as an atomic unit in places like the user interface.

AppImages seems to be a funny mixture of both concepts, by having executables being filesystems that ship with everything the application needs, and mount themselves and execute the "real" application when ran. But then do see my first conclusion.

>Out of date and inaccurate.
>>Visit the PPA's overview page in Launchpad and look for the heading that reads Adding this PPA to your system. Make a note of the PPA's location
>As you can clearly see, there is nothing like that on this page or any sub-page.
>https://launchpad.net/ubuntu/+source/neko
I don't believe that is a PPA; you can clearly see the mentioned heading in, for example, https://launchpad.net/~openjdk-r/+archive/ubuntu/ppa. Now, what that page is (apparently an entry for a specific package? from where?), or how you would go about "properly" installing that is a mystery to me; I haven't used Ubuntu in quite a while, and always found the layout of launchpad to be an off-putting mess when I did.

>Wrong attitude?
On installing from source in specific, because I believe that the schism between installing a package from source or from a binary is a consequence of bad system design (as in, I believe installing from a binary should just be a special case of installing from source in which the compilation phase was already done beforehand). But also
>Because I want people to do what's been proven to work instead of waiting for some hypothetical, pie in the sky solution?
That whole paragraph was more of me rambling on a vague possibility that I had considered within the context of an ideal system rather than proposing an actual, actionable solution for our current systems. I have a tendency to do that at times and do apologize if it seems off-putting or appears to derail the topic, but it seemed appropriate. I definitely do agree that Linux has the worst and most convoluted software distribution "situation" of any of the major operating systems (which mostly do work reasonably well by themselves), but disbelieve any of them have reached an ideal point either.

>This is the wrong attitude in my opinion. Practical freedom requires a bit of faith in other users.
I am not sure how you interpreted that, but I don't use the "trust" in the same sense corporations seem to have taken to recently. You choose to trust one or multiple parties to honor whatever technical expectations you have regarding the software in question (for example, that the distributor is who they claim to be, or that they are not modified in regards to the original source (or, in some cases, that they *are* modified in a specific way, whenever that is desirable), or that they do not contain malicious features you'd deem unacceptable, or whatever) whenever you download and execute precompiled binaries; this trust is currently largely rooted in faith, since there is little actionable way that the implicit assumptions you've made are certainly true in many cases (package managers do go to some effort to detect corrupt packages and automatically verify packager signatures and whatnot, which is great, but not enough), and when there is it is often cumbersome. I'd hope an ideal distribution system to allow one to allow one to easily and effortlessly verify such, given appropriate access to prerequisites (such as source code, in certain cases), and make the concept of trust in the packager (which, again, ideally, but not necessarily, corresponds to the developer) a little more meaningful.

>>2585
Actually, inability to statically link (coupled with ABI incompatibility between multiple libc implementations, or even multiple versions) and license issues do seem like more plausible concerns before what I had thought of.

>(e.g. you only get to use their libc unless you want to make your own syscalls)
I believe you're discouraged from making even syscalls directly, since the interface is unstable and changes between kernel versions. Go tried and gave up at some point, if I remember correctly.

>The .app container format is standardized
So are the equivalent components on Linux, for the most part.

>So I don't think GNUstep itself would really solve anything, the issue is lack of standardization that you will never get the linux community to adopt because their whole ethos and culture is against it.
But we *did* begrudgingly standardize on FreeDesktop, for the most part. Had that been maybe not even GNUstep, but the subset of OPENSTEP that treats of the same issues as FreeDesktop does, I do believe we'd be in a slightly better position (though still far from ideal), if only for virtue of having a better-designed model.

Post edited on 23rd Jan 2022, 4:42pm

>>2586
>the semantics of interacting with a resource embedded into the executable could be potentially different from interacting with files... then you have things like scripting languages, where the executable is not the application but an interpreter for the application, which is in separate source files
How do these potential hurdles necessitate a special application bundle structure? What I described with relative linking is how I assumed things are done on Windows software that isn't shipped as a singular, static executable, but instead a folder with a "main" executable and a bunch of other things, sometimes including other executables.

You can move that folder anywhere in your system and it will still work. You could put it on a usb, or email it as an archive and it will work on another machine. Does this being possible without anything extra come down to a difference in how the Windows kernel works?

>>2587
>Go tried and gave up at some point, if I remember correctly.
Yup, I wanted to mention that but forgot to. If I recall correctly the BSDs are also similar to osx in that the only stable interface is through the provided libc. I think this ends up working out better for both os/kernel devs and end-users, but it's obviously too late for linux (and glibc has too much momentum that switching off of it will introduce more issues than it solves).

>equivalent components on Linux, for the most part.
By equivalent components are you referring to flatpak et al.? If so I'm not sure I'd call that standardized since last I remember there was still a war being fought between snap, appimage, and flatpak.

Interestingly, like it or not Electron has probably done more for the state of linux desktop apps than all these other efforts combined. It may be a humongous bloated non-native monolith making us subservient to big G, but since Chromium basically works on all environments the electron apps it usually "just runs", it can be distributed as a single bundle, and it's easy for developers to create and share.

>>2588
Are you referring to what are conventionally called "portable windows apps", which are basically a self-contained folder of the exe and any config files needed? My knowledge of windows is not great here, but I believe the EXE itself in this case contains application resources in addition to the PE which holds the actual code. If the containg folder contains any DLLs then yes I assume they're linked relatively. But note that not all windows apps are packaged in such a fashion (indeed, I believe many require an installer tool that installs things to a specified location and thus the program isn't set up to look up dependent files/dylibs relatively).

You could in principle do the same on Linux as well, and indeed see the exodus tool mentioned above which basically does just that with some ldpath hacking. If you couple that with an application that writes its configs to a relative location, you'd basically get something close to fully portable apps on linux. But the main issue you will run into on linux is glibc as mentioned before.

>>2590
>Are you referring to what are conventionally called "portable windows apps"
Yes. I think it's the absolute best format for many kinds of programs, especially games. I love this way of doing things.

>the exodus tool
I've tried using it. If you've got musl on your system(musl-tools specifically in ubuntu), you can use that instead and it works fine. My issues with it posted above are likely because the original program didn't write its configs relatively.

Another shortcoming is that it produces an sh file, not a folder. When you run the sh script, it puts the software in /opt/exodus/, within a sub-folder that has its own /usr/ and /local/ and /bin/. The only portable thing I think is the sh script. It's not as clean or desirable from what I saw.

I'd rather people be able to write software like this in a format the OS already supports, rather than having to use a messier hack. I think Haiku is capable of this.

https://discuss.haiku-os.org/t/portable-applications/10703/5
>you could manage to find all needed libraries and copy them in a “lib” directory next to the executable
>the libraries that you put under /lib have priority when run the executable

Post edited on 23rd Jan 2022, 5:46pm

>>2588
>How do these potential hurdles necessitate a special application bundle structure?
They don't, I am silly and assumed you had meant to have *all* application resources coupled together into a single executable. That not being the case, application bundles would work just like a glorified "application folder", though do see below.

>Does this being possible without anything extra come down to a difference in how the Windows kernel works?
You can ask the linker to have the executable look libraries up relative to it's own directory first, or use stuff like LD_LIBRARY_PATH, and there is software distributed like that (Dwarf Fortress comes to mind), but it can be rather brittle, for reasons already stated.

>>2589
>By equivalent components are you referring to flatpak et al.? If so I'm not sure I'd call that standardized since last I remember there was still a war being fought between snap, appimage, and flatpak.
I was referring to desktop integration infrastructure (so things like .desktop files and icon themes and whatnot), of which application bundles do include, as well as working reasonably as a distribution mechanism; the unstated point being something like that they can be both portable and still offer things like offer to open files and protocols they can handle, and so on. Given my misunderstanding and the direction this has taken, the point is moot anyway; I do apologize for dragging out a tangent I shouldn't have and conflating 2 different (but closely related) issues.

Gotta love the community.
https://icculus.org/finger/icculus?date=2009-11-03&time=19-08-04

Post edited on 5th Mar 2022, 6:32pm

>>2626
>Generally pretty trivial on Linux
Also hilariously wrong, especially the older the software is the more likely it depends on some super specific library version

>>2627
I've been thinking about it lately, and I think "communities" are simply incapable of competently making a project as large as a desktop os.

Desktops, by nature, should not be modular. There needs to be a singular entity, with a strong vision, making decisions from top to bottom, ensuring everything is seamlessly integrated.

Looking forward to fuchsia desktops, if that's ever a thing.

I've been trying out Fedora with Gnome(in a vm). I actually like it in quite a few ways. Been probably the best experience I've had, probably more due to Fedora than gnome.

The file picker though. The fucking file picker. I just learned about it yesterday and it is one deep rabbit hole. It's not just how bad it is, and how long it's been awful, it exposes the twisted attitude of the devs. And this affects all gtk applications, not juse gnome.

They don't care enough to do something about it 16 18 years after it was first pointed out, so instead they tell other people to do it. Except, other people aren't within their circle, so getting their patches in is next to impossible. And they don't even feel like looking at patches because that involves code review. So they just say "do it yourself", but they don't ever intend to use other people's fixes. Patches which aren't added, are always playing catch-up. So you can't even fix this locally.

Instead, they just wax on about various technical hurdles and performance concerns without DOING anything, and hiding behind being a nonprofit, "volunteer effort". Why work as much as they do on it, if they don't intend for it to be usable for the most typical use cases? Their thought process is totally bizarre me.

Post edited on 1st Apr 2022, 1:32pm

>>2661
>File picker
Ah sooner or later everyone falls into the file picker rabbithole. Apparently they have no time to integrate a patch but are happy to redesign all their buttons chasing the latest flatui trends (https://blog.brixit.nl/the-end-of-the-nice-gtk-button/).

Attempting to use any linux distribution for non-cli purposes is a futile endeavor and amounts to a death by a thousand papercuts.

>>2662
KDE at least has this fixed for firefox. On another note, Chrome OS doesn't have this problem.

>>2662
>https://blog.brixit.nl/the-end-of-the-nice-gtk-button/
Change for the sake of change, or at least designers justifying their existence.
KDE isn't perfect, but I'm glad I chose it as my DE of choice.

Tried getting fcitx5 to work in kde. Horribly unstable. Someone asked about ime integration back in 2014. Guess how much that's progressed?

https://forum.kde.org/viewtopic.php?t=122114

>>2667
on kde neon
https://files.catbox.moe/21k2km.mp4

edit, I've had better luck with ibus(on kubuntu).

Post edited on 3rd Apr 2022, 1:23am

>>2665
For once, the guy greentexting isn't the biggest faggot.

Yesterday I intended on installing linux(kubuntu) and using it as a daily driver permanently, or at least I intended on trying. I've used it a lot in VMs, so I knew more or less what to expect.

It's not polished to say the least. My scaling was at 150%, and as a result the browser fonts were inconsistent. Thumbnails in the file picker were blurry, and despite installing support for jxl files in qt apps, their thumbnails didn't show up in the file picker(though they did everywhere else). Little things like that.

What REALLY killed it though was trying to get yggdrasil to work. This is something I've successfully done in a VM. Here though! Here it decided to not work, on an actual machine. And there was no information on why or how to fix it. I tried. Believe me I tried.
>yggdrasil.service: Scheduled restart job, restart counter is at 5.
>Stopped yggdrasil.
>yggdrasil.service: Start request repeated too quickly.
>yggdrasil.service: Failed with result 'exit-code'.
>Failed to start yggdrasil.

I followed the instructions exactly. I even built it from source. Nothing made a difference. It just DECIDED not to work. I don't know if it's yggdrasil's fault, systemd's fault, or ubuntu's fault. It really doesn't matter. I'm not a masochist and my patience has limits. Not polished. Okay. Things take more time and work. Alright. Not being reliable. No thanks. It's not being different. It's not having a learning curve. It's just being shit. When I tell the stupid cocksucking cunt to start the service, it needs to start that fucking service. NOT just write cryptic shit to a log file.

Posted from freshly installed windows ltsc.

>>2703
Install gentoo.

>>2704
Gentoo is actually the sanest OS. It just works, but you need to compile everything.

>>2705
I've heard gentoo only makes sense for exotic setups. Anywhere else it's needless work.

>>2703
That seems to indicate that the yggdrasil had some error starting, and so systemd or whatever tried to restart it, up until it hit some restart limit.

So in this case it's yggdrasil's fault. You should look at the logs (if there are any) or manually try to run the yggdrasil binary and watch stdout.

As a sidenote, I don't know why systemd turned out to be such a bloated mess when its inspiration, launchd, is really quite nice.

>>2707
It's already too late for that. I didn't know where yggdrasil puts its logs and there was no stdout. Also recently, something came on my plate that requires excel and VBA, so I really have no reason to go back and try again. The effort to value equation just doesn't add up for me. I get nothing out of it except a less polished experience with many many more annoyances.

Post edited on 13th May 2022, 12:22pm

>>2706
Gentoo's package management system (portage) you to enable/disable features you need/don't want via USE flags. You can also patch packages easily. Oh, and you can filter software by its license, too. So, you can install mostly free software but you can pick proprietary software on per-package basis. Gentoo allows you to also pick bleeding edge versions of software on per-package basis.

>>2708
If you want to test GNU/Linux again, you could use Windows' disk management tools to shrink the Windows partition and then dual-boot Windows and GNU/Linux.

>>2710
>enable/disable features you need/don't want via USE flags
What does a person get out of this except a bit of saved disc save and a nebulous "performance" gain? How does anything related to stability, reliability and consistency benefit? If I do something in a vm and it works, and then I do the exact same steps on a real machine in almost the exact same environment, it better fucking work without any issue. I don't care if file permissions or user groups or some other shit is the problem. The things I did were the same, so the result should have been the same.

Post edited on 14th May 2022, 6:45am

>>2711
Disabling features you don't need speeds up the build time for that package, and you may be saved from a bug if you didn't even compile that feature in a package. In Gentoo, you get to pick the optimization CFLAGS for each package as well (so applications are faster than in other distributions). The main reason why some see Gentoo as attractive is that you can have everything your way.

I heard that some claim that OpenSUSE is the best KDE distro, but I can't remember the reasons why. I used to use Debian testing at one point and I liked it more than Xubuntu.

>>2712
The way I want, is for things to just work. I don't think distro matters for a lot of stuff either. Like on 150% scaling, the font size here(tc) was significantly larger than the font size on lainchan. Why? I don't know. I set firefox's internal scaling to 150% too. Made no difference. It was very odd and unpleasant. Every distro uses the same stuff for these types of things. Windows, everything looks consistent, and I didn't need to tweak anything or set site specific rules or any bullshit like that.

Post edited on 14th May 2022, 9:47am

>Gentoo's package management system (portage) you to enable/disable features you need/don't want via USE flags.
See I'm not convinced that's really a killer feature. I get the same thing on osx by just using macports. It's nice being able to compile and customize things yourself, but 99% of the time that's not really a benefit: A different package manager isn't going to fix fundamental issues with the desktop linux experience like >>2713 pointed out.

Also the speed benefits of having all your packages compiled for march=native are a bit questionable anyway: Anything that's actually compute intensive probably includes their own optimized subroutines (e.g. ffmpeg), or links against blas to do the heavy lifting.

I think the best bet for a desktop OS that's not windows/osx is maybe something like HaikuOS which is being designed from the ground up as having a standardized interface and set of APIs that applications use, much like osx and windows have.

>>2713
>everything looks consistent
The Windows UI is absolutely all over the place
It's even worse now with situations where you have a settings menu reskinned into W10 with half of the options missing that you have to go digging into the old version of the same menu to find to do what you want

Sucks you had a bad Linux experience but it sounds like you shouldn't be using it anyway if you need stuff like Excel in the day to day, which is fair enough.

>The way I want, is for things to just work.

The overwhelming majority of things these days do just work
In my experience most people complaining it doesn't are either having some specific software won't run compatibility issue or they're trying to do something they'd never even attempt to do in Windows anyway (people randomly decide they want to change the file picker... change the default DE... the list goes on) and then wonder why stuff breaks.

>>2715
>The Windows UI is absolutely all over the place
Yes. I agree. That's not what I meant though. Fonts and stuff like that is what I meant. The "feel" of it. It's a hard thing to describe, but when you're sitting there and using it, linux or xorg or whatever feels worse, at least at 150% scale. Not to mention the numerous visual glitches I noticed. Which windows has too, but not as much in my experience. Whatever windows uses as a "display server" is just better than anything linux supports.

>The overwhelming majority of things
Except the majority of things don't include the stuff I use which few other people do. As I said twice already, I tried using something that worked in a vm following the exact same instructions, but on an actual machine it didn't work. Same os. Same de. Same software. Same instructions.

And by the way, it works in wsl ubuntu(when started manually cause wsl doesn't have systemd). It also works on windows, which I've set up multiple times. For all I know, the wi-fi drivers were at fault, and it works in VMs because those use an ethernet interface or whatever.

Post edited on 14th May 2022, 1:58pm

>>2714
>I get the same thing on osx by just using macports.
I've thought about using osx, but a few things keep me away from it. Hackintosh is dead for one. I don't like the look of macbooks, their shortage of ports, or how they're built to not be repairable. Soldered on ram and ssd. On the software side, they dropped 32-bit support a few years ago. So all legacy programs are now unusable.

>>2717
Yes, osx has a bleak future. It's basically been taken over by the ios team, and despite the transition to arm which was pulled off quite nicely, there are too many bugs in the newer OSs. I'm taking about severe usability impacting things like wakeups from sleep every few minutes due to some OS watchdog process never shutting up, battery drain when enabling bluetooth, WindowServer spiking CPU usage whenever caps lock is pressed (even if you remap caps lock to control), gestures randomly stop working requiring you to restart WindowServer, etc. I wonder if anyone at apple even uses their own shit.

Not to mention that every release you have to go to more lengths to avoid the OS treating you like a child. First it was codesigning, which up till 10.9 was still ok because you could disable it from system preferences and be done with it. Then it was SIP (system integrity protection), which prevented you from running dtrace or debugging privileged processes. To disable that you've got to reboot into recovery, set some nvram flags, and reboot back. Then it was AMFId, which I have no idea what it does except it's some bullshit backported from iOS. Then you have notarization, as if codesigning wasn't enough. And don't forget that Apple added "entitlements" as part of code signing so you can't even compile your own GUI app that links against CalendarKit or whatevre without figuring out the right arcane incantation of provisioning your own self-signed certificate and then invoking codesign.

It's a real shame that they put in all this effort building a really decent OS only to fuck it up for no good reason. The ideal setup would be to just run one of the last few good versions, either 10.6 or 10.9 depending on who you ask, which is actually pretty feasible considering that macports goes to heroic lengths to patch programs to maintain support for old OS versions.

Post edited on 14th May 2022, 2:32pm

>>2718
>10.9
Wow, that's nearly 10 years old. (5 since the last build).

Post edited on 14th May 2022, 2:33pm

>>2719
Can you honestly say that there has been anything new in computing in the last 10 years? That 10 year old OS works perfectly fine, and I feel is probably better than any OS that has since come after it. Even the 15 year old 10.6 is perfectly fine functionality wise and rock solid (although a bit too "Aqua" for my taste).

Which is again why I said it's a shame that they're taking the piss with the newer releases. A decade since their last decent release and what do they have to show for it? Nothing but visual redesigns no one asked for, "protections" that make you fight your own computer, and bugs so egregious that you both question the competency of their developers and wonder if anyone there even uses their own OS.

Oh and don't forget that they've given up on the developer facing side as well. 10 years ago they had some pretty decent documentation on not only cocoa APIs but also the kernel side, such as kext programming, IOKit, etc. Good luck finding any of that these days, it's all been archived and left to linkrot. Instead they offer up autogenerated header files for libraries you don't even have the source to: good luck doing anything meaningful with that.

>>2720
I mentioned the time because I was surprised how long ago the "last decent version" came out.
>Can you honestly say that there has been anything new in computing in the last 10 years?
In a literal sense, yes. You probably can't use the latest version of wine on 10.9. If you meant innovation, there's been incremental improvements in various fields and hardware. Like vulkan, which had its first release 6 years ago. I also have doubts about 10.9 hackintosh's support for newer hardware. I also doubt 10 year old apple hardware is that great. Their laptops have always had issues with questionable design(planned obsolescence).

Post edited on 14th May 2022, 3:19pm

>>2721
>Wine on 10.9
Looks like WineHq supports down to 10.8. Also most userspace software that doesn't link against Cocoa frameworks works just fine. Also yes true on Vulkan, but osx never supported that anyway in favor of Metal (I guess there's vulkan on metal wrappers though). And osx's OpenGl support had never been good anyway.

10.9 probably won't run on newer processors at all, at least not unless you start tinkering around with the kernel (which is feasible I guess since that part is open sourced, someone was able to get it to work on ryzen). But unless you're willing to use an old GPU you won't have graphics acceleration either, and I don't think anyone has reverse engineered the graphics stack.

Post edited on 14th May 2022, 3:20pm

>>2720
Oh another thing I just discovered. Apparently you can't even get coredumps of processes that crashed in the newer OSs. All you get is a helpful message from the kernel "AMFI: denying core dump" that even Google doesn't have useful results for. And this is a program I compiled myself, what the fuck. I'm surprised that there still any developers willing to put up with this platform.

>>1183
Does everything I need while having a usable command line and not nagging me with updates / unwanted shit I can't remove
Even VNs run fine these days
Unless you need some specific windows only software there's no need to use Windows