How necessary is it to have a separate /boot partition these days though? I have one because my root is LUKS-encrypted, but I think Grub could handle booting from an unencrypted ext4 root. I guess it would still fill up eventually, but maybe not before a re-install for other reasons.

Grub can actually handle booting from an encrypted ext4 root as well, no /boot needed. You do end up entering the password twice by default, but that can be dealt with by using a key file.

Lots of blog posts out there with instructions to convert existing installations, for example http://dustymabe.com/2015/07/06/encrypting-more-boot-joins-t...

On UEFI systems, the /boot partition needs to be FAT32. So there's that. :P

The UEFI system partition is mounted at /boot/efi. /boot itself can be a regular filesystem, or part of the root filesystem if you have no unusual requirements.

Depends what bootloader you use. Gummiboot (thus systemd-boot) can't handle having the EFI loader and the kernels on different partitions (thus having /boot and /boot/efi separate has questionable benefits). Not to mention that full disk encryption causes problems with /boot.

That isn't necessarily a problem; Debian handles this by means of a kernel postinst hook that copies the newly-installed kernel from its installed location in /boot to /boot/efi/EFI/DEBIAN (or wherever gummiboot expects to find the kernel, I can't remember off the top of my head).

That systemd refuses to support anything other then EFI at /boot puts it into opposition with existing practice (as seen in Debian, Ubuntu, Fedora and SUSE).

I would expect all of those to fall in line with systemd soon enough...

    sudo crontab -e 

and put this :

    0 5 * * 1 apt-get -y -q autoremove 1>/dev/null

I have it on our servers so we avoid get filled with junk on /boot

For maintainability, you might want to consider using /etc/crontab or /etc/cron.d or /etc/cron.daily to store this instead of the root user cron. Especially on servers.