[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Spam:]Re: “What’s in a package”
From: |
Konrad Hinsen |
Subject: |
Re: [Spam:]Re: “What’s in a package” |
Date: |
Wed, 22 Sep 2021 20:20:27 +0200 |
Katherine Cox-Buday <cox.katherine.e@gmail.com> writes:
> As we've seen these past years with COVID-19 and the world's supply
> chains, efficiency has some kind of inverse relationship with
> robustness. If you go too far down the path of efficiency, you are not
> very flexible, and you're building sand castles.
That's exactly what I have seen happening in scientific software for a
while :
https://hal.archives-ouvertes.fr/hal-02117588
> It's for this reason I appreciate having "robust" software underneath
> my sand castle. At least I know only so much can crumble :)
100 % agreement!
> I want to be careful here in what I suggest. I think it is very
> important that Guix remain a bastion of robust software with very high
> standards. I don't want to see the PyPi PyTorch packages of the world
Me neither. My suggestion was for support in Guix the tool, not Guix the
software distribution. People can/should package their sand castles in
their private channels.
> So with your example: make it really easy to transform that PyPi
> package into a terrible Guix primitive of some kind, but don't let me
> commit it to Guix proper.
I trust our maintainer team to not let this happen.
> Maybe interactive software that introspects how a package
> is written and behaves at runtime (in a container?) and utilizes the
> homoiconicity of scheme to suggest modifications of the package, or
> next steps. E.g. expand the linter to suggest things like
That sounds interesting!
> Speaking of industry, I don't think we leverage software to build software
> enough.
Definitely not.
> And by the way, none of those ideas would be possible if Guix weren't
> such a robust and sane ecosystem.
Exactly. We can discuss (and more) adding sloppy stuff on top of Guix,
but it wouldn't work the other way round.
"Jonathan McHugh" <indieterminacy@libre.brussels> writes:
> Your focus regarding a transition from exploratory to robust is
> important (though may have equal significance in the other
> direction?).
Not equal as I see it, but yes, it matters as well, for dragging a
stable package out int the open again for significant improvements.
> Would security experts have (understandable) criteria to prioritise
> choices for 'robust corridors' within an ecosystem of sourcefiles and
> encapsulated blobs?
I'd love to hear from security experts too!
Konrad.