I3wm and Ubuntu 20.04 server without any useless packages(github.com)
github.com
I3wm and Ubuntu 20.04 server without any useless packages
https://github.com/efazati/i3buntu
42 comments
After turning to Manjaro for my main distro, I feel like all the time I spent on trying to configure a base Arch install was totally wasted. The i3/awesome community editions are great - they are properly configured and setup with sane defaults and a minimum set of programs to ensure basic functionality you'd expect from your average OS (like wifi) works straight out of the box. I don't think I could go back to doing everything from scratch with Arch or even starting from Ubuntu (or other) where the default settings for i3/awesome are nigh unusable until you've sunk a significant amount of time into setting everything up.
> So I have no idea what the poster means by 'without any useless packages'
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).
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).
Maybe I'm missing something but there's no option for i3 in that Manjaro URL.
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.
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.
Make sure that your browser is directing you to the URL which includes the '#'. If it doesn't, you can find it under 'community' flavours.
edit: nope, you're right it isn't working!
edit: nope, you're right it isn't working!
The link doesn't work. That's just the page for the official releases. You have to go to Editions at the top of the page -> Community -> i3.
I spent a couple of years running an extremely minimal arch I3 install. It was fantastic doing things within my normal workflow, but when you have to introduce new tools, new network requirements, etc. it takes a fairly significant amount of effort. For instance- connecting to my university's wifi took hours and required hacking up a python script that wasn't compatible with my system.
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
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
I recently switched to KDE, Which lets you use i3 as the window manager. You still get KDE's bar and applets like the network manager and such. Not nearly as minimal as the arch setup I had before, and takes a depressing amount of time to log in and out in comparison, but so far is otherwise worth it for me.
> without any useless packages
redis, cmake, caffeine, unrar, vlc, postgres, docker, axel, fish, fzf...
really?
redis, cmake, caffeine, unrar, vlc, postgres, docker, axel, fish, fzf...
really?
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 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.
[1] https://regolith-linux.org/
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.
[1] https://regolith-linux.org/
Mhm. Looks nice. Is there an equivalent for sway/Wayland?
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..
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..
I will second this. I am also using regolith as a PPA on Ubuntu. Took some work to merge my i3 config with regolith's but it was worth it. Check it out if you currently use i3wm.
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/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.
- /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.
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 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:
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
> 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 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.
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.
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 longer) and occasionally send notifications when the user has a calendar event coming up.
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 have done the work in removing the "resistance" for you.
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.
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.
This is an asynchronous forum. If you find my information moot or unwelcome, you can just ignore it.
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.
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.
> 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 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.
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.
A completely vague term for "stuff I don't personally need". They were made and included because lots people want them and consider them useful, obviously.
That said, their definition of "useless" is completely at odds with mine, with them preinstalling slack, zoom, spotify and balena etcher.
That said, their definition of "useless" is completely at odds with mine, with them preinstalling slack, zoom, spotify and balena etcher.
So why then did you choose the "Windows among the Linux-distributions" as a base?
> So why then did you
Who? I am not the author.
Who? I am not the author.
In my (albeit limited) experience, those "useless" packages tend to be not so useless in order to have a somewhat functional installation.
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.
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.
You can include them based on your need instead of adding them because someone else likes to use them
> without any useless packages
This is as opinionated as it can get. No specific mention of any of those packages either. So what am I looking at?
This is as opinionated as it can get. No specific mention of any of those packages either. So what am I looking at?
You are right, I should update readme for more detail. but mainly there is no dm ( display manager ) also I didn't add most of the gnome related packages
I will write a good comparison
I will write a good comparison
It's nice to see people sharing - but this seems like a terrible way to install the needed packages, with a separate install per package, rather than a list of packages..
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.
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.
Why Ubuntu and not Debian for a project like this?
Having used both recently, I found when some vendors target just one distro to package for, they target Ubuntu because it's more popular, not Debian.
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.
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.
Debian can be a really great base for something like this. But I just assumed that most people are more comfortable working with something like Ubuntu.
You probably want Regolith Linux instead, or an Ansible-based solution which will work better for updates.
This project is an opinionated one-time install script. After initial install, good luck!
This project is an opinionated one-time install script. After initial install, good luck!
It is still installing Bluetooth support, ansible, terraform and all kind of things. Maybe you could group these so they can be disabled individually. I guess the notion of "useless" package really differs from users to user and doesn't really allow for a "standardized minimalistic experience".
You are right about those packages. I removed them, I will try to make better packaging system for diffrent usage
How is this different from installing ubuntu and then installing i3 ?
Is there much point in enabling compositing if we're installing i3 with this method? Would it even make a difference?
I3 supports compositing, I used it to have semi transparent floating windows (heresy for a tiling wm isn't it) and it also greatly improved some stuff such as smooth scrolling that was all teary.
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.
You are right. maybe it is better to remove all apps from the repo and put them in another place to let users choose based on their need
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')
[1] https://regolith-linux.org/