Hi On 2016-01-07, Stephan Foley wrote: > Hello, I am working on a Fluxbox Debian Pure Blend: > > https://wiki.debian.org/FluxBox/Blend > > Currently, I am going to use discover, mdetect and read-edid for > hardware discovery but found in the repos hwinfo which is used by > Debian Edu and was wondering if this is a better tool. Description > follows: [...] As someone working on Debian derived live systems since the earlier kernel 2.4 days, I wonder why you think to need any of those on a modern linux system at all? linux >= 2.6, udev and kmod do a great job to probe all auto-discoverable devices on their own. The things they miss either can't be detected automatically or at least not in a safe way. Neither of which are typically found on systems supported by Debian systems whose primary purpose is running/ showcasing/ using a window manager. The i586/ i686 cutoff mostly prevents you from having to discover ISA devices or even weirder legacy system buses - and on embedded architectures with SDIO, similar non-discoverable buses and board specific boot procedures, you have bigger problems (e.g. getting FOSS display driver support) than anything discover/ mdetect/ hwinfo can help you with. Regarding read-edid, why?! X.org does a pretty good job detecting your screen, its native resolution and your common input devices these days (I'm too lazy to check for the exact version, but for a few years already). The only time you might want to override the auto-detected settings, is typically when automatic detection doesn't work (broken EDID, weird setups, etc. - but this usually means older than ~15-20 year old CRTs), in which case read-edid isn't very likely to help you either. Complex multi-screen setups just aren't something you can detect, as nothing will tell you which monitor is left/ right/ top/ bottom - so the only thing you can do there is sticking to X.org's defaults (clone) and providing an easy way to do xrandr based runtime configuration (a feature typically covered by modern desktop environments). These days, live systems basically need help (beyond the default features provided by a normal Linux/ Debian installation; the situation slightly differs for kfreebsd or probably hurd) in two areas[0]: - setting up a network connection (again, the kernel probes the required modules quite well, the problem is just a policy decision. Find 'the' network interface with a link beat and run a dhcp client, if that doesn't help, the user needs to configure it manually anyways - same for encrypted wlan, wwan, etc.) - and providing firmware blobs, if needed. - generating a fstab (and even this is largely optional these days, considering today's RAM sizes, auto-discovering an existing swap isn't as critical as in the days of yore, the other disks/ partitions are typically handled quite well with udisk2 and policykit in the typical desktop environments, although probably not using fluxbox). plus the things that aren't hardware dependent at all, like: - finding~ and cooking the rootfs to appear writable - forgetting stale state ((re-)generating machine IDs, clearing sshd keys, etc.)[1] - setting up live users/ preseeding[2] a sane configuration environment - intercepting reboot/ halt and properly shutting down the live environment - locales/ i18n/ keymaps - ... discover, hwinfo, hwdetect, kudzu, read-edid had their days of fame (or rather, they were a painful necessity), but at least on semi-modern linux systems they are pretty much obsolete for a couple of years already for anything resembling a remotely 'normal' system (anything with VGA/ DVI/ HDMI/ DP, PCI(e), USB and BIOS|UEFI with ACPI). And at least for the non UEFI/ACPI armhf/ arm64 world, either of those tools come way too late (as you need a SOC/ board specific bootloader and configure it to use the proper dtb; beyond that, kernel/ udev should just work as well for most auto-detectable devices there as well). Regarding "hardware detection", there typically is only one distant domain which could need some further refinements - namely helping the user to find missing firmware images for their devices (preventing them from just working out of the box, aka welcome the non-free blobbyness of the real world) or identifying additional packages you might not want to preinstall, but which are nevertheless useful (only) in combination with certain hardware (e.g. sane, if you have a scanner, fprintd if a fingerprint reader is present, something like this) - isenkram is supposed to cover this. You haven't really revealed if the target of your pure blend is an installed system or a live environment (the wiki page and your mail slightly tend towards a live system, but neither provide a definitive answer), but in neither case it should be much of a concern how to detect hardware (as that's either solved by d-i or your live framework in a desktop/ WM agnostic way) for you as blend maintainer. If you do, you're quickly leaving the pure-blend domain and venture into the derivatives land[3]. You'll probably find an audience with more specific knowledge in these particular areas on the debian-derivatives@lists.debian.org and debian-live@lists.debian.org lists. Regards Stefan Lippers-Hollmann [0] yes, I'm simplifying this a bit, but the days of black magic and voodoo are fortunately in the distant past and you don't need to do too much, to make a normal linux installation "portable". [1] this is basically the only problem where Debian packages could improve the situation for image based replication and distribution approaches massively, by implementing a global "factory reset" flag and removing (preventing it from entering the image)/ regenerating (on boot) all unique state. [2] on a pure-blend, the pre-seeding should be almost non-existent [3] unless you start to wear both hats, pure-blend- and live framework maintainer/ patch contributor, of course.
Attachment:
pgppOeqHoVA3x.pgp
Description: Digitale Signatur von OpenPGP