Several weeks back, you may still remember my proposal of getting a new distro/fork out by Christmas, and I’m still avidly committed to that pursuit. One thing that got my attention back when I used Alpha 2, and that I really appreciate(d) about the Haiku OS was the ability to have control over the system, but to still have controls both in the shell and the filesystem to set limits if necessary. And one thing unique to Haiku that I hadn’t seen on anything outside of both the classic Mac OS and OS X is the ability to protect system folders in a way that does not “take over” the system like Windows 6.0 and later. Tracker, for example, asks the user to hold Shift when pressing Delete to avoid removal of a core folder.
I mention all the above because I have noticed that in the latest revisions/nightlies, this concept appears to apply too broadly in favor of the new Depot setup. If I try to add files to certain areas, such as fonts, or if I try to modify it, the system tells me I have no permission to do so. Of course, on any other POSIX-compliant system like OS X or Gnu/Linux, I could set flags or do chmod to repair this sort of thing and regain control, but I don’t know if that will work on core folders without the “root” user, as Haiku from what I’ve observed, seems to assume a unique single-user administrative power and views the filesystem differently in BeFS than in my experience with ext2/3/4 or hfs+. I haven’t tried this approach yet because of these variances, but I’ll definitely see if it works.
The reason why this is important is because I would like to be able to call functions in the system freely and place temp files and content in folders outside the “home” folder.
With all this said:
In the unlikely scenario permissions changes aren't possible, is there a way to turn off this new FS behavior in config or in make files before producing a compiled build?
If this is not possible, how can I download a full copy (not individual packages) of source code from an earlier Nightly revision or from Alpha 4, that does not have this on by default?
I’d really appreciate any assistance, advice, or input from anyone; thank you for reading, and I hope this may help others as well.
You aren’t supposed to modify /system/ in other way than adding packages, and it doesn’t have to do with users (users aren’t even implemented, btw). It’s a design decision, and of course, why would users want to modify raw system files?.
Every program must place it’s “user files” into /home/, /home/config/ preferently for configs. If this is not possible, use another folder other than /system/.
But also, Haiku allows you to add unpackaged programs, like raw fonts. You just have to place them in /home/config/unpackaged/. In your case /unpackaged/addons/fonts or something like that (check the path structure in /system/).
I understand that multiple users are not implemented yet, but does the baron/admin implementation == root? This, and talking about general users as single users is the sense of “users” I was referring to; forgive me for being vague.
My question isn’t about where applications, or where the user, stores data, but in regards to how to disable this new “feature”. The reason is because the distro/fork that I am planning to finish, with several things I’m working on, will have to access the system folder, such as temp files I would like to hide without using a . prefix. It is also true that fonts and other files now are being denied as well from system folders, which I’m finding to be an annoyance. That said, again, I appreciate your help, but stating where and how the system vs. the user places its files is stating the obvious.
My questions were/are:
Can I turn these new permissions off, either during or after, compilation, using configs, makefiles, etc.?
Or, can I get an earlier Nightly/revision source copy than the current git that excludes said changes?
Again, I honestly do appreciate your answer & time, but its not quite what I was searching for…
[quote=agreimann]Can I turn these new permissions off, either during or after, compilation, using configs, makefiles,
[/quote]
The behaviour you don’t like is part of Haiku’s package management system. You can’t change these folders because they don’t really exist any more, they are a mirage conjured by package management.
If you’re not comfortable using git itself to find the version you want then you can download Haiku source code ZIP files for any branch (e.g. alpha3) by picking that branch and then pressing the download as ZIP button from github.
But realistically if you’re not comfortable with tools like git you aren’t going to build a successful fork of Haiku and should maybe think of a less ambitious goal.
This is exactly the type of answer I sought. It’s a pity the system is set up this way now, but if it advances the package management/Depot, then I cannot argue. I’d only add one comment in response to what you wrote earlier, however:
I’ve used F/OSS software for years, have authored and author open source project(s), and understand how to use subversion/svn and git. I’m fully ready to take on a distro/fork, but was hoping there was a FTP archive or similar; git/cgit/etc. will serve my needs just fine.
I appreciate you explaining the situation; thank you.