回帖

注意: 该帖子在版主未审核以前将不会显示。

会员名称:
电子邮件:
标题:
帖子图案:
附加:
(增加附件)
可使用的文件类型: fgb, rar, gif, jpg, pdf, png, txt, zip
限制: 3 每贴
请注意,任何上传的文件在版主审核前都将不会显示。
验证码:
《九评共产党》一共有几评?(请用阿拉伯数字回答):

快速键: 按下ALT+S可以直接发帖, 按下ALT+R则可以预览帖子.


帖子总览

作者: jingyue 发表时间: 四月 20, 2017, 07:46:24 pm

原文:(英文网页)

Developer Commentary: Philosophy, Evolution of TrueOS/Lumina, and Other Thoughts.

by Tim | Apr 19, 2017 | History | 1 comment

TrueOS and Lumina Developer Ken Moore recently took to Discourse to answer a few questions about the development philosophy for TrueOS/Lumina and provide some insight why these projects have evolved the way they did. I’ve edited and reproduced his answers here, but please feel free to browse, contribute to the original threads, or make new threads for questions on Discourse:

Thread 1: https://discourse.trueos.org/t/developer-blog-entries/1221/16

Thread 2: https://discourse.trueos.org/t/upstream-packages-will-start-breaking-the-future-of-trueos/1252/6

 
Philosophy of Development

 
No project is an island.

 

Every single project needs or uses some other external utility, library, communications format, standards compliance, and more in order to be useful. This is especially true with graphical applications, since they need to utilize the current: display system (X11/Wayland), audio system (OSS, ALSA, PulseAudio, SNDIO, etc.), and more.

 
A static project is typically a dead project.

 

A project needs regular upkeep and maintenance to ensure it continues to build and run with the current ecosystem of libraries and utilities, even if the project has no considerable changes to the code base or feature set. The ecosystem is a moving target. If a project stops upkeep, the passage of time increases the odds the project ceases to build and run.

 
“Upstream” decisions can have drastic consequences on your project.

 

Through no fault of yours, your project can be rendered obsolete or broken by changing standards in the global ecosystem that affect your project’s dependencies. For example, look at the the audio subsystem “wars”. ALSA vs PulseAudio is the fight that people are more familiar with (ALSA lost), but do you remember the “JACK” audio system? JACK was soundly beaten by ALSA, even though Jack was/is better at low-latency functionality. However, JACK losing to ALSA meant nearly all development/support for Jack has disappeared. Furthermore, all those audio recording/mixing utilities which used Jack are rendered nearly unusable by this upstream decision.

 
Operating system focus is key

 

What OS is the project originally designed for? This determines how the “upstream” dependencies list appears and which “heartbeat” to monitor. For Linux-based utilities like Okular or Firefox, this means the only supported audio subsystem is PulseAudio (even if we have OSS on FreeBSD which works 10,000x better), because PulseAudio is the only audio system officially supported on Linux, the app’s primary development platform. For FreeBSD and TrueOS, this presents a massive challenge to continue to support Okular and Firefox, as those applications are now essentially incompatible with the native subsystems used on our OS. While not impossible to support, it takes a lot of time and effort to “port” those apps over to work with FreeBSD, often introducing bugs and other usability issues along the way.

 
Evolution of PC-BSD, Lumina, and TrueOS

 

With these principals in mind – lets look at PC-BSD, Lumina, and TrueOS.

 
PC-BSD

 

PC-BSD was largely designed around KDE on FreeBSD. KDE/Plasma5 has been available for Linux OS’s for well over a year, but is still not generally available on FreeBSD. It is still tucked away in the experimental “area51” repository where people are trying to get it working first.

 

What about KDE4 on FreeBSD?

This runs into the problem with static projects discussed above. It is basically a dead project, as it is replaced by version 5. This means it is continuing to accumulate security vulnerabilities like hald, OS-incompatibilities, and is relying on other dead or dying projects for critical functionality (policykit/consolekit – both replaced by systemd on Linux). For PC-BSD 10.x, we tried to mitigate a lot of the changes in KDE by making our OS configuration utilities desktop environment (DE) agnostic, but that only gave us a short reprieve from the underlying decay. It also introduced a a “split-brain” framework where our functional and supported tools were available simultaneously with the DE’s dysfunctional tools.

 
Lumina

 

As a developer with PC-BSD for a long time, and a tester from nearly the beginning of the project, I was keenly aware  the “winds of change” were blowing in the open-source ecosystem. This was especially true in the desktop environment subsystem, long before systemd was announced. Because of this, I started working on a FreeBSD based desktop environment that did not rely on all these Linux based subsystems and frameworks. This was so we could ensure a FreeBSD based desktop OS could outlast other Linux based desktop implementations which now regularly have their fundamental frameworks ripped out and replaced.

 
TrueOS

 

All of these ecosystem changes finally came to a head for us near the beginning of 2016. KDE4 was starting to deteriorate underneath us, and the FreeBSD “Release” branch would never allow us to compete with the rate of graphics driver or standards changes coming out of the Linux camp.

In response, we started rolling monthly “snapshots” of PC-BSD based on the FreeBSD “Current” branch (also to prepare for FreeBSD 11.0). Surprisingly, this “rolling” release model for monthly snapshots was solving a lot of the longstanding issues with PC-BSD. There are newer drivers. Bugfixes are available in a timely manner. Critically, the project now has a single “supported version”, which makes better use of our limited developer hours.

At the same time, we started switching to Lumina instead of using KDE by default. During this switch, we discovered much of what we were working on started “clicking” together. The interface was stable. There is only a single set of OS configuration utilities. The number of “upstream” bugs from Linux effecting us dropped considerably. Is Lumina as “finished” as KDE? Definitely not! However, critical issues are now resolved simply and permanently.

 
The Rename and Next Steps

 

With all of these changes and the lack of a clear “upgrade” path from PC-BSD to the new systems, we decided it was necessary to change the project itself (name and all). To us, this was the only way to ensure people were aware of the differences, and that TrueOS really is a different kind of project from PC-BSD. Note this was not a “hostile takeover” of the PC-BSD project by rabid FreeBSD fanatics. This was more a refocusing of the PC-BSD project into something that could ensure longevity and reliability for the foreseeable future.

Does TrueOS have bugs and issues? Of course! That is the nature of “rolling” with upstream changes all the time. Not only do you always get the latest version of something (a good thing), you also find yourself on the “front line” for finding and reporting bugs in those same applications (a bad thing if you like consistency or stability). What you are also seeing is just how much “churn” happens in the open-source ecosystem at any given time. Although, I personally think the “churn” is a bit more aggressive now. Because the changeover to a rolling model is still fairly fresh, the developers and contributors are still adjusting to some of these new realities and working on implementing contingency frameworks and/or automated QA tests to help mitigate some of the churn. However, all this takes time.

We are devoted to providing our users (and ourselves – don’t forget we use TrueOS every day too!) a stable, reliable, and secure experience. Please be patient as we continue striving toward this goal in the best way possible, not just doing what works for the moment, but the project’s future too.

 
Lumina Desktop Utilities: Why so many?

 

There are a few reasons to develop these small utilities:

 
Missing functionality in TrueOS

 

Sometimes we cannot find an open-source application to add to the TrueOS base install which fits our criteria. However, filling the functionality is critical. The Insight file manager (lumina-fm) and lumina-archiver are two good examples of tools developed to “fill a hole” in TrueOS.

 
Future-proofing TrueOS

 

Sometimes a utility we’ve been using for a long time starts losing functionality. This usually occurs when the upstream project starts expecting more dependencies either unavailable on FreeBSD or add numerous undesired. When this happens, we look for a replacement or write one ourselves (see first point).

Note this process sometimes starts quite a while in advance of the current app completely breaking. We try to proactively anticipate development trends for any utility TrueOS relies on, so if the time comes we have no glaring holes in our project.

lumina-pdf is a utility that falls into this camp. okular may currently work, but we expect that to change soon. While qpdfviewer is currently a valid replacement for okular, moving to Wayland will result in that utility becoming nonfunctional. Because Wayland integration is “down the road”, lumina-pdf is on the back burner.

 
Developer “Fun Time”

 

As a developer, it is very useful to take those small bits of extra time to do something different. This provides a “playground” to re-think an application, experiment with new libraries or features, and grow as a developer. If one of these projects becomes something useful, then more “official” time is used to polish it up and release it. However, not everything makes the cut.

lumina-mediaplayer is a good example. It began as a hobby project to replace pithos as my Pandora radio application. Pithos is fragile with LibreSSL versions and GNOME3 integrations, which frustrates me. Through tinkering, lumina-mediaplayer has gradually become useful to more people than myself. The local-file playback functionality is largely to provide baseline functionality for the user who doesn’t want Pandora. It also fills a niche as a “fallback” utility in case somebody doesn’t need the depth that VLC or another “full-featured” media player provides.

 
The TrueOS stance on external applications:

 

Where TrueOS is concerned, it is not our responsibility to ensure the availability or functionality of Linux-based apps. This is more the responsibility of the FreeBSD community and ports committers. What we focus on is the reliability, stability, and dependencies of the “base” applications that we pre-install on systems. This ensures the most general use-cases are reliable.

Here are a few types of application functionality we generally review:

 
– General Applications –

 

    File Manager – Can you browse/open files graphically?
    Terminal – Can you get a virtual CLI?
    Web Browser – Can you get to the internet?
    Email Client – As old fashioned developers, we like working clients.

 
– File Support Applications –

 

    PDF Viewer – Can you download, view, and print official documents and/or give presentations?
    Text editor – Both CLI and graphical.
    Multimedia Player.

 

Note these applications don’t need to be massive or cover every possible file type or use-case. Rather, they need to cover the basics (like an office workstation or web-user) and be functional all the time.

Concurrently, the “desktop” functionality needs consideration:

    Is it possible to login with an arbitrary user account (AD/LDAP/Local)?
    Can the user launch or manage applications easily?
    Are system notifications and status easily visible? (battery status, network connectivity, etc)
    Do TrueOS + Lumina run on low-end systems or systems without GPU acceleration?

These points are what we consider the “core” functionality of TrueOS – all other use cases (audio/video production, graphic design, radio broadcasting, [your-usage-here]) are not seen as the responsibility of the TrueOS team itself, but more the larger FreeBSD community to ensure “Application X” is available and functional.


1 Comment

    Raul Rodriguez   
    Raul Rodriguez   on April 20, 2017 at 1:55 am

    Sorry you may have felt you had to write this. But I am glad you did. I knew sooner or later linux apps would become a problem for BSD. I sometimes felt I should switch to linux because of that. I would have hated that. This blog will make me stick it out. I always felt more apps should be written as native BSD. I know it ain’t easy. I wish I could contribute, but don’t BSD nor linux. Grew up on windows, I knew enough just to survive that OS. I think your doing a great job. Thanks for all you do.


Reply

作者: jingyue 发表时间: 四月 20, 2017, 07:36:33 pm

原文(英文)链接 https://www.trueos.org/blog/developer-commentary-philosophy-evolution-trueoslumina-thoughts/

(以下为谷歌在线翻译的中文网页,详细请看原文链接,)

开发者评论:哲学,TrueOS / Lumina的演变和其他想法。

由蒂姆 | 2017年4月19日 | 历史 | 1条评论

TrueOS和Lumina开发人员Ken Moore最近采访了“话语”,回答了有关TrueOS / Lumina的发展理念的几个问题,并提供了一些洞察为什么这些项目的发展方式。我在这里编辑和转载了他的答案,但请随时浏览,贡献给原来的主题,或发表新话题的话题:
主题1: https : //discourse.trueos.org/t/developer-blog-entries/1221/16
主题2: https : //discourse.trueos.org/t/upstream-packages-will-start-breaking-the-future-of-trueos/1252/6
 
发展哲学
 
没有一个项目是一个岛屿。
 
每一个项目都需要或使用一些其他外部实用程序,图书馆,通信格式,标准合规性等等才能有用。图形应用尤其如此,因为它们需要利用当前的显示系统(X11 / Wayland),音频系统(OSS,ALSA,PulseAudio,SNDIO等)等等。
 
一个静态项目通常是一个死亡的项目。
 
一个项目需要定期的维护和维护,以确保它继续建立和运行与现有的图书馆和公用事业生态系统,即使项目没有相当大的变化的代码库或功能集。生态系统是一个移动目标。如果一个项目停止维护,那么时间的流逝就会增加项目停止运行的可能性。
 
“上游”决定可能对您的项目产生巨大的后果。
 
通过没有错误,您的项目可能会因为改变影响项目依赖关系的全球生态系统中的标准而过时或破坏。例如,看看音频子系统“wars”。ALSA vs PulseAudio是人们更加熟悉的战斗(ALSA丢失),但你还记得“JACK”音频系统吗?JACK被ALSA严重殴打,尽管Jack在低延迟功能方面表现更佳。然而,JACK输给ALSA意味着几乎所有的杰克开发/支持都消失了。此外,使用Jack的所有音频录音/混音实用程序在上述决定中几乎不可用。
 
操作系统的重点是关键
 
最初设计的项目是什么操作系统?这决定了“上游”依赖列表的显示方式以及监视哪个“心跳”。对于基于Linux的实用程序(如Okular或Firefox),这意味着唯一支持的音频子系统是PulseAudio(即使我们在FreeBSD上运行的OSS的运行效果更好),因为PulseAudio是Linux正式支持的唯一音频系统,该应用程序的主要开发平台。对于FreeBSD和TrueOS,这是一个巨大的挑战,继续支持Okular和Firefox,因为这些应用程序现在基本上与我们操作系统上使用的本机子系统不兼容。虽然不是不可能支持,但是需要花费大量的时间和精力将这些应用程序“移植”到FreeBSD上,通常会引入错误和其他可用性问题。
 
PC-BSD,Lumina和TrueOS的演进
 
考虑到这些原则 - 让我们来看看PC-BSD,Lumina和TrueOS。
 
PC-BSD
 
PC-BSD主要是基于FreeBSD上的KDE设计的。KDE / Plasma5已经可用于Linux操作系统已有一年多的时间,但FreeBSD 仍然不可用。它仍然被卷入实验“区域51”存储库,人们试图让它首先工作。
 
FreeBSD上的KDE4怎么样?
这将遇到上述静态项目的问题。它基本上是一个死亡的项目,因为它被版本5替代。这意味着它将继续积累安全漏洞,如hald,操作系统不兼容,并且依赖于其他死亡或垂死的项目来执行关键功能(policykit / consolekit - 都被替换在Linux上由systemd)。对于PC-BSD 10.x,我们尝试通过使我们的操作系统配置实用程序桌面环境(DE)不可知来减轻KDE中的大量更改,但这只能使我们从基础衰减中缓解。它还引入了一个“分裂脑”框架,其功能和支持的工具可与DE的功能失调工具同时使用。
 
Lumina
 
长期以来,作为PC-BSD的开发人员,以及来自项目初期的测试人员,我深切地意识到“变革的风”正在开源生态系统中受到吹捧。这在桌面环境子系统中尤其如此,早在systemd被宣布之前。因此,我开始使用基于FreeBSD的桌面环境,该环境不依赖于所有这些基于Linux的子系统和框架。这样我们就可以确保基于FreeBSD的桌面操作系统可以超过其他基于Linux的桌面实现,这些实现通常会将其基本框架剥离并替换。
 
TrueOS
 
所有这些生态系统的变化终于在2016年初开始向我们展现.KDE4在我们的下面开始恶化,FreeBSD“发布”分支将永远不会让我们与图形驱动程序或标准变化的速度相竞争的Linux阵营。
作为回应,我们开始基于FreeBSD“Current”分支(也为FreeBSD 11.0做准备)滚动PC-BSD的每月“快照”。令人惊讶的是,这个“滚动”的月度快照发布模式解决了PC-BSD的很多长期问题。有更新的司机。修补程序及时提供。最重要的是,该项目现在拥有单一的“支持版本”,可以更好地利用我们有限的开发人员时间。
同时,我们开始切换到Lumina,而不是默认使用KDE。在此切换期间,我们发现了很多我们正在开始的“点击”开始。界面稳定。只有一组操作系统配置实用程序。来自Linux的“上游”错误数量大大降低。Lumina是否“完成”为KDE?当然不!然而,关键问题现在解决简单永久。
 
重命名和后续步骤
 
随着所有这些变化和缺乏从PC-BSD到新系统的明确“升级”路径,我们决定需要更改项目本身(名称和全部)。对我们来说,这是确保人们意识到差异的唯一途径,而TrueOS真正是PC-BSD的一种不同类型的项目。请注意,这不是狂热的FreeBSD狂热分子对PC-BSD项目的“敌意收购”。这更是将PC-BSD项目重新集中在可以在可预见的未来确保寿命和可靠性的一些项目。
TrueOS有错误和问题吗?当然!这是随着上游变化的“滚动”的性质。你不仅总是得到最新版本的东西(一件好事),还可以发现自己在“前线”上查找和报告这些相同的应用程序中的错误(如果你喜欢一致性或稳定性,这是一件坏事)。您还看到的是,在任何给定的时间,开源生态系统都会发生多少“流失”。虽然,我个人认为现在的“流失”有点更积极。由于转换为滚动模式仍然相当新鲜,开发人员和贡献者仍在调整其中的一些新情况,并致力于实施应急框架和/或自动化QA测试,以帮助缓解部分流失。但是,这一切都需要时间。
我们致力于为我们的用户提供一个稳定,可靠和安全的体验(我们每天也不要忘记我们每天都使用TrueOS)。请耐心等待我们继续以尽可能最好的方式努力实现这一目标,而不仅仅是在为当前的工作做好准备,而且是项目的未来。
 
Lumina Desktop Utilities:为什么这么多?
 
开发这些小型实用程序有几个原因:
 
TrueOS中缺少功能
 
有时我们找不到一个开源应用程序来添加到符合我们标准的TrueOS基本安装。但是,填写功能至关重要。Insight文件管理器(lumina-fm)和lumina-archiver是在TrueOS中“填补空洞”开发的工具的两个很好的例子。
 
未来的TrueOS
 
有时候,我们长期使用的实用程序开始失去功能。这通常发生在上游项目开始期望更多的依赖关系在FreeBSD上不可用或添加许多不需要的时候。当这种情况发生时,我们自己寻找替换或写入(见第一点)。
请注意,此过程有时会在当前应用程序完全崩溃之前开始一段时间。我们试图主动预测TrueOS所依赖的任何公用事业的发展趋势,所以如果时候到来,我们的项目没有明显的漏洞。
lumina-pdf是一个落入这个营地的实用工具。okular可能目前正在工作,但我们期望即将改变。虽然目前qpdfviewer是一个有效的替代品,但移动到Wayland将导致该实用程序变得不起作用。因为韦兰一体化是“走下坡路”,lumina-pdf就在后面。
 
开发者“乐趣时光”
 
作为开发人员,采取这些小小的额外时间来做不同的事情是非常有用的。这提供了一个重新考虑应用程序,实验新的图书馆或功能,并作为开发人员发展的“游乐场”。如果其中一个项目变得有用,那么使用更多的“官方”时间进行抛光并将其释放。但是,并不是所有的东西都切断了。
lumina-mediaplayer是一个很好的例子。它开始是一个爱好项目,以替代pithos我的潘多拉广播应用程序。Pithos是脆弱的LibreSSL版本和GNOME3集成,这使我失望。通过修补,lumina-mediaplayer已经逐渐变得对我们更多的人有用。本地文件播放功能主要是为不想要潘多拉的用户提供基准功能。如果有人不需要VLC或其他“全功能”媒体播放器所提供的深度,那么它也将填补一个利基作为“回退”效用。
 
TrueOS对外部应用的立场:
 
 
在TrueOS的地方,确保基于Linux的应用程序的可用性或功能不是我们的责任。这更是FreeBSD社区和端口提交者的责任。我们关注的是我们在系统上预安装的“基础”应用程序的可靠性,稳定性和依赖性。这确保最一般的用例是可靠的。
这里有几个类型的应用功能,我们一般检查:
 
- 一般应用 -
 
文件管理器 - 您可以图形浏览/打开文件吗?
终端 - 你可以得到虚拟CLI吗?
网络浏览器 - 你可以上网吗?
电子邮件客户端 - 作为老式开发人员,我们喜欢工作的客户端。
 
- 文件支持应用程序 -
 
PDF查看器 - 您可以下载,查看和打印官方文档和/或发表演示文稿吗?
文本编辑器 - 两个CLI和图形。
多媒体播放器
 
请注意,这些应用程序不需要大量或覆盖每种可能的文件类型或用例。相反,他们需要覆盖基础知识(如办公室工作站或网络用户),并始终运行。
同时,“桌面”功能需要考虑:
是否可以使用任意用户帐户(AD / LDAP / Local)进行登录?
用户可以轻松地启动或管理应用程序吗?
系统通知和状态是否容易看到?(电池状态,网络连接等)
TrueOS + Lumina是否在没有GPU加速的低端系统或系统上运行?
这些要点是我们认为TrueOS的“核心”功能 - 所有其他用例(音频/视频制作,平面设计,无线电广播,[您的使用 - 此处])都不被视为TrueOS团队本身的责任,但是更大的FreeBSD社区确保“应用程序X”可用和功能。


1条评论

劳尔·罗德里格斯
   2017年4月20日上午1:55,   劳尔·罗德里格斯(Raul Rodriguez)
对不起,你可能觉得你必须写这个。但我很高兴你做到了 我早就知道linux应用会成为BSD的一个问题。有时我觉得我应该切换到linux因为这样。我会讨厌这个。这个博客将让我坚持下去。我总觉得更多的应用程序应该被写成本机BSD。我知道这不容易。我希望我可以贡献,但不要BSD和linux。在窗户上,我知道足够生存的这个操作系统。我认为你做得很好。谢谢你所做的一切

回复