Firstly, I like i3. Of all the tiling Window managers I've tried it seems to be the best mix of minimal, easy to understand, easy to configure and brings all the benefits of tiling WMs in terms of workflow and aesthetics.
What i3 doesn't do out of the box is look very good or have many common tweaks and quality of life improvements. This is something where the i3 community spin of Manjaro [0] shines because it bakes all of this in and gives you a gorgeous, modern-looking WM as default.
Regolith [1] was the first attempt I saw at providing this out of the box, but I'd definitely be interested in ways and means of containerising configs and i3 setups so that they are more easily accessible and can be tried out more easily.
[0] https://manjaro.org/download/#i3 (Direct link is broken. Click 'Editions -> Community -> I3')
Consider this targeted at Ubuntu users. Ubuntu out of the box has a huge amount of packages, and most packages have more dependencies than on "lighter" distros (anything optional is pulled in by default).
I currently use Regolith but I'm looking for something lighter but still doesn't force me to configure every single thing like battery or wifi.
edit: nope, you're right it isn't working!
I think a lot of the fight against 'bloat' is largely ideological and not really rooted in practicality, but it definitely makes for a good learning experience
redis, cmake, caffeine, unrar, vlc, postgres, docker, axel, fish, fzf...
really?
I'm now using Regolith [1] and loving it. It offers a clean and neat i3wm installation, but still uses Ubuntu's system admin tools. It was really simple to install: just install Ubuntu, add its PPA and run apt-get.
I highly recommend it for anyone that likes i3wm but doesn't want to be fiddling with configuration files to connect to a new WiFI or pair bluetooth headphones.
My external monitors behave nicer w/dock un-dock under gnome/Wayland. I'm planning to give sway a test when I get around to upgrading to 20.04..
Example: By default, Ubuntu+GNOME installs various utilities that you WILL need unless you want to do everything by hand. nm-applet, bluetooth applet, volume applet, etc.
Of course you have to add this to the i3 configuration manually, but that's the beauty of running i3. Yes you may have useless packages hanging around. But they will not be running UNLESS and ONLY IF you wish for that to be the case.
But when you need those "useless" packages, and you will most certainly need them to connect to your Wi-Fi network, you will be happy to have them already on GNOME and not have to install everything package by package and perhaps even compile an alternative software because it's the only one you found referenced on a reddit thread.
Basically, what I'm trying to say is, it's fun to do this once as an exercise to know how your computer works (learn what a compositor is, learn how pulseaudio works, etc.). But beyond that, it starts to get pretty tedious and not fun.
This is as opinionated as it can get. No specific mention of any of those packages either. So what am I looking at?
I will write a good comparison
https://github.com/efazati/i3buntu/blob/master/run.sh
Something like:
https://wiki.debian.org/AptCLI?highlight=%28%5CbCategoryPack...
apt-clone: https://github.com/mvo5/apt-clone
Or indeed like it's done here, but supplying a list of packets to apt, rather than a list of apt command lines to run one after another...
But the best way would probably just be a fork of regolith, and create a meta package.
I thought "No problem, the .deb format works on both!". But in practice the Ubuntu and Debian release cycles are not aligned and so their dependency trees are not always aligned, so some vendors .deb package for Ubuntu may not work on Debian.
You can choose Debian and hope you don't run into this, or you can choose Ubuntu and benefit from current and future support from a more popular desktop distribution.
This project is an opinionated one-time install script. After initial install, good luck!
- /usr/lib/evolution/evolution-source-registry
- /usr/lib/evolution/evolution-alarm-notify
- /usr/lib/evolution/evolution-calendar-factory
- /usr/lib/evolution/evolution-calendar-factory-subprocess
- /usr/lib/evolution/evolution-addressbook-factory
- /usr/lib/evolution/evolution-calendar-factory-subprocess
- /usr/lib/evolution/evolution-addressbook-factory-subprocess
- /usr/lib/evolution/evolution-calendar-factory-subprocess
- /usr/lib/evolution/evolution-calendar-factory-subprocess
Side note: I blogged about this last year, outlining a policy that distro package maintainers could adopt:
https://www.colbyrussell.com/2019/05/15/may-integration.html...
The idea is that any background service should be sufficiently self-aware, i.e., able to understand that (a) it is a service was installed by default (without explicit action on the part of the user; it was just included in the default install) so that it may at some point be of use, and (b) in the last (say) 4 months since the system was first installed, the service has never been exercised for its original purpose. Given those conditions, the system should retire the service for the foreseeable future, so that it no longer runs in the background.
The programs you listed are part of evolution-data-server and are used as the backing store for your calendar, clock and address book, which the GNOME panel integrates with. You can kill them but gnome-shell will start them right back up again when you open the calendar and it does a query to see if you have any events.
If you're in a non-GNOME session (like i3) and systemd is still starting those daemons, you can turn them off with some stop and disable commands:
systemctl --user stop evolution-addressbook-factory
systemctl --user disable evolution-addressbook-factory
systemctl --user stop evolution-calendar-factory
systemctl --user disable evolution-calendar-factory
systemctl --user stop evolution-source-registry
systemctl --user disable evolution-source-registry
That said, their definition of "useless" is completely at odds with mine, with them preinstalling slack, zoom, spotify and balena etcher.
Who? I am not the author.
Sure, I could. But refer to my comments in that post:
> I'll uninstall these sorts of things, unless there's any resistance at all [...] in which case I tend to immediately write it off as not worth the effort
My comment was not a StackOverflow-style cry for help. It was only meant to provide some data points in response to the person who asked, 'What are "useless packages"' and an alternative to the other person who dismissed the reference to "useless packages" on the basis that they "were made and included because lots people want them".
EDIT: Thanks for the detailed response, anyway. Since you've written it here, it might be indexed and become useful to someone who is trying to get to the bottom of things—and who maybe otherwise wouldn't have ever found out how to deal with this—and now they can.
Trying to guess which services are inactive and kill them off won't fly when the point of the service is to sit idle for a really long time (potentially on the timescale of months/years, i.e. just as long as you suggested if not longer) and occasionally send notifications when the user has a calendar event coming up.
Sorry, you misunderstand. The "resistance" was on the day that the system was installed and while casually scanning a list of installed packages and selecting ones to be removed, and then having the package manager complain about unsatisfied dependencies.
Your message is a path to achieving the original goal. But it's not a magic eraser that made the original resistance disappear. Your message here suggesting how one might get down to the bottom of things now is neither unwelcome nor welcome. It's simply moot.
> the point of the service is to sit idle for a really long time (potentially on the timescale of months/years
I'd wager that the difference in size between these two groups:
- those who go months or years without ever having used the thing, and then suddenly change their patterns and start getting use out of it; versus
- those who go months or years without using it, and never end up doing so
... is probably an order of magnitude (or maybe a couple) in favor of the latter group. Even ignoring that, there's an implementation strategy up for adoption that facilitates the former use case but doesn't involve persistent services sitting by idly, waiting for the first instance to come along. It doesn't have to be a trade-off; that's not an intrinsic consequence of the problem here.
It would be impossible for a daemon to categorize its users into those two groups and decide when to stop itself from running because it cannot see months into the future. The other implementation strategy already exists and I talked about it, it's to use socket/dbus activation to start the service on-demand. But that doesn't work in all cases such as with idle notifications, so I would argue that it is a trade-off.
The scheme I outlined doesn't ask anyone to look into the future. It asks that the service look into the past.
> I would argue that it is a trade-off.
Argue if you want—it seems you're predisposed to it. I said it's not an inherent trade-off. The developers/package maintainers are certainly making a trade-off. That's not the same thing as that trade-off being unavoidable.