Normal view

There are new articles available, click to refresh the page.
Before yesterdayMain stream

超过 10 亿投入,理想宣布开源自研汽车操作系统

By: 芥末
29 March 2025 at 09:00


理想汽车董事长李想在 2025 年中关村论坛年会上宣布理想汽车自研整车操作系统「理想星环 OS」进行开源。

「理想星环 OS」主要包括车控操作系统、智能驾驶操作系统、通信中间件、虚拟化平台等核心部分,预计将在 4 月底上线开源社区。

对于开源这件事,李想后来发了一条微博,更详细的讲了下。

其中表示自研 OS 是“逼上梁山”。首要原因是 autosar 的高使用成本和长芯片适配周期,其次是对 autosar 闭源的性能和安全性的担忧,毕竟看不见内部。

星环 OS 这次开源其实暗含着摆脱和替代 autosar 的意图。

要先解释一下 Autosar 是个啥,它究竟有多重要。

Autosar 是一种汽车软件架构,同时在他背后也有同名的一系列相关标准和组织。

它存在的意义其实在于作为一种标准化的方案,autosar 能够通过提供基本软件模块规范、定义应用接口以及构建基于标准化交换格式的通用开发方法,来提高汽车电子系统和软件的可扩展性、可靠性和互操作性。

发起者主要是德国公司,像宝马、博世、大陆集团、奔驰、西门子 VDO 和大众等都是其创立成员,之后福特、标致雪铁龙、丰田、通用等也相继加入。

但 Autosar 的标准和架构都是不要钱的,主要要钱的都是符合 Autosar 标准和架构的具体软件产品的一次性费用和授权费,以及配套工具链使用授权费。

大概了解了 autosar,我们回到理想这边。

为了解决刚才提到的两个缺点和 2021 年「芯片荒」的困境,理想开始自研操作系统,累计投入超过十亿元以及近 200 人的研发团队。

除此之外,理想汽车在智能化道路上还遇到了系统关键性能、安全性、可靠性等方面问题。因此,理想汽车开始一步步扩大车用操作系统自研领域,最终完成了整车操作系统的全栈自研。2024 年,理想自研的操作系统实现商用上车。

研发起来相当不容易,但却带来了十分显著的效果。

自研操作系统将新型号芯片的适配时间从 6 个月减少到 4 周,并且支持了车用芯片的各种架构,做到芯片选择自由,极大缓解了芯片荒对供应链的影响。

同时理想的操作系统做到了全链路融合,响应速度快了 1 倍,响应稳定性提高了 5 倍。反映到高速 AEB 上,时速 120 公里下的刹停距离可以减少7米。在信息安全上也具备了更好的能力。

当然,给 Autosar 的钱也不用交了,每年可节约数十亿的成本。

那投入这么大的项目,理想为何决定把它开源呢?

至少有两大好处。 一是智能汽车专用的操作系统技术门槛高,需要座舱、智驾、底盘等横向和应用、系统、硬件等纵向联合创新,开源能够让大家资源共享,合力研发,理想自己的成本压力也会小一些。

另外,现在的开源生态中并没有面向整车的操作系统,理想把已有的成果开源出来,可以让大家避免「军备竞赛」,更专注在其他的差异化功能上。

有业内人士评价理想开源时举了 Android 的例子,说通过开源理想汽车说不定能像 Google 一样,成为智能汽车领域的「规则制定者」。

然而就在同一天,Google 决定不再维护目前安卓 AOSP 的公开分支,逐渐关闭相关的的支持性资源,并可能停止更新有法定开源义务(GPL 等协议的代码)外的组件的源代码。

#欢迎关注爱范儿官方微信公众号:爱范儿(微信号:ifanr),更多精彩内容第一时间为您奉上。

爱范儿 | 原文链接 · 查看评论 · 新浪微博


独家 | Google 决定终止开源 Android

By: 杜晨
27 March 2025 at 12:07

出于新闻报道和纯兴趣讨论目的,爱范儿对知名科技公司的战略做过各式各样的「沙盘推演」,设想了许多场景。

但没想到,最不可能的一种情况,居然正在 Google 身上发生。

Google 已经决定停止 Android 开源项目AOSP

AOSP(Android Open Source Project) 是 Google 主导的开源项目,为所有 Android 设备操作系统提供基础框架和核心组件。它相当于一个「毛坯房」,开发者可自由下载、修改和分发其代码,并基于此构建定制化系统,包括 Xiaomi HyperOS、vivo OriginOS、OPPO 的 ColorOS、甚至 Pixel 手机的 Android 系统,都是基于 AOSP 构建的。

Google 对 Android 的维护分为两条路径:公开的 AOSP 分支面向全球开发者开放,包含纯净的开源代码,不涉及任何 Google 专有服务。任何厂商或个人均可基于此分支开发系统。而内部闭源分支仅供签署了 GMS(Google Mobile Services) 协议的厂商使用。

具体来说,Google 将不再维护目前 AOSP 的公开分支,逐渐关闭相关的的支持性资源,并可能停止更新有法定开源义务(GPL 等协议的代码)外的组件的源代码。

海外媒体 Android Authority 最先报道了这一情况,Google 也确认了此事。

从下周开始,所有的 Android 开发工作将仅在 Google 的内部分支进行。在一段时间后,外部分支可能将不再公开甚至彻底关闭。并且,AOSP 的持续集成/交付 (CI/CD) 工具和环境也可能关闭,甚至 Android Gerrit (https://android-review.googlesource.com/) 也可能会关闭。从今往后,只有 Google 内部的员工能够访问 AOSP 的内部分支,或是提交代码。Android 的开发过程将不再透明。

从高维度来看,Google 将逐步缩减 AOSP 所包含的内容,直至 AOSP 作为开源项目,以及作为一种概念,都不复存在。

以史为鉴,OpenSolaris 项目(也就是 Solaris 操作系统对应的开源项目)在 Oracle 在收购 Sun,宣布对 OpenSolaris「延迟开源」后,直到 Solaris 开发部门解散为止,都没有以 CDDL 许可证开放过半句代码。

谁也不知道,Google 对 Android Authority 承诺的「继续开源,只是推迟」,是不是只是一句空话——毕竟无限期的推迟,也是一种推迟。

根据爱范儿的了解,Android 闭源的总体思路是最终只保留 GPL 强传染许可证要求开源的部分,主要是 Linux 内核态驱动和补丁。其他中层、上层等之前采用 Apache 等宽松开源许可证的部分,最终会闭源;未来的 Android 版本发布后也不再对外公开发布、更新源代码。

此事的决策层级在 Google 高层管理者级别。据信他们做出此决定的时间不晚于 2025 年初。整个策略的执行将会在一个更长的期限内完成,至少持续数年,直到 AOSP 彻底失去意义。

Google 此举的真实动机尚不明确,但根据爱范儿的分析和了解,主要是为了节约开支和增加收入

AOSP 在不同的维度上(比如版本号、发布进度等)有着多条代码流水线和大量的分支。再考虑到项目的上下游代码、多公司之间的协作,进一步复杂化,维护管理起来非常困难,产生大量的计算资源和工时成本。Google 可能希望节约这些成本。考虑到 2025 年初 Android 部门已经向所有员工提供了「自愿离职」的选项,削减开支的思维逻辑不难理解。除此之外,签署了合作伙伴协议的厂家也有义务捆绑 Google 服务,为 Google 提高广告收入,变相提高了公司的整体收入。

好在目前来看,闭源 AOSP 对业界的直接影响并非灾难性,对终端手机用户直观影响也微乎其微。

绝大多数主流手机厂商早就和 Google 签订了各种授权合作伙伴协议。在现有协议安排下的厂商,仍然可以得到和使用最新 Android 源代码,获得 Google GMS 认证,正常预装 Google Play、Gmail 等服务和应用,得到 Google 的支持。一切生意照旧。

真正的影响更多不会直接展现,而是会在更长的时间里从侧面体现。后文会详细解读。

 

AOSP,不存在了?

如下几点需要澄清:

  1. 因为大部分 AOSP 代码通过 Apache 2.0 许可证发行,任何人都可以 fork 一份。其他代码服务平台上也有各种 AOSP 的镜像,例如 GitHub 和国内的 Android 社区。Google 无权要求其它「非官方」 AOSP 代码库下线。已经开源的,无法被撤销开源。
  2. 也就是说,只要能从其他非官方渠道下载,人们仍然可以使用 Google 最后更新的 AOSP 代码,也可以按照自己的需要对其进行修改。原则上如果你有足够多厉害的开发者,也可以把之前的 AOSP 变成自己的系统,去维护和更新。

Android/AOSP 从来不是一个真正的开源项目,社区里的原教旨主义者也一直对其颇有微词。

前文提到,Android 目前运行于 Linux 内核上,后者是 GPL 许可证开源的。GPL 是一个强传染性的许可证,要求所有衍生工作都必须按照 GPL 许可证同样开源,从而贯彻无限开源、扩大社区的精神。

而当年 Google 为了构建 Android 商业生态,创建了平衡开源与商业需求的许可模型。Google 将 Android 平台分为几个部分:底层的 Linux 内核部分保留 GPL v2 许可证(按照要求),而 AOSP 的大部分代码则采用了更为宽松的 Apache 2.0 许可证。这种许可结构使设备制造商能够修改和定制 Android 而不必开源所有修改,同时允许企业在 Android 平台上构建专有应用和服务。Google 自己的专有服务 GMS (Google Mobile Services) 则与 AOSP 分开,并采用不同的许可条款。这种混合方法创建了一个既保持开放性又为生态系统提供商业灵活性的模型。

具体来说,Linux 内核基于 GPL 许可证,虽然 kernel module 需要依据 GPL 强制开源,然而 userspace 应用并不受 GPL 传染性的影响,因此无需开源。部分 userspace 应用程序也与传统的 Linux 发行版不同,例如使用 bionic libc 替代 glibc,使用 toybox 替代 busybox 等。此外,Google 还使用了「硬件抽象层」(HAL),允许厂商将不想公开的商业机密资料,比如一些特定的专有功能对应的背后代码和逻辑,存放在这一层上面,即提供了一套 stable ABI(应用二进制界面),使得厂商可以独立于 Android 框架层更新他们的专有代码。

当然 Linux 基金会对 Google 这种违背开源精神的操作方法很不爽,一度将 AOSP 从 Linux 开源项目中除名。

结果就是,AOSP 底层部分按照 GPL 开源的,大量中层按照 Apache 宽松开源(部分闭源),在此基础上的应用就可以自行按照开发者意愿和商业目的选择各自的开闭源属性了。

Google 自己也是这样做的。事实上,自从 2013 年的 Android 4.4 KitKat 之后,所有的 Android 版本都不再完全开源。Google 为 Android 系统开发的一部分驱动、UI,以及应用层的大量大量核心产品和服务,也就是人们熟知的 GMS 套件,都是闭源的。

AOSP 存在着,但它并不是完整的 Android。这也是为什么很多系统开发者都会强调「原生 Android」(指 Google Nexus/Pixel 的操作系统)不等于 AOSP。

尽管 AOSP 是个开源项目,Google 也不常合并第三方提交的合并请求(合并 AOSP 代码需要 Google 员工的批准,而不少 PR 就死在了 Gerrit Review 里)。这也是不少开发者认为 AOSP 和典型开源项目之间的最大区别。让参与者难以在 AOSP 里获得真正的参与感。

在 AOSP 项目的官网上,Google 写了这样一段「治理理念」:

Google 领导 AOSP,负责维护和进一步开发 Android。尽管 Android 由多个子项目组成,但 AOSP 是严格的项目管理。Google 将 Android 视为一个单一、整体的软件产品,而不是一个发行版、规范或可更换部件的集合,并对其进行管理。Google 的意图是让设备制造商将安卓移植到设备上;他们并不实施规范或策划发行版。

这段话已经把 Google 的意图描述的够清楚了。如果 AOSP 是一头干活的驴,那么卸磨杀驴的时候已到。

 

Android 闭源,将会带来怎样的影响?

主要结论:主流手机品牌和它们的用户不需要担心。

首先让我们重温一下Google 和 Android OEM 之间的协议关系:

  1. AOSP,任何厂商都可以使用 AOSP 进行开发,不需要获得Google 的同意;
  2. Android 兼容性承诺协议 ACC、移动应用分发协议 MADA、企业设备补充协议 EDLA 等,不一而足。通过协议,Google 和 OEM 之间建立商业约束。签订了 ACC 协议的 OEM 通过 AOSP 开发的操作系统,才能够称之为 Android 操作系统,获得 Android 商标使用权等权益。
  3. Google 移动服务 GMS,包括Google 服务核心、账号体系等后台功能,以及前台的 Google Play 商城、YouTube、Gmail、Calendar 等应用。公司签署了上述协议,并且手机型号通过了Google 兼容性测试,才可以预装 GMS。

ACC、MADA/EDLA 等协议的组合,确保了Google 对 Android 操作系统有着大体上的绝对控制。

包括小米、vivo、OPPO、三星等在内的当今绝大多数 Android 手机品牌,和Google 都签订了协议。没有意外的话,Google 应该已经联系它们进行安抚,并且确保未来的合作照常进行了。

在过去有相当一部分设备和芯片厂商,它们利用 AOSP 开发产品,却不从 Google 获得 Android 设备认证,设备不需要预装 GMS 全家桶,也能够避开 Google 的认证要求。

非认证 Android 设备五花八门,数以十亿甚至百亿计。通过这次闭源 AOSP,Google 有可能引诱非认证设备厂商向自己低头,签订前面提到的各种协议。

一种极有可能出现的情况是,基于 AOSP 开发的智慧座舱系统,可能代码也不会再无偿提供给全世界的厂商了。除非车企和 Google 签订协议,它们将无法得到最新的代码。当然,车企也可以继续使用已经开源的旧系统开发。

这不是已经发生的事实,只是一种可能性。Google 这次闭源 Android,不排除有一个小的动机就是试图夺回非认证设备市场,或者至少能够从中分一杯羹。这个大市场,虽然是设备厂商自己打下的,但如果没有 AOSP 确实也不会是今天的样子。

顺着这个角度,非认证 Android 设备消费者可能就会受到影响了,当然同样不会很明显。影响主要来自财务方面:OEM 想继续预装 Android 操作系统,就必须要服从 Google 对设备的管理和要求。这个成本当然会被转嫁给消费者,导致支付更高的价格。除此之外,消费者也只能使用 Google Play 等渠道下载应用,第三方应用市场(例如 F-Droid)等的生存空间也变得更少,Google 也可以向所有的应用内支付收一笔费用。

部分厂商可能不愿意屈从 Google,产品退出市场,消费者的选择权就缩减了;但与此同时,任何 Google 在闭源之前已经发布的 AOSP 代码,理论上仍然可以使用。厂商可以随意 fork 代码,自己开发、更新、维护。估计智能冰箱的消费者不会在意冰箱是否预装最新 Android 操作系统。

不过,这恐怕就又回到了「Android 碎片化」的老生常谈:如果非授权设备厂商继续一意孤行,用老的、不再有官方维护的代码去开发产品,届时碎片化恐怕就不是版本号那么简单了——而是可能出现类似于今天的中国,推送、版本、功能、外观、名称、体验等全方位碎片化,并且向全球范围扩大的一副诡异图景。

开发者权益侵害

AOSP 的闭源,对于 Android 应用第三方 ROM 开发者来说,影响更为明显。

曾经 Android 第三方 ROM 百家争鸣的景象,也将被历史掩埋。ROM 开发者的最好结果,是用 AOSP 最后更新的版本去修改,然后维护当前版本,到它慢慢过时,直至最后放弃这项事业。

至于应用开发者,他们仍然可以从 Google 获取需要的 SDK,在后 AOSP 时代内应该不会有太大的直接影响。

不过在此之前,由于 Android 已经存在相当程度的碎片化情况,开发者为了适配各版本系统、各品牌机型,需要获得不同厂商的系统代码,以及设备作为测试机。这对于中小型,特别是独立开发者来说都是不小的成本。目前尚不清楚这种情况在今后会不会愈演愈烈。

如果中小开发者生存环境被遭到进一步挤压,传导效应就是强者恒强,创新被遏制,进而发生更多的垄断。因此,Google 在做了它该做的事情之后,应该要给出后续方案,确保中小开发者的生存。

最极端,却又最不出意外的做法

此前在中美技术脱钩的大背景下,爱范儿曾经构思过 Android 对中国手机厂商「断供」的几种可能性:禁止在海外销售的手机中显示 Android 商标、禁止预装 GMS、对中国厂商「指向性」闭源 AOSP,甚至中止这些厂商的授权并将其从 OHA 中解约/除名。

在所有可能性中,完全闭源 AOSP 是可能性最低的。爱范儿一度认为这样做实在太不体面了。

在智能移动设备的萌芽阶段,Google 做出开源 Android 的决定,不仅获得了技术开放的名誉,更是在当时将大量厂商和用户从塞班、Windows Mobile,以及诺基亚和黑莓的手中赢了过来。

当然,诺基亚、黑莓和微软各自走了弯路,对Google 获胜起到不小的助攻作用。但 Google 开源 Android,毫无疑问,是今天 Android 在移动操作系统市场抢下超七成份额的道路上,最正确的决定。

Google 内部仍有员工认可开源这项事业的科技普及化意义和长期价值。无论出于业务和上级要求,还是个人身份,他们为 Android 项目编写代码,做维护工作,而 AOSP 也是这些工作的载体。然而 AOSP 对于 Android 和 Google 的商业价值,早已不可同日而语。

尽管这次操作的主要动机是节约成本,但长期来看,也会对 Google 增加收入带来一定帮助。毕竟在过去,Google 很难从那些运行基于 AOSP 操作系统的非认证设备上获得直接收入或数据等间接利益。

在这一事件之前,Google 通过 Android 赚钱的方式,主要是在伙伴协议的框架下对 OEM 进行收费授权认证。 想要在商业合规的框架下使用 Android,厂商需要签署协议。具体协议内容方式等细节可能会有不同,但大的规则是不变的。Google 的主要收入来源是通过预装的Google应用和服务(搜索、Play商店等)获取的广告收入和应用分成。

显然,非认证设备无法给 Google 创造收入,AOSP 的存在却「给人做嫁衣」,作为任何一家商业公司恐怕都想要尽快跟这些设备和厂商切割。

#欢迎关注爱范儿官方微信公众号:爱范儿(微信号:ifanr),更多精彩内容第一时间为您奉上。

爱范儿 | 原文链接 · 查看评论 · 新浪微博


BlinkShot – 开源免费 AI 图片快速生成工具

By: DUN
15 December 2024 at 17:12

DUN.IM BLOG

DUN.IM BLOG

我们还年轻,可不想看到这个世界处在毫无自由、隐私的边缘。

BlinkShot 是一个以 AI 人工智能技术即时生成图片的免费服务,这是开源项目,背后使用 AI 加速云服务「Together AI」和图片生成模型 FLUX,这项服务特性是能在非常短的时间内依照输入的提示词生成各种图片,以毫秒为单位,生成的图片也丝毫不逊色,有兴趣的朋友可以玩玩看。

目前 BlinkShot 支持英文提示词,也可以直接叫 AI 服务帮你生成〔例如用 ChatGPT 或其他同类型服务〕,另一个方法是使用图片转文字 AI 工具,例如:Image to Prompt等工具,将喜欢的图片快速转换为英文提示词,最后稍作修改再生成想要的图片。

BlinkShot 目前没有使用的生成数量限制,还有个「Together API Key」栏位可自定义自己的 API 密钥,生成的图片素材皆可免费下载使用,AI 图片基本上也不会受到版权限制,使用于个人或商业用途都没问题。

Generate images with AI in a milliseconds

进入 BlinkShot 后直接输入提示词就会立即生成图片,整体速度非常快,过程中如果继续输入其他形容或是提示词,图片会即时更新,相较于其他同类型的 AI 图片生成器来说确实非常强大!

下方会显示生成的图片历史记录。

通过 BlinkShot 生成的图片看起来很逼真,也能依照用户需求调整成各种风格、样式,越仔细的提示词就能生成更细致准确的结果。

生成过的图片历史记录会显示于下方,可以随时切换回去查看。

在图片点击右键即可下载保存。

在图片上点击鼠标右键、选择「另存图片」后将图片保存下来即可使用。

BlinkShot 未来也会加入下载按钮,让用户更方便获取图片。

TimeLapseCam – 让抽屉里的闲置安卓手机变身为延时摄影神器

By: Anonymous
15 October 2024 at 12:59

DUN.IM BLOG

DUN.IM BLOG

我们还年轻,可不想看到这个世界处在毫无自由、隐私的边缘。

TimeLapseCam 是一款 4MB 大小,只需要 6.0 就可以运行的 Android 延时摄影,可以在屏幕关闭的情况下继续录制延时,还能自定义调整分辨率、定时录像、禁用快门声,没有录制限制,堪称闲置安卓手机的最佳伙伴。

Contribute to woheller69/TimeLapseCamera development by creating an account on .

谁抽屉里还没有一两部淘汰下来的安卓手机呢?(没有请举手)

如果,我是说如何还能开机,那么拿出来试试这款应用,说不定解锁了新姿势。

TimeLapseCam 是一款简单易用,但暂无中文界面的 Android 延时摄影应用,不过其已经配置的很好了,打开就能用。
设置界面
默认一秒拍摄一张照片、不限时,直到你点击停止。可以修改拍照间隔,最长 10 分钟一张,也支持自动结束时间,最长 46 个小时。

还能定时开始拍照,以及关闭屏幕后继续拍照。

在 TimeLapseCam 中打开 REST API 之后,就能用浏览器打开 http://192.168.2.182:8085/rest,看到如何使用 API:

REST API v1:
GET /1/ctrl/status: Get current state: [stopped/running]
GET /1/ctrl/start: Start recording
GET /1/ctrl/stop: Stop recording
GET /1/ctrl/param: Get parameter
GET /1/device/battery: Get battery percentage
GET /1/current/img: Current / last recorded image
GET /1/current/imgcount: Image count
GET /1/current/lastimg: Last image: Name, Timestamp and URL
GET /1/img/list: List image folders
GET /1/img/listhtml: user clickable HTML page
GET /1/img//list: List folder / images
GET /1/img///list: List folder / images
GET /1/img//…/: Download image

比如:http://192.168.2.182:8085/1/img/TimeLapseCam/2024-10-15/TimeLapseCam0.mp4 可以直接播放最近一段视频

Stirling PDF – 免费开源的 PDF 编辑工具,拥有超过 30 个的全面功能

By: Anonymous
16 October 2024 at 12:50

DUN.IM BLOG

DUN.IM BLOG

我们还年轻,可不想看到这个世界处在毫无自由、隐私的边缘。

Stirling PDF 是一站式的 PDF 编辑,让用户能对 PDF 文件进行各种编辑操作,包括分割、合并、转换、重新组合、新增影像、旋转、压缩等等,特色是免费、开源GitHub〕,过程中文件只会存在用户的设备上,若在处理时有暂存于服务器的内容在下载后会即时从服务器删除,不会记录保存或追踪任何资料,相较于在线工具来说是更安全、的解决方案。

1 Locally hosted web application that allows you to perform various operations on PDF files – Stirling-Tools/Stirling-PDF

Stirling PDF 提供多元的 PDF 编辑功能,涵盖文件组织、格式转换、安全性、检视与编辑等工具,满足各类文件处理需求,用户无需额外下载、安装软件,只要通过即可进行操作,Stirling PDF 有中文在内等多国语言界面〔在我写这篇文章时中文字串翻译率已达 93%〕,进入、找到对应的功能后就能直接进行编辑。

这项服务目前可以做到的功能包括:

1. 文件组织

2. 格式转换

3. 签名与安全性

4. 检视与编辑

5. 进阶功能

顺带一提,Stirling PDF 还有提供 Windows 版本,可以在没有连上的情况下使用,如果有兴趣的朋友可以在 GitHub 找到下载链接,原则上两者功能差不多,无论在线版或 Windows 程序都不用付费、也无广告干扰。

Stirling PDF

进入 Stirling PDF 网站后先从右上角语言选择「中文」。

Stirling PDF – 免费开源的 PDF 编辑工具,拥有超过 30 个的全面功能

接着从上方「工具」就能看到完整功能,依照类型分为:组织、转换为 PDF、从 PDF 转换、签名与安全性、检视与编辑和进阶工具,也可以直接从首页输入功能名称列出相关工具。

有一个 PDF 万用工具是整合旋转、裁切、分割、移除、新增图片等功能,进入后先点击左下角新增要编辑的 PDF 文件。

加入后 PDF 页面预览就会显示于下方,每一页都可单独旋转、删除或调整页数,将光标到页面中间时还会出现其他编辑选项,例如裁切或是加入图片,其实操作上很直觉,稍微摸索一下就会。

编辑完成别忘记点击右上角「下载」保存新的 PDF 文件。

另一个压缩 PDF 也是很常在在线工具看到的功能,选择文件、设置压缩比或是自动模式〔自动调整质量以使 PDF 达到指定大小〕,就能快速压缩 PDF 以获得更小的文件容量。

点击压缩后就会开始处理,完成后自动跳出下载提示,我以大约 9 MB 的 PDF 文件、手动模式 3 级测试后获取一个约 2.5 MB 的新文件,压缩成效相当好,而且图片并没有失真或模糊等情形。

另一个也很常用到的功能是「分割 PDF」,可以将 PDF 指定页面删除、或只是留下需要的页面,使用方法也很简单就不多加赘述,Stirling PDF 会有预先设置的示例提示,用户照着格式稍作修改后就能完成相关编辑任务。

如果要说 Stirling PDF 有没有比较特殊、少见的功能,有一个「自动涂黑」工具很有用,用户只要输入要涂黑的文字,选择 PDF 后就会自动将识别到的文字涂黑,确保隐私和安全性,同时也省去手动编辑文件的时间,操作上更有效率哦!

下图就是使用自动涂黑工具识别、涂黑的 PDF 文件示例,指定文字就会被涂黑处理。

copyparty – 免费开源强大的文件服务器,支持 WebDAV、FTP、媒体播放等超多功能

By: Anonymous
19 October 2024 at 12:16

DUN.IM BLOG

DUN.IM BLOG

我们还年轻,可不想看到这个世界处在毫无自由、隐私的边缘。

copyparty 是一款功能非常丰富的多功能文件服务器,主要用来你电脑、服务器、设备里的文件,并通过、WebDAV、FTP 等方式访问,还支持播放音乐、上传文件、权限设置等功能。

几乎可以在任何有 Python 环境的地方运行,还支持 Docker 托管,以及 系统下的单可执行程序,甚至可以在 中运行。虽然运行很容易,但我不敢说它简单易用。

Portable file server with accelerated resumable uploads, dedup, WebDAV, FTP, TFTP, zeroconf, media indexer, thumbnails++ all in one file, no deps – 9001/copyparty

copyparty 给自己的定位是「便携式文件服务器,具有断点续传、重复数据删除、WebDAV、FTP、TFTP、零配置、媒体索引器、缩略图++,全部集成在一个文件中,无依赖。」

所有的功能集中在一个 .py 文件中,718 KB,直接运行就可以了。Windows 系统有编译好的 .exe 单可执行文件,双击也即开机用。其他平台直接 python copyparty-sfx.py 就行了。

就是文档太啰嗦了…看不下去。

直接运行就可以在浏览器访问 http://127.0.0.1 了,默认会使用 80/443 端口,打开就是这样的:

可以上传、、播放、听歌、看图片…非常纯粹的文件分享。有一种 Alist 的感觉,不过它不支持网盘。

只需要在启动的时候添加一个用户,就能设置权限了,包括只读、文件夹限制等等:

这一行的意思是创建了三个用户:u1/u2/u3,为它们挂载文件夹 music,对 u1/u2 两个用户只读,u3 用户可以写。

但注意有参数后,访问端口就变化了(3923)。

copyparty 默认开启了 WebDAV,只需要在你的 WebDAV 客户端里直接连 http://ip:3923 就行了。

甚至,你可以通过 WebDAV 把这个文件夹映射为 Windows 的网络磁盘,不过 Windows 默认需要 https,改一下注册表就好了。

而 FTP 则需要在启动的时候添加 --ftp 21 参数,用户名密码和上面的设置相同,不设置就支持匿名访问。

❌
❌