6

What are the detailed specific technical/organizational reasons that the PC-BSD team faced that ultimately lead them to scrap PBI and return to ports?

Was because of the difficulties compiling and packing? Was because of problems with the hard links they created? Or because of the amount of work to collect dependencies and compile together?

I am curious just to know why the same team that create a software (say GNUCash), take the time and effort to provide a self-contained version for Windows while the *NIX is left as to the compiler/installer.

I am not asking about why ports and libraries are good (easy security upgrades,...). I also am not asking about preferences or opinions for packages vs Windows, just the technical reasons that led to scrap PBI. I am asking specifically why the route of PBI (0install, NixOS) is technically not feasible or broadly adopted.

  • 1
    I up modded your question and after noticed it is a duplicate/repost of a previous one that was closed by administrators. I wont take the vote, however I do advise you might want it to rephrase it better to contain facts and not opinions. – Rui F Ribeiro Nov 19 '15 at 7:57
  • Done. My first question contained this question and nobody answered. Hope this makes sense. It is a technical specific question, not want opinions. Let me know if you think it is better now. – null_pointer Nov 19 '15 at 8:20
  • While is has a disclaimer at the end, I am afraid the body still feels a bit opinionated IMO (yep I smiled with the irony of this sentence) – Rui F Ribeiro Nov 19 '15 at 8:22
  • seems far better now. – Rui F Ribeiro Nov 19 '15 at 8:30
  • Windows is an entirely different animal than FreeBSD/Unix. You can't easily port a well running program to Windows, with all its warts/dlls/etc., and expect it to run. That's why everything needs to be self-contained. Windows is not reliable or consistent over any period of time. It's why you never find Windows outside of Microsoft's own creations. – Rob Nov 19 '15 at 13:50
4

There are actually 3 good reasons why the PBI file format was discontinued on PC-BSD:

  1. The PBI format was created to provide a packaging format for FreeBSD (no "real" package system existed before pkg - only the ports collection).

    Once pkg was finally developed/implemented within FreeBSD itself (9.2/10.0?), there was almost no reason to maintain a competing format because more people would contribute to fixing the "official" FreeBSD pkgs than a secondary package format.

  2. The PBI file format was the #1 cause of user issues on PC-BSD.

    Most of the PC-BSD users were former Linux users show did not understand the concept of a self-contained/restricted application scope - so when App "A" could not find/launch App "B" (because "A" was running in a restricted container) they assumed a failure in the application/system. This was also at the time that all the various Linux-based applications were steadily moving toward integration with the system (moving away from the concept of a stand-alone application), so more and more applications simply would not function within a restricted environment. By the time we decided to switch from PBI to pkg, there were only about 200 apps on FreeBSD that we could successfully package/run within a restrictive PBI container, whereas by switching to the standardized pkg system we had instant access to all 23000+ packages on FreeBSD. This also reduced developer overhead because the FreeBSD community at large would be testing/fixing applications instead of having the (two) PC-BSD developers also try to maintain separate versions of everything.

  3. Technical Issues

    Aside from the general container system and the limitations/restrictions this imposed, there were a few other technical bugs which just helped push us into scrapping the entire file format:

    • Loading times

      Starting a PBI took ~30-45 seconds while pkg took ~2 seconds. This is mainly due to initializing the containers and loading the libraries within the container.

    • Application compilation

      The PBI's needed to be compiled with a different runtime prefix than normal (which apps are supposed to support), but more often than not the apps themselves had hard-coded paths/settings which prevented the app from actually building/functioning properly. This also meant that when we did run into issues building an app, we were never able to get any support from the app developers or the FreeBSD porters because we were using different build settings.

    • Developer Maintenance

      As I alluded to earlier, the PBI system was extremely maintenance-heavy. The build systems were always running into strange failures when building apps (due to the change in runtime prefix), then when an app did build, it had to be manually loaded/tested by a developer to ensure it actually started up (catching built-in path issues), and then the meta-information for the application also needed to be updated/maintained as well (we still keep this extra info right now - but treat it as an additional information overlay to the pkg system). So not only was that was a lot of work for two guys to maintain, but at the end of the day the apps themselves only barely functioned because they were not integrated into the base system environment as most of the Linux apps were designed to do.

Please note that while the PBI file format has been dropped from PC-BSD, we are still dedicated to application compartmentalization. We have instead been focusing on using pre-existing FreeBSD subsystems (such as the jails framework) to ensure reliable/secure runtime containers, while the "standard" applications the user installs will function normally/reliably the same way they do on other OS's.

| improve this answer | |
  • 1
    I made and published pkg (ng) packages using PC-BSD 9, although there were indeed some significant changes to it between 9 and 10 (about which I could go on at length (-: ). You might also want to point to Weekly Feature Digest 27 – Software System Redesign , by the way. – JdeBP Nov 19 '15 at 17:15
  • Thanks. This answer gives light, and also explains why other options like NixOS or 0install face difficulties, as somehow maintaining this should be like rowing against the river flow. Hope compartments in jails have better traction. Thanks again. – null_pointer Nov 19 '15 at 20:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.