They'll have to convince the suits, many of whom think that RedHat ::= Linux.

Yeah, I also remember reading Christoph `20h' Lohmann's rant on systemd when Arch switched to it: http://thread.gmane.org/gmane.comp.misc.suckless/11928/focus=11934

1 members found this post helpful.

Yeah! And I loved his last sentence:

When your beloved opinion leaders raise that type of arguments, I can gently ask if the anti-systemd movement isn't in fact an commie fest?

What do you think is missing to become "Datacenter material"?
in other words: for any "non SMB" sysadmin to consider Slackware as an alternative to a systemd riddled distro, what do you think needs be done?

Slackware does great as a server distro, but a datacenter requires different tools for the enterprise use-cases, and to scale, some of them enumerated here: http://www.linuxquestions.org/questi...4/#post5100969

Think, for instance, of fifty 40U cabinets full of 1U blanks, with ten more full cabinets arriving monthly. Now, are you going to plug a keyboard, monitor, and dvd into each blank to install Slackware, or even open all their cases to clone their disks? Something like Spacewalk is a necessity, so you can just power the blanks up and have them network-install to different personalities while the admin monitors from their office workstation.

To justify the transition to their suited overlords, administrators will need to enumerate the company's use-cases and show that Slackware will jfw for them. That means Slackware not only needs to make the tools available, but also have documentation explicitly describing the use-case, stating that Slackware will work, and providing instructions for doing so. Fortunately that requirement dovetails nicely with another recently-started Slackware project. :-)

Enterprise-ready Slackware is doable, it "just" needs a hell of a lot of work.

I dug up some notes from the last time I was thinking about "Datacenter Linux", transcribing/annotating:

To bootstrap the larger system, the admin would need to conventionally install Slackware onto a system, and then install the DCL package, making it a "boss server". It would then provide installation services over the network so blank servers could use it to network-install to some flavor of boss or worker node (the differences being the authentication keys they were given, whether they copy all of the boss-specific data, zeroconfd configuration, and which Chef/Puppet recipes they use).

The package would:

* Put the slackware installation files in $DIR/slackware/$VERSION (could copy them from dvd or .iso file, make a symlink from elsewhere on the disk, or acquire them over the network),

* Copy the slackbuilds and their source tarballs to $DIR/SBo/$VERSION, and perform the equivalent of "sbopkg -r" (the initial copy could be distributed with the DCL package),

* Copy the boot image(s) for PXE to $DIR/pxeboot/$VERSION,

* Install the DCL-specific libraries, modules, scripts, cgi, and daemons,

* Initialize the inventory database,

* Configure/start named,

* Configure/start httpd,

* Configure/start nagios (or munin?),

* Configure/start dhcpd and tftpd, for PXE,

* Configure/start zeroconfd.


When a blank server boots, it is presumed the vendor or VAR has set its boot order to boot off local disk before network (PXE), so that if it has no operating system installed it will attempt PXE-boot and:

* Negotiate PXEboot with boss node via DHCP,

* Load a boot image via tftp and boot from it (this will just be Slackware with a few extra scripts installed, some of which are called from rc.local to continue the process described here),

* Wait for a zeroconf pulse (a UDP broadcast packet) directing it to the right boss node, or for a human to give it an IP address,

* Announce self to boss node (via https), and get a response setting its clock and telling it to either try again periodically (and how often, and with what stagger) or with instructions for network-installation,

* Receiving instructions ("obtain your net-install script and other things from <url>") might take a little while, because the admin may have configured the boss node to keep blanks in limbo until the administrator can look them over, choose a personality, and click "OK". When the blank announced itself to the boss node, the boss node made a notation in its inventory database, causing the blank node to appear as an entity in the admin's web-app control panel.

* Once instructions are received, the blank node fetches ssh keys, password hash, installation configuration file, recipes, and a network-install script via https and runs it,

* The network-install script partitions the blank's disk(s), creates filesystems, and https-copies the Slackware installation files from a boss node.

* Slackware is installed (like we do manually, but with no human input, only the installation configuration file obtained from the boss node),

* DCL-specific files/scripts are installed, along with a central configuration management tool like Chef,

* The node reboots itself, booting from its local filesystem this time,

* Chef takes over from there, receiving instructions from the boss node and running the recipes necessary for the new worker-node's personality, as well as installing/starting things every node must have (like nrpe, for Nagios checks). Depending on its personality, the node might become a new member of a load-balanced webserver pool, or a slave node in a replicated MySQL instance, or a GlusterFS data brick, or whatever.

* Slackbuilds and their sourceballs would be obtained from the boss node(s), so a hundred nodes wouldn't have to reach over the internet a hundred times to install a package. An sbopkg-equivalent tool will need to be written which operates without human input (sbopkg's "-e" option doesn't cut it; there are too many conditions under which it would block forever seeking input).

* Parallel-ssh tools (or their equivalent, like gexec) would be provided for additional central administration (besides Chef).

1 members found this post helpful.

I think Slackware already has an automated way to install packages (even third party): slackpkg+
With a pxe server and slackpkg+ (using templates), you can turn any standard slackware install into a specialized system.
All that is needed is have a "datacenter specific" package repository.

As long as Spock has a goatee in your universe, yes.

3 members found this post helpful.

The whole idea about systemd just seems like painting a pretty picture in front of you while tying your hand behind your back. In principle.

Having hard dependency on a specific startup scheme is another example of simply trampling on people.

If it has advantages for certain folks, it can be done elegantly. If other folks don't need it, don't want it or is counter-productive to them, things still must work and work properly.

Not to mention :
http://ewontfix.com/14/

I'm not flaming, it is about choice, and hard dependency on systemd is about taking it away.

Seriously? And this hard dependency kick your freedom of choice?

Lets see...

A GNU operating system, like Slackware, can run technicaly on three kernels: Linux, kFreeBSD and Hurd. See Debian GNU/Linux, Debian-GNU/kFreeBSD and Debian-GNU/HURD.

BUT, on that P.O.V., Slackware operating system make the Linux kernel as hard dependency. You aren't unhappy by that strong limitation of your freedom of choice?

I wonder what Slackware would be like with a BSD kernel?

Now SystemD is taking over networking management duties out the box with its latest release has its users crying now.


http://www.phoronix.com/scan.php?pag...tem&px=MTYxMTI

1 members found this post helpful.

And doth the Kraken yet groweth another tentacle.

Okay, while I abhor systemd's philosophy but can see where it has potential, this seems to be a step too far in my opinion.

If systemd-networkd is going to internally manage networking within the systemd hypervisor, then what purpose does dhcp-client, dhcpcd, network-manager, and such bring to the table, and with systemd fairly much being ran as a locked hypervisor with no console, how will it affect static ip addressing or will it force dynamic addressing? Can systemd even be built without networkd? How will it be configured?

For servers with certain functions using dynamic addressing isn't an option as some require static ip addresses to operate. For end users and workstations it's not so much an issue, unless you're on a static ip managed network then I can see a potential problem.

Not sure how much of questionability this addition will raise but sinking a tentacle into the networking infrastructure is not something PID-1 or any init system should be concerned with in any regards. One more possible failure point in my opinion.

My recommendation for Slackware's future would be to drop the entire "desktop" stuff and give Slackware a reliability advantage as a server OS by not having the whole freedesktop.org mess on board.

In my opinion the GNOME/KDE/Xorg/Wayland stuff won't survive beyond 2020, anyway. So hunting their dependencies would be a waste of time in the long-term perspective.

1 members found this post helpful.

Amazing!

Now, please enlight me, how droping the "desktop" crap will grow the Slackware reliability advantage as a server OS?