I spent four days last week attending Ohio LinuxFest 2014, one of the busiest and most successful Linux shows in the country. It was my honor and privilege to deliver the closing keynote this year, and much of what I said either alluded to or squarely addressed our trust in free open source software.
That should be a no-brainer, right? I mean, GNU/Linux, or just “Linux”, is rooted in FOSS applications and principle.
Except when it’s not.
Here’s what I want to know. Is replacing a well known application in Linux with a crippled version acceptable when it’s done in the name of stability? I’ll go ahead and place myself in front of you for scorn and castigation by admitting that I’ve been a member of the Slashdot community since 2002. Everyone has a sig line, right? Mine was thoroughly honed to be as concise a possible:
“Windows assumes you are an idiot…Linux demands proof.”
In other words, for the most part, Linux users are in complete control of everything in/on their system. Linux will allow you to completely bugger your installation, because as a user you have the responsibility to know what you are doing. Fools are not suffered gladly when using Linux. You wanna play with the rm command? Go ahead…it’s your computer.
Some lessons are best learned the hard way.
So here’s my point. I’m a big fan of Linux Mint. So much a fan that we modify the Mint KDE LTS to serve the needs of our Reglue kids. I think it was somewhere around the middle of the support time for the Maya release that I noted something odd. You could no longer use Synaptic to update your computer. I mean, you could install packages in Synaptic, but the means to update or upgrade your system was completely missing.
Mint had already made upgrades a bit more difficult by making you choose all apps with a ctrl+A command and then right click to update all apps. But now, you can’t do even that. The Mark All Upgrades button is completely missing. It wasn’t stripped out; from my understanding, Synaptic had been replaced by Mint’s version of Synaptic. You can search and install applications with it…you just can’t upgrade your system with it.
Why? Let’s take a look. From the author of Tux Tweaks:
“I’ve written before how to restore the Mark All Upgrades button to Synaptic in Linux Mint. Things have changed in the latest version: Linux Mint 17 Qiana. The previous technique no longer works because the Mint team is providing their own version of Synaptic rather than using the package from the Ubuntu repositories. The following will show how to restore the Mark All Upgrades button to Synaptic in Linux Mint 17.”
So they are providing their own version of Synaptic? Why…when the regular synaptic works just fine? And that’s the problem. Synaptic allows you to upgrade every app, kernel release, theme, script and software voodoo curse you chose to update, but in the Mint world that can be a problem…or so it seems.
The Mint Update Manager is a slick and fantastic piece of code. It’s preformed flawlessly for me when I choose to use it. See what I did there? When I choose to use it.
By default in the Mint Update Manager, applications and other software in the repositories are coded by numbers, one through five. Those are the levels of safety the installation presents. One through three are just fine and install at will. If you want to live dangerously and install software considered “dangerous”, at levels four and five, you have to go into the settings and agree that you understand the possible negative consequences.
That’s not such a bad thing, right? I’m not gonna gripe about that in particular. What I will gripe about is completely neutering Synaptic as an alternative method of system upgrade/update.
“Remember kids, this is for your own good. You might break something and I don’t have time to fix it. Now run along and play nice.”
See, it wasn’t too long ago that a program called Mintconstructor was removed from the Mint repositories because of some people taking liberties with the Mint system without giving credit to the Mint creators. That’s what I understand anyway. The results of that donnybrook are fading in the search results.
Our Reglue 2014 Volunteer of the Year, Randy Noseworthy ran into this problem when adding apps for the Reglue respin. Being the brilliant guy he is, he hacked it together enough to make it work for the Linux Mint 17 LTS spin. But he did that by the seat of the pants…he doubts he will be able to do so in the future.
So are there any other methods of doing respins? You bet. One of them is called UCK.
“But Ken…Ken, UCK is for native (K)Ubuntu systems, not Linux Mint.”
That’s my point. Exactly.
Ken Starks is the founder of the Helios Project and Reglue, which for 20 years provided refurbished older computers running Linux to disadvantaged school kids, as well as providing digital help for senior citizens, in the Austin, Texas area. He was a columnist for FOSS Force from 2013-2016, and remains part of our family. Follow him on Twitter: @Reglue
I don’t really have a problem with that. The people I’ve installed Linux Mint for are not going to miss that functionality, and are unlikely to ever want to change anything in that area anyway… and probably will ignore the updates available messages, anyway.
I volunteer for a non-profit that refurbishes computers for people. We use a mixture of Linux Mint and Windows 7. I’m the Linux guy and I use Linux Mint at home, too. I like Linux Mint for its polish and stability, and I find Mate especially good for new users. However, I want Linux to be Linux and not to be about putting sections of the system off-limits to me. I know of new users who regularly do updates. I’ve used synaptic to upgrade when I was a kubuntu user and don’t see why it needs to be neutered in Mint.
This does bother me.
I have had Mint 13 LTS Update fail on me — crashing under load on an older, more resource-constrained system. I forget whether I used Synaptic to fix it (I don’t recall anymore whether I had usable graphics), or whether I went to apt-get or aptitude on the command-line.
So I figure Mint Update just isn’t as robust as Synaptic.
And it (Mint Update) sometimes just doesn’t provide me the information I need and the options I want, where Synaptic is often a more convenient and more useful tool than either Mint Update or the CLI options.
A cautionary pop-up (similar to the one Mozilla Firefox presents when I find cause to go into about.config) would be mildly irritating, but I’d recognize it as a legitimate action (especially if it had a check-box for “show this warning every time/don’t show this warning again”). But hard-crippling a useful tool is not kosher.
Mint forks a huge number of packages from the Debian/Ubuntu repos. Synaptic installs the Debian/Ubuntu versions from the Debian/Ubuntu repos, and the Mint update manager/package manager installs the Mint version from the Mint repos. A full upgrade using synaptic would result in a Ubuntu/Mint hybrid. If you have ever noticed when upgrading with synaptic in mint that it will ask to keep the original config (mint version), or install the package maintainer’s config.
@67GTA
I don’t know how Mint does things as I don’t use it, but why would Synaptic need to pull from Debian or Ubuntu repos on Mint (these two are not equivalent either…unless you like horribly broken systems)? Why not point it at the Mint repositories? If it is, as I suspect, because Mint pulls some packages from their own repos and some from Debian or Ubuntu and only their update utility can handle that appropriately, then I’d go so far as to say Mint is “doing it wrong”. They should host their own packages.
They do host the packages they fork in the Mint repos. Mint is directly based off of Ubuntu. Mint piggy backs off the debian/ubuntu repos for 90% of their packages, just like Ubuntu does with Debian. That is why synaptic is locked down, so it won’t update using debian/ubuntu packages. I’m no developer, but I’m guessing it was easier to write their own package manager, rather than to earmark every package version through synaptic.
I’m a gentooer running kde (lite, USE=-semantic-desktop so it’s not even installed), which pretty well tells where my personal configurability gauge is set, even more so once you know that when gentoo/kde tried to kill the semantic-desktop USE flag and force it on, I carried my own ebuild patches for awhile turning it back off, because I’d had a previous taste of it and knew I didn’t want nor need it, and that stuff was NOT going to be on my system.
But I realize that people run the gamut, and there’s a lot of folks who want it to “just work”, and don’t want to even think about configuration that could in any way break their system or simply make it so they don’t know how to use it properly any more even if it’s not technically “broken”. And I realize that there’s a developer parallel as well, like the gnome devs that don’t want to give users too much configurability for gnome (FWIW it was not just gnome3, back in the gnome1 and kde2 era when I was choosing, I ended up choosing kde, because it actually had a color settings applet, while gnome1 only had theme settings, and forced you to edit the config files manually if you wanted to set individual colors).
But there’s a place for both types as well as those in between, and you know what, I’m very glad that there’s a gnome project for the devs who think the users will simply mess up their beautiful ideas if given too much configurability to play with, and for users who are afraid of too much configurability, because if there wasn’t, they’d be trying to kill all the configurability in kde, that’s the reason some of us actually use it!
Similarly, I would hope that the folks who believe “there can be only one true way, and it’s our way” would recognize that the alternatives with all those configuration options they hate, help keep the people who actually want and use that configurability, out of their hair! Tho of course it isn’t always so, as we have people complaining about the split, and all the other options there are, all the time, just like they complain about “too many distros” too choose from.
Meanwhile, the Mint folks have for the most part always marketed Mint as “it just works, as installed”, so it shouldn’t be too much of a surprise to see them trying to file down one more bit of too sharp an edge configurability, from their viewpoint, just one more way users can end up hurting themselves, so it must be filed down into smoothness.
The good news is there’s lots of distros out there to choose from. If you’re part of the Mint target group that appreciates their care in filing off all these even slightly sharp edges so their users even have to worry about getting hurt, great, say with them.
OTOH, if you think that’s one smoothed edge too far, there’s certainly distros out there that are /almost/ that smoothed, but not quite.
All the way to the other extreme, like gentooers or even more so the linux from scratch folks, where if it’s possibly configurable and there’s not an exposed way to configure it, it’s a bug!
And all the way in between, arch toward the gentoo side, ubuntu toward the mint side, with debian and fedora and opensuse and lots of variants and smaller distros in the middle.
Wouldn’t it be possible to point Mint’s Synaptic at a repository that contains vanilla Synaptic and use Mint’s Synaptic to install the vanilla Synaptic and then use that?
(Still annoying, I’m not arguing that, just saying . . . )
Somewhere along the line it appears that a secret cabal of knuckledragging imbeciles snuck into OpenSOurce land and did some sort of changeling thing. Bullies, misguided crusaders and self appointed developers have built a fire, placed our GNU/Linux upon it and are now dancing round watching the flames take hold.
When you remove something from a distro, that wasn’t causing any problems, in order to obfuscate functionality, you have left the path of wisdom and are heading for the lunatic asylum.
If this is what you want from an OS, Windows awaits your pleasure.
Slackware does not do this to its users. “But Slackware doesn’t have a package manager” you wail. Precisely – learn instead. It’s easier than you think. Learning what little you need to run slackbuild scripts/compile your own software (and it really is a little) will help you more than the minimal, ‘use without learning anything’ apps like Synaptic.
Convenience is a false god.
It would have been nice if you had looked into the background of Mint and included this releveant and insightful post by Clem :
http://segfault.linuxmint.com/2013/11/answering-controversy-stability-vs-security-is-something-you-configure/
And more recently:
http://segfault.linuxmint.com/2014/10/improvements-in-the-update-manager/
Both address your topic from the Mint side, and I feel completely explain why the decisions concerning synaptic were made.
Take the time to read them and consoder updating your article to be more relevant.
The vanilla synaptic is in the repos. Mint just removes the upgrade button via config file. I don’t use Mint, but install it for new linux users. I used this method to fix it “http://tuxtweaks.com/2014/09/restore-mark-all-upgrades-in-synaptic-linux-mint-17/”
Looking through ’em, I don’t think either of Clem’s posts you linked refers to this Synaptic issue. He does refer to the 1-5 ratings on updates, but mr. Stark specifically says he’s “not gonna gripe about that”. I suppose you could say some of the more general stuff in the first implies what he would say about this Synaptic issue if he were saying it, but that’s a bit different.
Thinking about this whole thing, I have a suspicion that all this has less to do with security and more to do with Clem’s general allergy to the whole idea of updating from one version to the next. He’s very big on getting everyone to do the schtick where you back-up your lists of software you’re using, reinstall from scratch, and use the back-up list to automate reinstalling all your extra stuff. This doesn’t bother me much in theory, but I’ve had some problems with the back-up process and searching around turns up a fair number of other people with similar complaints, so in practice I’m not sure it’s so awesome as Clem wants to claim.
Anyhow, Clem doesn’t really intend Mint to be upgraded from version to version, and doing an upgrade with Synaptic can be an end run around that. No doubt he also because of that focus doesn’t build Mint to upgrade without breakage and would prefer people didn’t end up with breakage because they do it the way he doesn’t want them to. But, y’know, it’s Linux.
I’m not a Mint user but I have installed it in the past. I also was puzzled by Mint’s altered synaptic. Also, if anything, I would think Mint’s native updater with its numbering system to be even more confusing to neophytes than the traditional synaptic. My question is what happens when you try to update from the command line(apt-get update; apt-get dist-upgrade)? Has this functionality also been removed from Mint?
I think the provided explanation in the thread, that one package does not always come from one source precisely outlines the point.
The one paragraph of personal opinion about mint-backup is not relevant to this article about synaptic.
Apt-udate and apt-upgrade commands are functional in terminal in Mint 17…providing an experienced user a higher level of control when desired.
I offer:
” clem Oct 16,2014 08:11
It’s not true though, what you think you know.
Let me give you an example:
libxatracker2
libgbm1
libegl1-mesa-drivers
I only listed 3 of them here.. but there are 34 in total, they’re all parts of “mesa”. Any given update can potentially introduce code changes and dependencies between them in any number of these packages. It’s really important you apply them together.
You say we show less info than before? That’s the opposite. We condensed it visually and we actually show more than before.
Prior to this we’d show x updates and you couldn’t see what source package they were from. Now, we show one update and clicking on it lists the included packages. So there’s more info there now.
There’s less choice of course because you’re no longer able to select parts of an update as opposed to the entire update, but that’s a good thing. First because it’s dangerous to do so, second because even if you really wanted to (the only case I can think of is to troubleshoot, for devs) you can still do so (assuming the maintainer didn’t make it impossible via deps as he should..) with apt or synaptic.
Don’t fall for the cheap Windows comparisons. Nobody here likes what we call “click and pray”. This tool is to empower you to make decisions on a very sensitive matter, the more effective it is the better, and that means showing you relevant information, not drowning you in details you don’t need without telling you what really matters.”
Hi,
Don’t see any bad in it. The culture is sound, we want people to be able to do what they want with their computers, but we also want things to work well for everybody by default. That means making things safe for novice users as well as letting advanced users do power stuff. Here that translates into letting people dist-upgrade with apt-get (which novice people typically don’t use) and removing dangerous use cases from synaptic (which anybody sees in their menu and are able to click without thinking too much).
The workaround is simple for people who want the upstream synaptic. Install the Ubuntu version with “apt install synaptic/trusty” and hold it with “apt hold synaptic”.
Keep doing what you do best, it’s good to question design and decisions and wonder about things. We do it too and we work hard on improving Mint every day. You might think Synaptic is crippled as a result, we think it’s improved for us and for most of our users as it integrates better with the overall range of solutions, letting novices with filtered updates while the removed features are there with apt-get.
Another solution would have been to leave Synaptic as it was but to remove it from the default software selection. We felt that was a pity since the other features it provides are both advanced, useful and safe for everybody.
Note: We work mostly on feedback, we react to feedback, we change things in most cases because it fixes real issues people really had, not because we think it “might” be better or it might make things easier for “your own good”. Us being in that post-PRISM era with Google, the NSA and whatnot doing this and that, I fully understand the need to question things and wonder motivations when it comes to maintainers deciding things “in your best interest”. It’s worth understanding that our model relies solely on user’s comfort with their operating system, we’re funded by their donations, we’re motivated by their happiness. The only thing at play here is that you represent one part of our audience, and that there’s another part out there who click buttons and doesn’t know nearly as much as you might. In this particular example, and because you’ve apt-get to install/dist-upgrade/hold we chose to accomodate novice users. In most cases we can please both novice and advanced users, when it comes to package upgrades and package management though, it’s a bit more tricky.
Regarding mintConstructor, there’s two things. First we no longer used it and it was a lot of work to maintain it, it wasn’t going to happen (you probably know it lacks hybrid support for instance). That was a small issue. The big issue was credit, but you’re getting it wrong. We don’t mind people not giving us credit, quite the opposite.. what we didn’t like were people creating ISOs we had nothing to do with (some of them breaking even the simplest test cases from our QA), and distributing them as if they were made by us. When you see people come to you and talk about bugs in Linux Mint, just to realize they’re running an edition you never heard off.. called Linux Mint Ultimate Edition or something of the like, that’s a problem. If tomorrow I start writing articles and I sign them Ken Starks you’ll have an issue with it. We asked people to rebrand their work and not to distribute it under our name, that was the central issue here. What became of mintConstructor, I don’t know. It’s open source, it probably got forked, that’s what should happen anyway if people cared about it. It’s available on the Web (if you can’t find it I can probably dig archives and send you my latest version). What’s changed is that we no longer promote it, distribute it or develop it (I don’t know where you got that screenshot though.. we never maintained any PPA… as I recall we used to distribute it on linuxmint.com and github.com).
One last thing: About upgrading to newer releases, we know people want to do it. It’s already possible and if you know your way around package management you’ll have no problems upgrading Mint the way you upgrade other Debian distributions. We do not recommend it, simply because we don’t feel it’s safe enough for people who don’t have that knowledge. Now with that said, it’s also one of the reasons we decided to stick to LTS, so that these upgrades could be safer and trivial. You’ll see something new with 17.1 in Mint, for the first time we’ll recommend upgrading for all existing users and we’ll provide tools for that anyone can use.
Other than that, although the topic isn’t very happy, it’s nice to hear from you Ken. It’s been a while 🙂 I hope I don’t sound too negative. Take care. Call me pragmatic if you will, you’ve always been more of an idealist. I do appreciate what you do.
“This smacks of some of the elitist mentality Gnome took toward their users. We know what’s best for you.”
Hey!! That’s a bit unfair :))
An entire cycle went into supporting MATE and creating MGSE, rejecting GNOME 3’s design and embracing the implementation of what people were screaming for (basically to continue to use their computers the way they liked). Nowadays our biggest project, by far, is still around that post-GNOME2 loss with the development of the traditional desktop that is Cinnamon. I don’t know any other project that fought as hard to go against what you just mentioned there and to provide people with alternatives.
What you don’t appreciate is the lack of inclusion of the community in how decisions are made, the lack of brainstorming or pre-emptive explanations. I understand that can be frustrating. These decisions are nonetheless based on feedback, not on some abstract guidelines, and when challenged (like here) they’re met with discussions, arguments and replies, not with ignorance (well, you tell me, but I do happily reply as much as i possibly can, on blog.linuxmint.com or segfault.linuxmint.com in general, or sometimes outside of Mint like I’m doing now).
Another reason why you might have said that is that Mint isn’t a distribution in the same manner as traditional distributions (like Arch, Debian, Slackware) which role is to distribute upstream. It is a project which builds a desktop solution, call it a DE, an OS, a distro, it doesn’t matter. It’s a project which builds a finished product, and in a way it’s very similar to Ubuntu or GNOME in that respect. If you’re used to run vanilla upstream components you might have an issue with the amount of integration and patching done. There’s really two kinds of distributions here and I understand that also can be frustrating to some people.
Hey Clem…yeah, I was going to start a conversation about this in your forums but there are a couple there that weren’t exactly welcoming in the past.
And I appreciate your feedback. You cleared some things up that maybe I might have looked into a bit more before I posted….or not. ;-)) What good’s a rant if you have all the facts? Just kidding. this was far from a rant.
Mint in the KDE ISO has been an absolutely amazing and popular choice with our Reglue kids and if you can see fit to pass along a working copy of Mintconstructor, I would appreciate it…and I’d even offer to pay for the maintenance if you or someone wanted to do that. Reglue is a non profit with some disposable cash so if Mintconstructor could be updated, I would appreciate it. However, I understand the headache it might be by releasing it again. We really, and I mean really like Mint KDE. Please pass along our congratulations the the folks who put that together.
This is actually a good example of how to deal with criticism. I’d like to follow up on my blog, featuring our post and your response. Lots can be learned from it. Thanks again Clem.
It’s ok. Thanks Ken, if it didn’t take so long I’d talk with people a lot more. There’s good in criticism for us too, we learn from it as well, sometimes it’s better to see miscontentment expressed and reflected in an article or comments than not being aware of it at all.
I’m sorry things went bad in the forums. I started with Slackware around 1996 myself and I remember people helping each other a lot and welcoming you to Linux with open hearts, it’s really something I want to preserve, even now that it’s gone a bit mainstream. The mod team is completely with me on that, but it’s a big community, sometimes things get heated and unfortunately we don’t always get people to be as welcoming or nice with each others as we’d like to.
I put mintconstructor here temporarily for you to download http://linuxmint.com/tmp/mintconstructor_3.1.2_all.deb. We’re paid to work on Mint though, I’m not taking money for anything else 🙂 As far as I know (it’s been a while so things might have changed) it should still work pretty well but it doesn’t support hybrid ISOs, it might also fall short with EFI. In any case that’s for other developers to worry about. Have a look at it yourself if you can, it’s not that complicated. After all it’s all open-source and this is just a frontend to common tools such as chroot, squashfs, mkisofs..etc. Hopefull it’ll have a second life with a new dev. team. After all that’s what open-source is all about 🙂
ttyl Ken, take care.
Looking at the code it does call isohybrid.. hmm.. maybe it does support it then. I’m sorry I really can’t remember where we left off with it.
I’m pretty sure it’s missing something, maybe it’s the ability to boot from DVD drives in EFI mode. You might want to replace isohybrid with a xorriso call or to talk to the cdrtools devs.
Anyway look what you’re making me do. OK I’m gone, I am NOT working on mintconstructor 🙂
@Clem
Kudos for the excellent explanations.
@Clem
Maybe I’m missing something, but why not simply add a synaptic group to enable / disable the advanced / dangerous functionalities in Synaptic ? This is already done for exemple with the lpadmin group to enable / disable the right for a user to configure printers, or more recently in Jessie a wireshark group has been added to enable all Wireshark functionalities (and in the later case, it is a critical security issue).
This is better than installing upstream synaptic as a workaround. It allows knowledgable users to do what they want and novice users to be protected, at the same time and on the same machine, which is a requirement on a true multi-user system.
It may also be simpler to maintain and support. And with a bit of polishing, such functionality may be a candidate to be pushed upstream, because Mint is not the only distribution which supports a complex and hierarchical depot configuration and needs to protect novice users from doing things that are dangerous and that they do not understand.
The main difference is that it would add a functionalty to synaptic, instead of removing one.
Of course, this does not solve the issue of a badly configured synaptic if it is the underlying problem. Taking binary packages from different and incompatible depots is always a problem with any distribution and any package manager, and while apt-pinning can solve some issues, apt-pinning is tricky to configure correctly, even by system administrators, can have unexpected consequences, and does not magically resolve technical incompatibilities.
Anyway, assuming that power users always use the command line does not match reality.
A last thing about novice users, while the distinction with power user is correct, novice users is definitely not an homogeneous group. Some novice users are on their own, do the installation and do not get much support except from the Internet. Other novice users would problably never do even a “single click installation”, get a lot of support from family or friends for the simplest things, and need a completely configured and locked down system to avoid mistakes.
This generates more requirements for the second category, because in that case, the system must be at the same time very sane and locked down for the user, and very open and configurable for the administrator. Assuming that a power user and a novice user use two different machines is just not an option.
As a power user myself (in fact a software engineer with more than 20 years of professional UNIX experience), I often do support for many novice or occasional users, and the last two things that I want, is to do support on a system which is locked down for me, AND to do support on a system which is not locked down by default or that I cannot lock down for users… These requirements are very different, but they are equally important, because in both cases, it is potentially a loss of time for me.
Hi Lionel,
Good point(s). It’s basically down to time/resources here.
Our main objective was to make things safer, we did that by quickly disabling features (see here https://github.com/linuxmint/synaptic/commits/master). That’s done.
Now your point is valid and if we can accomodate more people by making this configurable, I’m all for it. The reason we pinned Synaptic in the first place is because it’s missing an /etc/synaptic.conf 🙂
Let’s be pragmatic here. If somebody comes to us with a pull request on Synaptic (like here https://github.com/linuxmint/synaptic/pulls) to make these removals configurable, whether he’s using /etc/synaptic.conf, gsettings, gconf, a user group or whatnot won’t matter to us. It will go in, we’ll merge his code and push an update into Mint.
If nobody does it we can look into doing it ourselves. It’s a perfectly valid claim for a feature request (I can see some people raging at the back of the room when they hear me call disabling feature removals “feature request” but heh..). In that case we add it to the roadmap and it might get done sometime down the line when a dev from our team looks into it or typically in a middle of a cycle when things aren’t as heated and we’ve time to work on non-urgent projects.
But yes, to be brief.. we went for the quick fix for something we thought was important. With more work put into it it’s perfectly feasible to make this configurable and thus to please absolutely everybody.
Please correct me if I’m wrong, but neither Synaptic (patched or unpatched) or Mint’s update manager allow you to clean out your cache of downloaded packages after you’re done installing them. Which means they just pile up, needlessly using disk space.
(The only GUI-based package installer I’ve seen so far, from an Ubuntu-based distro, anyway, that allows you to empty your package cache is Linux Deepin’s.)
So get real: if you want to be in “complete control of everything in/on their system”, to quote the article, including cleaning up when you’re done, you’re going to need to go to the command line anyway.
Thanks for your explanations Clem, it seems that everyone is short on time/resources 🙂
I do not know the synaptic code, and I just looked at my config : there is a configuration file, but at ~/.synaptic/synaptic.conf
It’s very short, only parameters like windows positions.
More interesting, there is a large global Synaptic configuration, but it is stored at /root/.synaptic/synaptic.conf !
Even the logs are in /root/.synaptic/log instead of /var/log/synaptic…
Oops, seems that our synaptic friend is not very standard for its configuration files 🙁
This does not imply that what you need to configure is already configurable, but at least, the configuration mechanism is there.
There is a parameter to clean the cache, both manually or automatically, in Synaptic Preferences, Files tab.
There are also two “CleanCache” and “AutoCleanCache” boolean fields in the /root/.synaptic/synaptic.conf configuration file.
Lionel: Thanks for the correction! That makes Synaptic more useful.
I would still argue that the point of this article is rather silly; it’s really, really, REALLY easy to pull up a terminal and type “sudo apt-get update && sudo apt-get dist-upgrade” for your updates. (Probably followed by a “sudo apt-get clean”.)
Using an apt-get command is easy but it’s not the point.
Some people prefer GUI tools, and they should not be forced to use a command line if they prefer using a GUI. What’s easy for someone is difficult (or maybe just less interesting or less funny) for someone else… “Command line vs GUI” is much like “vi vs emacs” or “C vs C++”, there is not a best choice for everyone, only choices more or less adapted to your own current preferences (and yes, this often changes with the age of the captain 😉
And speaking of simplicity, the easiest thing for an end user is to configure the upgrades to be done completely automatically, in the background, without any user intervention. If there is any problem during a dist-upgrade, anyway the typical end user would not be able to do any analysis, and would ask what to do.
The only solution in that case is simple, all upgrades must be executed flawlessly, without any user intervention, without any exception. That’s the price to pay to be accepted by a very large set of users. Even doing complete reinstallations instead of upgrades is an issue when you manage system from a long distance. It is not easy, and often not possible at all to do a full system reinstall through ssh…
> Some people prefer GUI tools, and they should not be
> forced to use a command line if they prefer using a
> GUI.
That’s all good and fine, but then you should find out how to install the GUI tools that do what you want, as Clem writes above, before you write an article complaining to the world about the ones that are provided in your favorite distro by default.
(And if you feel “forced” to use the command line to do something as simple as upgrading your system, you’re not going to get much sympathy from me.)
> the easiest thing for an end user is to configure the
> upgrades to be done completely automatically, in the
> background, without any user intervention
I’ve never had any problems with upgrades on Ubuntu-based distros, but I would never, ever have upgrades installed automatically on any computer of mine, or recommend that to anyone, especially beginners. That’s just an invitation for problems to occur, and takes control away from end users.
> … before you write an
> article complaining to the world about the ones that
> are provided in your favorite distro by default.
I am not the author of the article, my main distro is not Mint at this time, and I do not have time to complain.
Bad luck 😉
> (And if you feel “forced” to use the command line to
> do something as simple as upgrading your system,
> you’re not going to get much sympathy from me.)
I don’t need sympathy, and I decide myself what is right for me, nothing more, nothing less. Anyway, preferences are not technical issues, discussing technical points is useful, but discussing personal preferences is most of the time useless. You may as well discuss about your prefered background image, it’s interesting, but I already have mine…
Bad luck again 😉
> I’ve never had any problems with upgrades on
> Ubuntu-based distros, but I would never, ever have
> upgrades installed automatically on any computer of
> mine, or recommend that to anyone, especially
> beginners.
That’s contradictory. Either there aren’t any problems, you’re confident in the upgrade process, and you can have automatic upgrades. Or you are not confident in the process, which means that there ARE problems, and you do not do the upgrades. For a beginner, this means, no automatic upgrades AND no manual upgrades, because for a beginner, manual or automatic does not make any difference.
My choice for beginners is simple, all security updates, no other update. It may be automatic or manual, technically it doesn’t really matter. Psychologically, manual updates can help users to be more “in charge”. But the difference is ONLY in their head, technically it’s exactly the same (as long as they update the system regularly, which is often THE issue for manual security updates done by beginners…).
Of course, if a distribution does not make a difference between security updates and other updates, the choice is quickly done -> Distro unable to support required process, next distro.
> That’s just an invitation for problems to occur,
> and takes control away from end users.
Some end users do not want to be in control. In fact, many end users DO WANT someone else to be in control. And they have the right to make this choice. You make exactly the same choice when you buy a car and do not make the maintenance yourself, even for things that are very simple from the point of view of a car mechanic. For many users, computers are appliances, they want it to be as simple to use as a car.
It’s annoying when power users are locked down in the process, but a distribution maker has the right to give a higher priority to beginners than to power users. The main useful things that power user can do is help to implement solutions that are compatible with their needs, and probably also help to remind distributions makers that many beginners neither choose nor manage their distributions. As a result, it is difficult to make a successfull distribution for this group of beginners if there are too many limitations for the power users. Even small annoyances can be show-stopper for many people when they are doing unpaid support work. The power users who do tricky custom configuration on their own machine do not always have the time and envy to do the same things for all other machines that they manage in their spare time. It will always be less time consuming to support 10 machines with a single distro than 10 machines with 10 different distros, even for experts. This does not prevent to try different distros, but on distant end user machines managed only through ssh, experimenting with different distros and different upgrade processes may not be the best idea 😉
I used both tools to update… But now I want Synaptic back with full functionality more than ever.