On 15/10/14 06:01, Miles Fidelman wrote: > Scott Ferguson wrote: >> On 15/10/14 03:33, Miles Fidelman wrote: >>> Scott Ferguson wrote: >>>> On 15/10/14 01:54, Miles Fidelman wrote: >>>>> Scott Ferguson wrote: >>>>>> On 14/10/14 23:54, Miles Fidelman wrote: >>>>>>> Andrei POPESCU wrote: >>>>>>>> On Lu, 13 oct 14, 18:30:41, Miles Fidelman wrote: >>>>>>>>> Gee.... assuming that you don't run anything that >>>>>>>>> has systemd dependencies and/or systemd-shim is >>>>>>>>> actually maintained and kept up-to-date. >>>>>>>> Have you actually looked into what depends on systemd? >>>>>>>> ---------------8<------------------->8--------------------------------- > > What, it's NOT a football match?! Anyway - points as in bullet > points :-) :) 'twas understood - put it down to a poor attempt to lighten a heated topic.
---------------8<------------------->8---------------------------------> > There's also stable as in interfaces and behavior - particularly > important in a platform. Yes. Agreed. That I've had no insurmountable problems is not to say you haven't - or that your problems are trivial. I don't know what I don't know (now I sound like Yogi Beara) and I don't know your situation. While an increasing complexity does mean my learning curve increases it's a price I'm prepared to pay so I can deal with hardware and user changes that are forced upon me - e.g. efi, cryptographic support, bluetooth and multi-state USB devices (cdc_ether particularly) - and (sob) touch-screens. I can barely bring myself to mention BYOD without reaching for Lithium... (yes, of course you should be able to stream music from your phone through the desktop speakers - via bluetooth, as you walk into your office, and update your Twatter status while in the carpark? - give me ten minutes while I update my Friendface status, sigh). > > As to "no crashes" - well, not exactly, but that has more to do with > Xen than Debian. I'm not saying all my Debian builds, or Xen experiences have been perfect - but damn near perfect-able (problems have always been fixed eventually). ---------------8<------------------->8---------------------------------> > Parenthetically, I do notice that some here (not you) seem to take > offense at mentions of and/or comparisons with other distros and > O/Ss. I'm not entirely innocent - people using Debian derivatives and claiming to use Debian in order to get support do, um, bring out my more unpleasant emotions. And fanbois. > Personally, I think sharing experiences about alternatives is > an important topic. Yes. Constructive criticism and comparisons. Just as I want to hear from users of my Debian builds about what they see as better in other builds. Quite distinct from fanboi chants and non-constructive "I'm going to camp out in the foyer and annoy everyone until I get what I want while simultaneously and continually threatening to leave (perhaps they lack the bus fare?)". It's a long time since I've seen many user-support posts on this list - too many rent-a-mob protesters in the foyer? ---------------8<------------------->8---------------------------------> > Similar situation. Out of more than curiousity, if not for embedded > devices and desktop, what derivatives appeal to you? Did - no longer in production, Debian From Scratch. For me there is nothing that compares:- strict separation of software by license; multiple kernel choices; sheer number of packages; brilliant packaging system; (relatively) healthy community; range of architectures supported. And no animal fetish mascot. :) That I've years invested in it is a dangerous bias I'm aware of. > > Re. pre-seeding and post-seeding: So far, my experience with > pre-seeding has been largely to automate the Q&A that's built into > the standard installer, and to install a few extra packages. I'm > wondering how granular one can get in terms of defining the install > of the base system -- i.e., to what extent one could define a > pre-seed file that installs sysvinit-core. Any thoughts on this? It's something I'd 'probably' try with a post-seed (easier than hacking the d-i). In many instances I do that already, at a minimum a server build (that's not based on a image) has a post-seed that modifies config files, installs keys, and removes packages (e.g. debconf-i18n, aptitude, tasksel doc-debian, laptop-detect, man, man-db etc) and installs packages (e.g. mc, localepurge, zip, unzip, bzip2, arj, rar, unrar, deborphan, custom kernel, etc). I doubt I could pre-seed to change the init without an init-choice mechanism pre-existing in the d-i (I understand that is the plan). No different to radical embedded builds that require custom compiled packages - d-i would have to be modified, which is only economical in some situations (scale/demand). ---------------8<------------------->8--------------------------------->> >> I don't want to learn multiple inits - I'm lazy (pick one). > > Me to. Since I've already learned sysvinit, customized some of our > scripts, and it all just works - I REALLY don't want to either: a. > learn a new init system b. deal with the (probably subtle and hard to > find) ways that systemd's claimed support for legacy systemv init > scripts is less than 100% Agreed - but... at the same time I also recognise the need to regularly review those customisations for security purposes lest I be like the fella that jumped of the 10th floor and was heard to say "so far, so good" - as he passed the 3rd floor. ;) I surely didn't want to learn PCI (bus) - inferior in every way to MCA, and, something about the second law of thermodynamics. :) ---------------8<------------------->8---------------------------------> > Well... I don't know. I'm really thinking hard about a really lean > platform, with each app. in its own container - there's a lot of > appeal to that model, and it seems to be working for a lot of people. > Simpler to secure and maintain. ---------------8<------------------->8---------------------------------> > Fairly simple really -- mail, mailing lists, some simple web > servers, and our development sandbox. All but the last just needs to > stay up and running 24x7, with minimal care and feeding. Sounds simple... but experience has taught me there are many ways to do that, the client is always right (except when they're knocking on the wrong door), and rarely do I inherit systems that are configured (or documented) the way I would - definitely not to say I do it better, just that I often find myself unable to understand the logic the predecessor employed. SPF, DKIM, password policies, actual change control, documentation - these are all areas where I find huge difference in "simple" systems like that. Given that some of my work involves wading through the sewage of security breaches I'm cynical/biased about "the old school is best school" attitude. ---------------8<------------------->8--------------------------------- >> Sufficient comment has been made on the bulk of that paragraph. As >> for unaudited.... I'd be breaching the Coc to use the appropriate >> adjective for how *little* GNU/Linux *has* been audited. > > There is that. Then again, DHS has been funding Coverity to do > automated code analysis of lots of open-source stuff. Which the NSA furiously tries to simultaneously secure and weaken. They're not the only crazed prospectors digging for gold in them thar data hills. :( ---------------8<------------------->8--------------------------------->> > Isn't that "plan for the worst you can imagine, expect even worse?" > Sigh... I 'thought' that was (proper) risk management - plan for the unforeseeable (and build-in an exit strategy). > > Cheers, > > Miles > Kind regards -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/543de6fa.4060...@gmail.com
