跳转至内容

Open source | 开源

开源软件 | 开源社区 | 开源理念 | 开源与商业 | 开源可持续发展 等相关话的交流讨论
注: 这里的"开源"是泛化的共建共享概念, 范围包含 OSI的范围、自由软件、CC等相关内容

29 主题 131 帖子

子版块


  • 一个开源的技术学习、软件工具便捷下载、教程教学类项目构建和管理工具 - Github

    19 主题
    77 帖子
    sunrisepeakS
    多版本切换及工作空间命令演示

    利用工作空间机制, 支持自动版本切换(以node为例)

    speak@speak-pc:~/test/xvm$ node --version v22.12.0 speak@speak-pc:~/test/xvm$ xvm list node # 查看所有版本 23.6.0 22.12.0 speak@speak-pc:~/test/xvm$ xvm use node 23.6.0 # 切换到23.6.0 using -> target: node, version: 23.6.0 speak@speak-pc:~/test/xvm$ node --version # 验证版本 v23.6.0 speak@speak-pc:~/test/xvm$ xvm current node # 显示版本信息(xvm下有个test工作空间配置) [[test + global]] node: 23.6.0 nodejs: 23.6.0 --> [node] all targets added speak@speak-pc:~/test/xvm$ cd .. # 返回上级目录(自动切换到全局空间) speak@speak-pc:~/test$ node --version # node版本已经变成了22 v22.12.0 speak@speak-pc:~/test$ xvm current node # 查看当前版本情况 [[global]] node: 22.12.0 nodejs: 23.6.0 --> [node] all targets added speak@speak-pc:~/test$ cd xvm # 再次进入xvm目录(node会自动变成test工作空间的版本 speak@speak-pc:~/test/xvm$ node --version v23.6.0 speak@speak-pc:~/test/xvm$ 三种使用模式

    1-全局模式

    全局工作空间 支持使用注册/移除不同版本 支持版本切换/及别名设置 支持一键关闭或开启xvm对宿主系统的影响

    2-local模式

    基于目录的工作空间 工作空间继承控制(不继承及和全局版本进行隔离) 工作空间激活状态控制 工作空间配置可以编辑(一般用于项目控制版本) 记录使用版本并导出工作空间配置文件

    3-自定义工作空间 - (计划开发中)

    自定义工作空间且目录无关 (一般用于特定版本配置组合记录) 其他功能类似local 开源地址 https://github.com/d2learn/xlings/tree/main/core/xvm
  • 《计划-投射》快速绘制节点图的桌面工具,可以用于项目进程拓扑图绘制、快速头脑风暴草稿 - Github

    2 主题
    11 帖子
    sunrisepeakS

    @1049010335 基本元素是指的是做成组件式吗 直接创建表格?

  • 0 赞同
    2 帖子
    78 浏览
    LittlefeanL

    还没细看他们的争论评论具体内容,第一直觉上感觉项目命名结尾加后缀的方式,让原作者感觉自己被蹭热度了?

  • 开源的好处与坏处分析总结

    9
    1 赞同
    9 帖子
    70 浏览
    sunrisepeakS

    @Littlefean 可以搞赞助 vue 好像就这么发展的。但是mit使用好像并不需要手动授权好像

  • 开源协议总结

    4
    1 赞同
    4 帖子
    82 浏览
    LittlefeanL

    @sunrisepeak 在 开源协议总结 中说:

    CC和OSI感觉最主要的冲突点应该是 "是否能商用自由"

    确实,NC直接禁止商用了。CC系列感觉范围主要是一些创意作品而非软件了。感觉有人往github上发自己创作的一些“开源文章”可能有用吧。

  • GPL开源协议的传染性问题

    10
    0 赞同
    10 帖子
    68 浏览
    LittlefeanL

    @sunrisepeak 在 GPL开源协议的传染性问题 中说:

    个人感觉开源软件中 一般把代码公开的情况下, 遇到大问题的概率比较小。且多数情况下 现实对 这方面好像也是偏向“宽容”处理的。 往往 是否代码公开 是核心争议点

    确实

  • MIT这个非常宽松的开源协议究竟保留了什么?

    5
    0 赞同
    5 帖子
    46 浏览
    sunrisepeakS

    @Littlefean 在 MIT这个非常宽松的开源协议究竟保留了什么? 中说:

    如果把游戏引擎的runtime打包到游戏里的时候一般就要包含了这部分的MIT协议。

    但这个回答是被动的,它是否需要开发者主动在“关于界面”或“开发者界面”里提出使用了这个引擎作为技术支持?

    一般来说是不强制要求在界面特别显示, 但是一般建议是在关于中提到。 但似乎这就是属于 "宽松" 区域, 但如果是一个要发行的商业软件, 一般默认尽可能的在关于进行标识比较好

  • 一些有趣幽默的开源协议收集与整理

    7
    0 赞同
    7 帖子
    36 浏览
    sunrisepeakS

    @Littlefean 开源协议 很多时候是为了传播和共享 会偏向 "宽松" , 并再使用上一般默认大家会尽可能的遵守 (似乎某种程度一些协议可能还有故意不想受很多规则的限制甚至包括法律? 但符合要符合现实世界规则一般还是要很多考虑的, 可能也是一个发展的过程...)

  • 开源协议的更换问题

    5
    0 赞同
    5 帖子
    32 浏览
    LittlefeanL

    确实,忘了版本号的问题了,依赖都是有固定版本号的,同一版本号里开源协议不能变但版本号变了开源协议就可以变了。

  • 此主题已被删除!

    1
    0 赞同
    1 帖子
    10 浏览
    尚无回复