BeOS compatibility and packagefs

62

If only it stayed at that…

I got threats of legal action against me for hosting beosarchive, supposedly an illegal mirror of bebits or haikuware copyrighted material (it isn’t, it contains mirrors of readily available FTP sites that predates both websites, and a few files found elsewhere).

It led to nothing, of course, but still.

Dozens and dozens of emails on the mailing list contradict this. There was a lot of design discussions and everyone took part in it. The conclusion is, obviously, that you can’t please everyone.

I still have found no evidence of anything being broken by the package system. Let’s not get trapped into this argument. Some people were very annoyed over problems that did not exist, or were not caused by packagefs at all.

6 Likes
63

While everybody is free to have an opinion i personally would greatly appreciate if you would not use every chance on every forum and platform to criticize the Haiku pkgfs, the Haiku developers and the Haiku project. You are free to do it here, but your attempts to derail countless comment threads on various news-sites reporting about Haiku milestones is just as annoying as the comments from the linux zealots questioning why Haiku doesn’t use their favorite kernel on the same threads. Thank you.

12 Likes
64

I think it is important to separate packagefs and package management.

packagefs is amazing! It already works amazing but I can see a lot of future improvements. For example binary diff packages that can activate alternative functionality, like debug packages or user defined changes to the immutable system. If adding user defined changes to the immutable file system then packagefs would have the same freedom of changes as any other non-immutable filesystem. Files and folders could be added, changed, moved, renamed and deleted using user defined changes. That way all user defined changes to the immutable filesystem can easily be managed and disabled.

Package management has the same problems that package management has on any other system. There is a lot of improvement to be made in this area. Following the amazing work at Haiku Ports shows that there are a lot of standardized packaging rules that needs to be defined and enforced to avoid system breakage. Enforcement should also be via software so that breakage of rules should be rejected. In my opinion a ground rule that installed systems should never break must be defined and enforced so that all rules reflect that.

tldr: packagefs gets a lot of bad critic that is the fault of package management.

1 Like
65

So, @cb88, it seems that after some time (couple of years or so), you are back with the same complains and arguments about the package system as you had before. I remember the very same discussion happening in the recent past. Since I am relatively new, I am certain that this has happened many times during the years.
In my opinion, there is no added value for anyone discussing things that have been discussed multiple times in the past. I really wonder where @PulkoMandy and others find the patience and strength to reply to these things again and again and again…

3 Likes
66

If @cb88 or other opponents to the current implementation of the package system stops ventilating their opinions, how are we supposed to know what the users of Haiku really think about the system? Their opinion is always valid.

Silencing any opinion is wrong on so many levels. If you do not like what somebody says, just ignore him/her. It is as simple as that.

1 Like
67

There is a difference between constructive criticism and blind hatred. So far, cb88 has not addressed any of the points PulkoMandy made here. In addition, PulkoMandy has renewed an offer to fix whatever old BeOS apps that still don’t work with PackageFS, which has also received no reply. One party has extended an olive branch, while the other party either ignores or swats it away.

This shows that one side is at best ignorant, at worst outright disingenuous and engaging in bad-faith discourse. If it really is the latter, then they are not owed further engagement. They would then only be creating nothing but noise, which is disruptive to the community.

68

People are allowed to dislike something so much that it turns into hatred. Nothing wrong with that.

Silencing opinions for whatever reason leads to an echo chamber. Just ignore what you interpret as noise, because somebody else might not interpret it as such.

There is no valid reason to silence anything except if the well being or possessions of an individual is threatened. That is a crime.

69

Haiku has grown over the years through discussing things. There is no other way. Even if some topics come up again and again, there are often new people there who have different views and opinions. this can only make you emerge stronger. If topics are brought up again and again even though there have already been final decisions and determinations, state this and no longer respond to the comments that emphasize this again.

70

I’m fine with people having opinions. What’s annoying is people making claims that are not backed by any facts, for example, people who claim the package management system broke a large number of BeOS applications, but after 10 years of saying this, no one has actually provided even a single example of a BeOS application having that problem.

As long as the discussion is not about imaginary problems that don’t exist (and there sure are some real ones, such as the memory usage of packagefs, and maybe the extra user-interface complexity when you want to tweak things in the system or config directories), yes, it can be useful to discuss things.

7 Likes
71

So I think the non-packaged is a bad example, as you should have the package configuration copied in ~/config/settings.

72

At least for debuginfo, there’s no need for “binary diff packages” as debuginfo can be stored in separate files from the binaries. We already do this, the same as Linux does, at least for some packages (you can see all the “debuginfo” sub-packages in pkgman or HaikuDepot.)

73

Because they still exist… and SPECIFICALLY in the thread in question they were VERY relevant. Look at my original post in that thread… if things veered off into a tangent that may be but it was relevant to the topic of running Haiku on resource limited machines.

Packagefs directly stopped me from using most of the machines I was using for Haiku at the time because even though a few of them now have enough ram, packagefs at the time had severe overhead a lot of which waddlesplash and others have mitigated (but at great technical expense).

@PulkoMandy Packagefs broke nothing? The onus of proof of that is on YOU, why when there constant posts for years about old BeOS software suddenly not working with Haiku, and required updates and patches from many softwares that had source available. If all the software on BeBits could still be installed on Haiku just as it was on BeOS in a compatible manner … why did we piss him off apparently there was no reason for that at all right? Don’t brush real changes under the rug as if it didn’t happen. Haiku absolutely could have maintained a compatible file layout but didn’t and instead chose a wacky back asswards one. Specifically talking about the immutable FS (in a personal OS of all places where the user runs at root its insane to remove power from the user) and forcing users to adopt non-packaged folder paths that broke nearly every app out there.

Personally I dont’ care one iota about all that, but it is a matter of fact and public record… and it is also a fact that packagefs adds overhead for features that I personally deem hacky and very much a kudge in implementation. It’s a significantly complex mass of code, that adds to runtime overhead AND doesn’t even offer these features in a generic way to other services.

That’s all there is to it… stop accusing me of saying things baselessly it is extremely rude. Next time you think to post such a think think twice and save us all the grief. You also bring up issues that were completely unrelated to what I mentioned. I’ll also add that all of the responses I’ve given on this are DIRECTLY in response to comments. It all amounts of complete failure to be objective about packagefs and to treat it as some sort of underdog, as well as severe sunk cost fallacy.

Frankly I don’t ever care to discuss this issue with you again Pulkomandy because you seem to be incapable of separating it from a personal issue. I’ll remind you YET AGAIN… we were discussing Haiku on machines that typically have much less than 128MB ram… and the events that led to that not being practical on current Haiku.

Frankly I’d like to be able to install Haiku on the same machines BeOS could at 16MB minimum maybe 32-64mb practically… but that would require disabling a ton of features even before getting to packagefs… fancy font rendering and probably many other things. I think the minimum Haiku had a few years back a was around 48MB but I am very fuzzy on that… not hard to figure out downloading some old images and booting in QEMU though.

Why is all this in one big comment that I keep adding to? Because I have every intention of not responding to further comments in this thread and am hoping to cover all the bases… because it just turns into a flame war back and forth with each other person undermining the other to no benefit to anyone at all. If you are going to make petty remarks instead of just commenting about what you like or dislike back it up and put it in reverse terry!

Since you love to ask me for things I have no intention of providing, I’ll ask you for something in like kind… post a link to the poll asking end users about the implementation of packagefs. Similar to how many other polls were ran in the past. If I recall … most of the users as well as myself were very positive on package management (and I remain so), however most users wanted something SIMPLE, instead you went with something super complex under the hood and “GNOMEIFIED” the package management at the expense of power users. If packagefs had been explained it would have been shot down right from the start as a non starter instead it was implemented in full and served up and every argument against it was then returned with a sunk cost fallacy.

74

Here is what I did already:

  • Host beosarchive, so that this software is preserved somewhere and available for testing
  • Fix several bugs and loudly complain about others (none related to packagefs) that broke BeOS apps
  • Investigated many problems that were not at all related to BeOS compatibility, since they affected programs that never ran on BeOS in the first place, but were built for older versions of Haiku (and, yes, we did break compatibility with ourselves several time)
  • Repeatedly offer people to give me a list of broken software, with no one able to find ONE related to packagefs
  • Continuing to answer this to people like you who appear to live in an echo chamber of people saying “everything was broken” and not providing a single actual example of things that were actually broken.

I think I have done my part.

Yes, it seems so. Karl complained a lot but was also unable to provide ONE example of software broken by packagefs. He would only offer HaikuTwitter, which was broken by… Twitter shutting down their API back then. I find it hard to blame packagefs for that.

All you have to do in find ONE application that is broken by packagefs. I have done the most I can to make this easy, since I personally host the archive of BeOS apps now.

But, since you can’t or don’t want to do that, maybe you should stop saying “it broke everything”. And then we can have a more useful talk about the other, as I have also already said, very real problems, and how to solve them:

  • packagefs did make Haiku need more memory. So did other things such as the Locale kit. Is it acceptable? To me, it is, to you, it is not.
  • The code is quite a bit complex. This is a result of a large set of requirements trying to please everyone (which apparently was not succesful) as well as the code being written in a bit of an “exploratory” way. We did something that no one had done before, and so it required some experimentations, trying different approaches, etc. This resulted in the code having a lot of abstractions for pretty much everything. Now that we have chosen one path amongst all the possible ones, we could go back and remove some of the useless abstractions. But, the truth is, the package system works quite well. It did have some bugs that eventually got fixed (for example managing multiple packages providing attributes for the same directory).

On such machines you will have a better experience continuing to use BeOS. Sure, there is a rift somewhere in the Haiku community, between people who want an OS for everyday use, and people who want an exact BeOS clone. I am firmly in the first camp. And also, being a latecomer to BeOS, I never ran it on machines with so few RAM anyways. My first BeOS machine had 512MB (and still runs BeOS and Haiku happily in dual boot 20 years later).

I have already repeated, in this topic as in pretty much all the previous discussions about this, that the change moving /boot/beos to /boot/system, and then moving things that were inside /boot/system/system to /boot/system because having two nested “system” directories, predates the package kit. By SEVERAL YEARS. So, once again, it is a problem that has absolutely nothing to do with the package kit.

The consequence of this is the occasional broken “drag XXX here” link in installation files for some applications. Which I have already explained how to solve, you can symlink /boot/beos to /boot/system/non-packaged. Are we spending thousands of angry words over a simple symlink? We did provide a “BeOS compatibility” support at some point, providing that link, and I guess we could ressurect it.

8 Likes
75

Why would a packagefs actually break an application? I know that the program like Raycone InsideDesigner and InsideConstructor will stop working at some point (which is a shame), but this has nothing to do with package management, but rather due to changes to the rewritten code from haiku (necessary in order not to use old source codes).

So if there are no concrete examples that show that packagefs has broken an app, then you should look into what the problem is? This information has probably already been received in bug reports and no solution could be found (as with the Raycone products).

If there is more focus on old bug tracker entries again, you should ask there to see if anyone knows a solution or has a corresponding idea.

Thanks to the non-packaged folders, we are also able to install old BeOS programs (installer files). I think that’s overall very good.

For porting old programs (which actually means repackaged old programs), you can use my tutorial (see above). Many packages have not been tested properly or have been created half-heartedly, so in the end there are no links to writable files that logically should not be in the package.

I think, even if I initially had a different opinion, that with package management and packagefs we have a good basis for installing and managing programs.

If an old BeOS program doesn’t work, it should be in the bug tracker and not asked here in the forum, or at least with a link to the bug report.

We should accept that Haiku is not BeOS and that we have to move with the times if we want Haiku to exist long-term and not end up just being a showcase system at old scool parties.

The only thing that bothers me, and using the InsideConstructor example again, is that tickets are closed without the apparently fixed problems actually being fixed, as people often don’t wait for a response.

1 Like
76

I agree that Haiku is getting a bit resource heavy. The system needs to be polished not only by identifying and fixing bugs, but also identifying and fixing code that wastes hardware resources and memory.

Haiku will never achieve the same low hardware requirements as BeOS did without sacrificing to much functionality. But I would hope that Haiku will have the possibility to be streamlined for low resource hardware, for example by disabling packagefs in one way or another or any other resource heavy feature.

I think it is a good idea to name hardware that Haiku should be benchmarked against and require that it meets certain criteria (memory usage, boot time etc). Haiku should scream on 20+ year old hardware with standard configuration (RAM, mechanical HDD etc).

I think this will resolve itself as Haiku gain popularity. That is the power of the open source community.

77

As I mentionned earlier, it runs without any problems on the machine I assembled in 2003 (yes, that’s 20 years old now). I was in high school back then and I did not have a lot of money to spend on that machine. The configuration is:

  • AMD Athlon XP 2200+
  • DFI AD77 motherboard
  • Radeon 7000 videocard
  • 512MB of RAM

So, yes, 20 years old seems a reasonable target (there are in fact people using machines this old).

But for anything older? Well, I’d say just continue using BeOS? Haiku is not a retro-computer system. It’s been more than a decade since we changed the tagline on the website to say “inspired by the BeOS” instead of “clone of the BeOS”.

7 Likes
78

I’ve recently tried using libreoffice to “just” edit some documents and add embeded png, and my 4GB of ram were pegged. Maybe that was just a bug, but haiku running on something and beeing useable is definetely different :g

79

But then again, running LibreOffice on BeOS will never be possible at all due to the lack of a proper package manager.

I don’t think you can blame Haiku for an application written by someone else, ported by someone else, and using Qt, a toolkit written by someone else. We can do a lot of things, but magically fixing other people’s code is not one of them :smiley:

(yes, I know, the Windows developers do exactly that, but we don’t have Microsoft’s resources here)

1 Like
80

Indeed I cannot, but calligra also failed in the task, and there is no native application available : )

81

Lack of package manager is not a problem at all for LibreOffice. Windows have no central package manager and LibreOffice run fine on it. It it always possible to put all dependencies to application directory.