Re: piece of mind (Re: Moderated posts?)
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
Reply to: