That's a false equivalency. I clearly stated if the person does not know something, don't do it. I am not saying you should not to do it. If you are experienced with the OS to make changes without breaking something, then go for it. A car owner might know how to change the oil - great - they can do it. But if they don't know how, they risk breaking something and the manufacturer should not be held liable. Tinkering is fine. But there is a risk and the person doing the tinkering needs to assume some or all of that risk. Just because you can do something does not mean it is safe for you do it because fixing your work might be beyond your ability to repair your own tinkering. Someone trying to reduce the weight of the car by removing lug nuts from wheels to improve acceleration is risking a wheel coming off. I can work on my air conditioning system but I won't do it because I know there is too much that can go wrong to take that risk. Same for working on my pool - I have certain abilities and recognize my limitations not to go beyond my skill level. But too many Linux users suddenly think they are computer engineers with skills beyond their abilities. Just because you can type in the "sudo" command does not mean you have all the necessary knowledge to delete files not fully grasping all the interdependencies. They watch a YouTube video and think they can go in to the internals tweaking and purging - suddenly when things break - you see the please help me request. They often don't provide specifics of what they did but some demand that the community help them. Some are realistic - many are not. I am all for helping someone needing help because they don't know how to make some changes or work with an application. But fixing some of their mistakes is asking too much sometimes. They too are a part of the community should recognize their own limitations. I don't advocate for an RTFM attitude but again, a Linux user should recognize their skill level. Furthermore, the community should insist for people to learn and grow but not just dump their mistake onto the forum for help when they make a bad mistake. When I was a flight instructor, I would never train someone to fly a single-engine approach that has never experienced flying that airplane with the engine shutdown. That's a recipe for failure. Yet we seem to excuse that type of behavior in Linux land. Although this is only MY opinion, it is a large reason why the Linux desktop has gained so little adoption in some 30 years.
I dont know where you get your opinion. I dont see Users demanding help, but rather asking for it.
I also think Linux desktop will get more adoption if Linux can implement more ways to change things without a command line prompt. Linux is still very heavy on users without much experience and things will break when you have to type in sudo xyz.
Another, in my opinion good example, is repairability of a phone. Yes, phones break if you try to change the battery. But they break because the user is forced to interfere with things that are beyond his level. If you look at fairphones philosophy, the users will not break the phone by changing the battery simply because the system (in this case the phone) allows users to change things without asking for much knowledge in the first place.
I love being misquoted. I specifically said "Some are realistic - many are not."
I didn't misquote you in bad faith, I seemingly misunderstood what you meant and also wanted shared a different view on the topic.
As I pointed out above, given my years of experience on this and other forums, this is an uncommon occurrence.
In the majority of cases, a user will state in the O.P. that they did something or were trying to do something and where it went south. Most do ask quite politely for help in fixing it.
Knowing my limitations also means expanding them. I started out in this world with far more limitations than I have today.
A limitation is not necessarily a halting point, just a marker of the boundary where the learning curve begins.
Your points are valid and having different views on something is beneficial. We can use different views to achieve balance. We can also increase others understanding of views that they might not have yet considered.
The equivalency, however, is not false. My post above outlined just how similar they really are.
Users are not breaking things, hiding that they did and then coming here demanding that we fix it. The vast majority of bug reports in existence are about developer issues, not user breakages. A smaller percentage are actually feature requests, not bugs.
And if you go over the solutions provided on just this forum alone, you will find that those dealing with user self-inflicted breakages are an exceptionally tiny minority.
The majority deal with Sound issues, printer issues, wifi issues and graphics issues that are driver related.
To put this in perspective:
This never happens. Ever. This may just not be the best analogy you could think of but... In reality, users that modify their vehicles know the risks and they take precautions.
Yet, too often, I see that people simply assume that others are inept and incapable. This is the Microsoft mentality to a T and many of us on GnuLinux migrated over to get away from that mentality.
The evidence is: We just do not see a lot of cases of users breaking their systems by wild and wacky tinkering. It happens, but it happens rarely.
As always, you win. I visit way more forums than just Zorin and my commentary/observations are not limited to Zorin. I gave several analogies but you latched onto just one
I referenced the lug nut analogy because it was so outlandish. How much acceleration are you going to really benefit from removing the lug nuts in a car but risking a catastrophic failure? That's what some people do in Linux. They go into the operating system armed with YouTube knowledge and the command line to remove a bunch of files that don't adversely increase boot times (acceleration) yet they remove them because they don't want bloat and then break the system (the wheels fall off).
Sure - this does not happen. I see it all the time with Linux users. Then comes the help request.
But you win!
What it appears we are doing is comparing anecdotal evidence, then. I posit that any user can browse through all of these forums and reach their own conclusions based upon the frequency of the stated events.
Certainly, in this forum, we can indeed find a few cases where a user tried to increase boot time. They are not a common issue and the worst that usually happens is that they lose access to their Grub Menu.
What we do is we inform users of what the Grub Timeout Style does and warn against them setting that value to 0.
We do not make it impossible or difficult to access grub file, nor make it to where they cannot modify it. Doing so would bring far greater harm because it would prevent the many more common issues that are correctable with a Grub Parameter from being implemented by the user.
Linux users take their lugnuts off the wheels to improve acceleration?
No.
It does not happen. Ever.
Do people modify grub? Yes. All the time. And harmlessly, at that.
In a few rare cases, some people make a mistake or do something wrong or have a typo in the grub file... and we are here to help. It is far more often that the user forgot to run sudo update-grub than it is that modifying grub broke their whole system.
In fact, I cannot even remember that last time a user broke their system by modifying grub. I can remember a great many where we needed to fix a parameter or correct a typo or run update-grub... nothing major.
Not to Shift Blame and not to tell people that they are inept and that they are not allowed to learn about their systems, tinker or modify.
Can you link to these Youtube videos that are maliciously telling people to remove files that do not even affect boot time? We have a thread for that:
I know my limitations. So should others. I don't remove any files to remove bloat to improve boot times, change the wallpaper, or change a default feature or whatever fanciful reason someone has to remove files. Consequently, I have not had my Linux installations break - the wheels of my Linux installation have never come off.
Yes, as I said, you make valid points about times when some users act rashly or blindly.
This is why exchanging differences with polite debate is good reading material.
It is also important that GnuLinux users recognize the limitations of efforts to control users or lock down systems.
As someone who has used GNU/Linux since 2002 and still not read the hefty Linux Manual based on Red Hat with tons of terminal commands. And you don't need to break a system by tweaking. In comparison, my experience with Plasma in both MX-Linux and KDE neon has led to the systems breaking by installing games from Discover. This is down to poor management of Software channels allowing old software in Games to be installed, they need to be purged. I have not got round to installing Timeshift in either of these and will concur that Timeshift has helped me when things have gone awry. One point I only recently was made aware of when my Devuan 3.0 was baulking due to a bloated /var and my failure to run
sudo apt autoclean
Additionally, any snapshots have to be saved to a drive or partition with the same FS (File System) used by the OS so saving a snapshot to an external drive that is formatted as NTFS as most external HDDs are, it will be unrecoverable. You also need to be aware of how to restore using Timeshift via the terminal which I think I have covered in the Unofficial Manuals that I have authored. One thing that has been pointed out in another posting on here is that the one in the Software Channel is not current. The most up to date one needs a repo adding (GitHub - teejee2008/timeshift: System restore tool for Linux. Creates filesystem snapshots using rsync+hardlinks, or BTRFS snapshots. Supports scheduled snapshots, multiple backup levels, and exclude filters. Snapshots can be restored while system is running or from Live CD/USB.)
With MX-Linux and KDE neon led to video out of range issues. Nothing important lost in MX-Linux 23.1 KDE just needed to do a fresh install. With KDE Neon it is no biggy it just means I can't boot into Plasma on X11 only Plasma on Wayland which is more secure anyway, so good choice that Team Zorin has made with the release of Zorin 17. I've only just discovered that x.org leaves GNU/Linux vulnerable to keystroke logging.
Knowing your limitations is good, but I'm not sure that accepting those limitations is conducive to making progress - gotta push boundries in the quest for knowledge, and having a safety net in the form of a utility like Timeshift has to be a good thing for novices (like me) and experienced users alike. Going slightly off-topic for a moment if I may - I'm guessing from your username that you're an ex-Starlifter pilot? I've always lived just down the road from RAF Mildenhall and those beauties were a common sight in the skies around here back in the '70's, as the KC-135's are to this day. Mildenhall Air Show was one of the highlights of the year for thousands of people back then - superb day out and the hospitality of the aircrews was second to none!
This is interesting to me because in my previous post Aptik was the backup/restore application to which I was referring. What's interesting is that the dev teejee also creates or manages that application and the repo from where it is obtained.
Edit:
I take that back, I knew this before and told someone else about it too. Did not remember seeing it on their website for some reason, but I knew I knew it... 
This is where I obtained the version that I am using - 24.01.1
Er...Do I detect thread has deviated from the original subject i.e. Timeshift ? 
May a split is in order.
(It is an intersting read though)
A split may be a good point, but what to call this conversation?
C141ZorinOS, I understand your reasoning. Those that have no interest in learning, want to follow a tutorial and accomplish what they want to do can be an issue.
There have been several that attempted to remove "bloat" (opinion-ed POV) and have caused boot failures, DE failures as well as Grub failures, resulting in a reinstall or restore from backups. They did this openly here to share the experience, knowledge and reduce the boot speed while removing the applications they didn't use or had preferable versions of. Some of their issues were interesting reads, as you wouldn't think some of the apps were or should be integrated into the system as they are.
Those that do have interest in pursuing advanced knowledge of their computer and OS, should know these limits and research what they need to know in order to improve that. As with anything you learn, sometimes, you can not find what you need to know or separate it from what you want to know. There is so much information out there about computers, networking, design and coding....one could get lost rather quickly in a rabbit hole of information. Sometimes the best education is trying. Failures teach us.
Take me for example. 20 years of IT support, network administration, and now 3 years of coding. I started my journey, unsure what MS skills were transferable, and asked many questions here on the forum, that I could have researched myself, because I wasn't sure where to start. After a few resolutions, I started helping here, as many of the issues are the same as MS, except resolved slightly different. How is what is different, not the resolution. I hope that makes sense.
Recently, I posted a thread asking for help with KDE Plasma on Zorin. I went into this, as I have in the past, with a good idea of what should happen. The unexpected issues, not of my own doing as I used vetted apt repos, where a puzzle that not only did I want to resolve, but share with others. I also wanted other POVs as my mind may not consider every possible cause or solution.
I found the answer here, on the forum, in a thread about steam. Because of my curiosity, willingness to attempt and fail (possibly), and willingness to help, I found the thread about sources and steam. This made me consider that I was having a similar issue. Once I tested my theory, I shared it here. Knowing full well that I may just have to restore and attempt it again.
Without pushing those boundaries, you, people, never learn anything. You can only read so much, but never trying will never give you experience or knowledge.
I'm with you.... Those that want to tinker, but without attempting to learn how the system works, shouldn't. Those that want to learn, research what they are using, and what could possibly go wrong, should continue to educate themselves, and others.
Yes thanks for catching that. I was a flight engineer on the C141 and the C130 many years ago. I retired from the Air Force in late 2018 after going through cancer. I am in-remission 5 years now enjoying my grandkids. Life is good. Linux has been instrumental in my healing - it keeps me occupied while learning new things and seeing the differences in operating systems. I don't agree with some some of the philosophical stances of open source but I do recognize it has merit and value. Sometimes, it seems, FOSS takes one step forward and two steps back. But there is a lot of ingenuity and creativity in the FOSS world and that is what I think is the best feature. Before I retired as an Air Force officer, I was in cyber security for a while since my MBA was in information system. Fascinating technologies being developed in the IT world not limited to the latest artificial intelligence fad. I often wish I had done more in management of information systems but I like where I am at now. Take care. 
Extremely well said. You captured what I was trying to point out in a very eloquent manner. 
Amazing and interesting what we learn about each other on these online forums sometimes. I wouldn't have known that about you if you hadn't said anything. Thanks for sharing. I myself have a STEM doctorate, so I have a technical and scientific background in addition to my prior work experience. Part of me staying with Zorin is that it simplifies all things Linux (well, compared to many other distros), and I like to keep things simple. Simplicity is complexity resolved. Zorin does a good job at that. This way, I don't have to think much of anything in my ongoing transition to Linux from Windows and can just focus on what needs to get done. Again, thanks for sharing, sir.
I agree whole heartly about Zorin making things easier which shows how well designed it is. Those few Linux users that complain about the age of the base don't understand all that is not relevant with Zorin since they have all types of packages and they have their own repositories for new software. However, I have started trying MX Linux KDE lately again. I have used in the past and liked it but it never gave me a warm fuzzy. With that said, I installed it again about a week ago and I am loving the idea of staying closer to Debian. This all started with my comparison of LMDE 6 with Zorin 17. I just enjoy LMDE because it avoids connections to Canonical by using only Debian (and Flatpaks when needed). MX Linux KDE is very similar with more robust options and tools. But for me, LMDE still wins because they have the upgrade tool to make major upgrades easier much like the new upgrade tool for Zorin. I like Ubuntu and Ubuntu based distributions but there is always some hiccup with Snaps and all that which is unfolding. I don't want to deal with what seems like a beta program to make Snaps work much like Fedora is with Red Hat. I think they have a good idea but the hit & miss of how Snaps can work and then not work is what is frustrating. I used Kubuntu with no issues whatsoever but with Ubuntu-proper (the flagship), there was always some bug with the software store or an actual Snap package. It makes no sense that Kubuntu worked better than Ubuntu proper. Same with Ubuntu Budgie (not my favorite desktop) - it worked flawlessly but yet - the flagship had all sorts of minor annoying issues. Not so with Zorin thankfully, but it is on an older more stable base. Somehow, Zorin seems to have avoided some of the pitfalls of Snaps in my use case but others may have a different experience. I am one of those Linux users that has slowly started to shift over to Debian since LMDE 5 (and now MX Linux) but still sticking with Zorin too. I just wish MX Linux had the upgrade tool but their unofficial script instructions work spot-on. I installed MX Linux 21 and did the upgrade scripts to MX Linux 23 and it worked. It was not difficult but not convenient either.
I find it good to treat a linux experiment like any science experiment.
- Make sure you have a proven escape route and recovery methodology.
- Document the steps taken (I use a handwritten notebook). That enables repeatability and avoidance of repeating a bad step or rabbit hole.
- Test the solution, but not to destruction.