@lightning @apgarcia @zash @ska
No.
$find /usr/share/man -name perl\*|wc -l
152
$
Anyone reading this who now goes to find out what these #OpenBSD manual pages are, immediately proves the point that counting the number of manual pages with wc(1) isn't a valid criticism. They've demonstrated by their own actions that it's a metric void of meaningful information.
@apgarcia @lightning @zash @ska
The scope of the software makes no magic difference to whether it's a valid metric, as I said. It's an invalid metric _whatever_ the software is. Because it's feeling the width, not measuring the quality.
@apgarcia @lightning @zash @ska
You aren't _measuring_ overkill in any way, though. All that you're measuring is a count of roff source files whose names match a pattern.
You have zero idea from that whether there's overkill in some way. Any more than you'd have from counting the number of files for #OpenBSD or Debian man pages. Or #s6 or #GNOME man pages for that matter.
You aren't actually measuring the metric you want to employ. As I said, one has to be careful about one's metrics.
@JdeBP @lightning @zash @ska it's just an off the cuff, rough figure. take it with a grain of salt, but it tells me that something's wrong.
i've used both solaris's service manage facility and linux's systemd. i'm not enamored with either of them, but smf comes closer to the mark for me.
i'm starting to think that init is not a one-size-fits-all program. is the size and complexity of systemd or smf necessary for a server? maybe. is it necessary for a workstation? maybe not.
@benjamineskola @apgarcia @JdeBP @lightning @zash Indeed, it's way more difficult to design a service manager for a workstation than for a server. Workstations may include seat management, desktop management, user services, etc.
(Also, I know nothing about seat management and little about desktop, but I know a bit about user services and the way systemd manages them is, as expected, incredibly brittle.)
@ska @benjamineskola @apgarcia @lightning @zash
One of the older criticisms of #systemd development was that server use cases got far less attention than workstation, and indeed specifically laptop, use cases.
The always-on public HTTP server would be properly killed when the laptop lid was closed, but you had to look to a 4th-party plug-in to get service monitoring integrated into Nagios. (-:
@benjamineskola @apgarcia @lightning @zash @ska
I don't really buy the claim that #SMF _is_ complex in the first place. It certainly isn't by the standards of most systems of the early 2000s. Flexibility is not the same as complexity.
c.f. http://jdebp.info/FGA/unix-service-access-facility.html
When it comes to the need to set up and tear down services on the fly on a general purpose machine, all of the major service management systems are capable of this. None has the woes of the long-dead inittab(5).
@apgarcia @lightning @zash @ska
Again, though, that shows exactly why counting manual files with wc(1) is silly. It tells one nothing whatsoever about the amount of documentation one should read for any particular task. About all that it tells one is that documentation to be read exists, which is in fact a good thing.
No-one is daft enough to assert that because Debian has more than 81,000 man pages; the amount of documentation one has to read to use Debian is not commensurate to the task.
@apgarcia @lightning @zash @ska
In any case, you're definitely not looking at things from a sysadmin's point of view.
A sysadmin's view would in stark contrast be whether, say, systemd.unit(1) documents the search path that the software has actually used for 10 years. Because whether the doco is correct and informative is important, not how many files it is in.
If how many files it was in were important, we'd have long since junked the man system in favour of PDF files. (-:
@JdeBP @lightning @zash @ska your 81,000 man page count is wrong.
$ ls /usr/share/man/man8 | wc -l
784
$ ls /usr/share/man/man8 | grep -c systemd
116
@apgarcia @lightning @zash @ska
It's not mine. It's unix.com's count of Debian manual pages. Rounded down to the nearest thousand from 81,313.
@apgarcia @lightning @zash @ska
What you provided is nonsense, though. There aren't 784 section 8 manual pages in #Debian. There may be that from the arbitrary set of packages on 1 machine, but even that has nothing to do with what one needs to read in order to run a system.
For starters, one would be foolish to think that one even starts there, instead of the Debian Administrator's Handbook, which isn't measurable in man pages.
You just aren't measuring anything meaningful.
@apgarcia @lightning @zash @ska
No, it hasn't. You've wrongly convinced yourself that it has value, but there is no value at all from a practical standpoint, no metric that can be actually used.
Try this practical exercise:
Name one concrete quality measure that you can deduce about package A versus alternative package B in #Debian, from the knowledge that A has 46 manual pages and B has 106 manual pages.
Your counts of #systemd man pages are exactly as devoid of value as those numbers.
@JdeBP @lightning @zash @ska quality measure, no, i can't, and i never said i could.
the sheer number of man pages tells me that systemd is sprawling. that's all i ever claimed.
@apgarcia @lightning @zash @ska
"sprawling" is a quality judgment, though.
You're claiming that you can tell this about #systemd from knowing that it has 216 manual pages but cannot tell the same about package B with its 106 manual pages, despite having exactly the same information, the count of manual pages, for both.
Is package B "sprawling"? Is #s6 with 88 pages? Or #execline with 62 pages?
If you don't know for them, you cannot know for systemd based upon exactly the same information.
sprawling: to spread or develop irregularly or without restraint.
if that doesn't describe systemd, then I don't know what does. yes, it's a judgment. to me, it's also common sense.
JdeBP
apgarcia
ben
Laurent Bercot