TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Identifying Software

120 点作者 ementally大约 1 年前

5 条评论

Zambyte大约 1 年前
I have felt spoiled by GNU Guix honestly. It has documentation that is comparable to Gentoo or Arch, power over your system that generally matches Gentoo (though a system-wide equivalent of USE flags is not yet available, individual packages can be configured), the ease of maintenance of a system like Fedora Silverblue, and one of the most approachable communities I have ever dealt with. I highly recommend playing around with it :)
评论 #39693920 未加载
评论 #39691179 未加载
评论 #39694403 未加载
weinzierl大约 1 年前
This is good take on the topic focusing on intrinsic identifiers. Guix has their own approach but the article also mentions SWHID[1] and OmniBOR[2] which are both contenders to fill that space.<p>SWHID is on its way to become an ISO standard[3]. OmniBOR is quite new but a highly interesting approach.<p>Because it does not directly solve any problems for Guix, it&#x27;s fair enough that they do not talk about much about extrinsic identifiers except to rightfully dismiss CPE as <i>&quot;showing its limits&quot;</i>, which is put mildly.<p>I think there is need for an extrinsic identifier standard beyond CPEs (in addition to intrinsic identifiers).<p>While intrinsic identifiers allow us to pinpoint artifacts exactly sometimes this is not what we want. Sometimes we deliberately want to talk about sets of artifacts together, like variants or versions of an artifact. One contender would be purl[4] (as in package URL and not the older persistent uniform resource locator).<p>[1] <a href="https:&#x2F;&#x2F;www.swhid.org" rel="nofollow">https:&#x2F;&#x2F;www.swhid.org</a><p>[2] <a href="https:&#x2F;&#x2F;omnibor.io" rel="nofollow">https:&#x2F;&#x2F;omnibor.io</a><p>[3] <a href="https:&#x2F;&#x2F;hal.science&#x2F;hal-04121507v1&#x2F;file&#x2F;2023-03-27-SWHID-kickoff.pdf" rel="nofollow">https:&#x2F;&#x2F;hal.science&#x2F;hal-04121507v1&#x2F;file&#x2F;2023-03-27-SWHID-kic...</a><p>[4] <a href="https:&#x2F;&#x2F;github.com&#x2F;package-url&#x2F;purl-spec">https:&#x2F;&#x2F;github.com&#x2F;package-url&#x2F;purl-spec</a>
datadrivenangel大约 1 年前
&quot;we believe binary artifacts should instead be treated as the result of a computational process; it is that process that needs to be fully captured to support independent verification of the source&#x2F;binary correspondence. &quot;<p>So binary artifacts should verifiably come from source code, which can be accomplished by signing it with a signing mechanism specified in the source code?
评论 #39690918 未加载
评论 #39699951 未加载
GlenTheEskimo大约 1 年前
Yep, it&#x27;s software
评论 #39697487 未加载
robblbobbl大约 1 年前
Way too late but downvoting always works.
评论 #39727875 未加载