31–40 of 43 posts
In this project, you can install i3 from the Ubuntu server without installing anything that you don't need.
To be honest, this looks a lot more like a script to set up your preferred environment, not a minimal i3 install. It includes a lot of packages like Firefox, docker, fish, etc that have nothing to do with i3.
Why Ubuntu and not Debian for a project like this?
What are "useless packages" and why were they made?
Here's a subset of active processes on my system, where I know that these have never fulfilled their purpose, given the way that I use my computer: - /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/ev…
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
So I have no idea what the poster means by 'without any useless packages' but I can talk a little to why packaging i3 is good. 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…
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).
Earlier quoted context omitted.
Here's a subset of active processes on my system, where I know that these have never fulfilled their purpose, given the way that I use my computer: - /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/ev…
Using a heuristic like that is mostly unnecessary when your daemon supports socket/dbus activation. In that case it's only brought up on-demand when another program tries to send a message to it. 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…
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.
Earlier quoted context omitted.
Using a heuristic like that is mostly unnecessary when your daemon supports socket/dbus activation. In that case it's only brought up on-demand when another program tries to send a message to it. 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…
> try your luck with removing [...] 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…
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.
I just reinstalled my machine from Ubuntu 16.04 to 20.04. I'm using i3wm for a few years, and things never worked out of the box. The sound applet, VPN, and other small things that quickly add up. 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…
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..
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.
Earlier quoted context omitted.
> try your luck with removing [...] 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…
My comment was to give a practical alternative to the solution you were floating which is not really going to work in this scenario. I have done the work in removing the "resistance" for you. 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…
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.
How is this different from installing ubuntu and then installing i3 ?
This is Ubuntu server plus i3 and some opinionated other package choices. This ends up being fewer overall packages than Ubuntu Desktop plus i3.