Re: Debian derivatives census: Inquisitor: status?
Hi everyone,
Sorry for the somewhat late answer. I'll answer everything in one message.
> The Inquisitor domain[1] does not resolve and seems to be expired.
> What is the status of Inquisitor? Is it still active, developed & used?
The domain expired for 1 day and was fixed promptly, thanks for the
information. Sorry for overlooking that issue, I've added it as an
alert to monitoring and hope it won't happen again.
>> Unfortunately I do not know about its current status, except that it is
>> actively used at least in ETegro Technologies company (http://www.etegro.ru/).
>> Development seems to be stopped, but project lives: it is rather mature
>> and stable enough for satisfying mass hardware testing.
I might add that from what I see from my current point of view,
Inquisitor is nowadays effectively forked a few times for the needs of
each particular company that implemented an Inquisitor-based solution
for its own production needs. For example, ETegro's fork was published
once at https://github.com/ETegro/Inquisitor - note that it's *very*
different from mainline Git tree, as it was done earlier as separate
svn migration, includes lots of ETegro-specific fixes, etc.
> Last commits appear to be around 2012:
> http://sourceforge.net/p/inq/mailman/inq-commits/?style=threaded
Technically, last commits were around 2013-10:
https://github.com/inq-team/inq/commits/master
inq-commits mailing list seems to be dead since switching from svn to
git - I doubt that there's a good idea to resurrect it for git-based
repository.
> BTW, Yocto-based LUVos (Linux UEFI Validation) distro, especially it's
> LUV-live release is probably the best hardware diagnostic distro these
> days. It bundles BIOS BITS, FTWS, CHIPSEC, and has additional tests.
> Created -- and actively maintained -- by Intel, targets BIOS/UEFI
> systems. Linaro is in the middle of porting it -- and its bundled tools
> -- to AArch64. Debian needs CHIPSEC package at least.
> https://01.org/linux-uefi-validation
I might be biased, but from what I see in LUVos description, it
pursues a completely different goal that Inquisitor. LUV concenrates
on firmware validation, combatting various security issues. It's for
situation when you suspect that your kernel configuration or something
like that might be off and thus you just lost some sort of
functionality you desire in a certain device - not for situations when
you have 1000s of a given device model with 1% of them having faulty
hardware.
Talking about "competitors", I'd say that primary competitor of
Inquisitor nowadays is PTS[1]. It indeed follows the same basic
principles (i.e. detecting configuration, running tests, reporting
results), it indeed has a relatively big user base, but PTS's author
(Michael Larabel) concenrates mostly on benchmarking stuff, while
Inquisitor is mostly suited for big-scale burn-in tests.
[1]: http://www.phoronix-test-suite.com/
> Thanks for the info. A mature stable project sounds like the perfect
> thing to merge into Debian in the form of a Debian Pure Blend:
>
> https://wiki.debian.org/DebianPureBlends
>
> There would need to be some packaging work initially but long-term
> maintenance would probably be minimal and yield always-available live
> images and offer the possibility of including hardware/firmware testing
> at install time as well as bringing more users.
Technically, it sounds like a good idea, but currently it would be
hard to implement as is. As of now, Inquisitor does not build against
now-stable jessie repositories - as far as I know, enterprises still
use lenny / squeeze builds with tons of in-house backporting and
custom-built kernels. There were a lot of infrastructure changes since
these days - namely, lb/lh received a major overhaul, whole systemd
transition stuff would require some work, etc.
There's one another aspect: Inquisitor is heavily biased to the needs
of technical-savvy testing operators, i.e. people who precisely know
what they are doing, know the procedures, are comfortable with dealing
with somewhat cryptic logs and output, etc. It's by no means a
"regular home user" solution when one expects to just push the button,
brum-brum-brum, and, voila, here's the result in simple human-readable
form like "your component X has failed, you need to replace it".
There might be an opportunity for some enterprise-backed Inquisitor
renewal in the near future, but that will probably concentrate on
ARM-based devices, again, with fairly specific booting & testing
requirements - and I won't hold my breath for this one.
If there's anyone out there who's willing to join the effort to port
Inquisitor to modern Debian codebase, then I might join in. If not,
then we'll just go with the flow, leave it as is, and see if any
opportunities will arise in future.
--
WBR, Mikhail Yakshin
Reply to: