90 seconds to boot? Are you counting from when you press the power button or is this 90 seconds after Lilo?
Slackware boots in 17 seconds here with a few things in rc.local (the 'compat' option in Lilo is really magic).
Post takes around 6 seconds, plus 5 seconds in Lilo screen.

The last time I looked at Slackware boot time, a big part of it was waiting on DHCP timeouts on ethernet network interfaces which might or might not even be plugged in (defaulting to 30 seconds per interface, so a minute on a dual-ethernet system).

Detecting carrier (whether the NIC is plugged in) from software is supported for -some- hardware, but not other hardware, and in the latter case all you can do is go through the motions on the assumption that there is a network attached, and deal with the DHCP timeout.

A better (albeit incomplete) solution would be to try to detect carrier on systems which support that, and skip DHCP entirely on interfaces not attached to a network, and fall back to the current behavior on systems which do not support such detection.

I looked at implementing that, but realized that I simply don't reboot my systems frequently enough to make it worthwhile, and put the idea on permanent back-burner.

I did reduce my DHCP timeout to 8 seconds in rc.inet1.conf though (DHCP_TIMEOUT). On my networks if DHCP doesn't happen in less than 8 seconds, it's never going to happen. This is not a solution suitable for every network.

If all of the interfaces defined in rc.inet1.conf are either assigned static addresses or plugged into a network with fast DHCP, of course, these delays do not manifest.

I have a Samsung SSD and Slackware is fast - and I don't even have TRIM (noatime) enabled in fstab, I am using JFS. I still hope later down the line maybe Slackware will allow installation using a FS based on NAND devices (JFFS2, YAFFS, F2FS). Don't get me wrong, the more 'traditional' fs work, but again with the ever growing adoption of solid state NAND devices, I still feel that using a FS that is solely optimized for such drives would be a logical idea.

Just as an FYI, trim and noatime are two different things. Trim is enabled in the fstab using the discard option (or using fstrim manually through the CLI). noatime, while typically suggested for SSDs, prevents updating access times for files and folders when they're accessed. It is commonly used on SSDs to minimize the writes to the NAND (although people would enable them on HDDs to minimize extra writes that can cause thrashing), but it probably wouldn't be enough to cause the NAND to fail for too many writes. That being said, I think I enabled it on my SSD (I'm at work and too lazy to ssh into my computer to check), mainly because I don't care if access times are recorded.

I meant also discard .

1 members found this post helpful.

On my Desktop on SSD it takes 11-12 sec plus 4 sec POST.
Cli - 9 sec.Upss mistake. There is realy 7 sec plus POST.
DHCP-On.

https://www.hostmat.eu/images/19773751042363431913.png

and I've got super duper systemD in a deep black ass hole

@all Excuse me for the off-topic.

Is that conky from Sbo? Please, which font?
Nice wallpaper too

If you don't like bsd-init you can put systemd on Slackware: https://github.com/Dlackware

That's the last / 1.9.0 / older edition of conky and old "remastered" by me script from somewhere probably conky site.

Wallpaper. Not remember from. Long ago. BUt YES
Here you are:

http://thundercr0w.deviantart.com/ar...atch-396466880


The font is .... hmm ...Noto Sans-8

As with most things in Linux distributions, configuration has huge effects on speed, disk usage, battery life, etc. From startup times to app load times, the configuration will have far more effect on these things than whether you're using Systemd, SystemV, or whatever.

Slackware has always been slow with the default fattykernel.

1 members found this post helpful.

In addition to what's already been said, booting Slackware in EFI mode will also be faster.

How do you set that up? By booting the installation medium in EFI mode.

1 members found this post helpful.

I always wanted to mess with EFI on Slackware (on Virtualbox) - but the latest Virtualbox release still doesn't work with EFI. It no longer crashes this time when I try EFI, but the bootup is stuck on GRUB and is frozen when trying to boot the Slackware ISO.

Thanks for the info.

Yes. From the time I press the power button to tty1 user login terminal.
Also, I did not count the time that LILO counts down 2 minutes for the boot menu.

I tried "chmod -x rc.inet1" and the boot time did reduce. However, I have to manually turn on the DHCP services later on after booting into the screen.

And what does it mean by "try to detect carrier on systems which support that"?