I think this approach makes sense and would be a good start already.
Just make sure to keep the possibility to enable and disable tracing at build time separately for each driver (I think we don’t want everything to be built with all tracing enabled by default).
No need for advanced skills to do this part of the work. And once all the logs are using the same macro, it will be easier to change the macro to send the logs to a different place if we want to and/or add extra data to it (such as criticity levels).
AsRock was the king of combining modern with retro. The last mobos with classic FDD connector were issued in 2011. Along with real FDD controller they offers IDE, PS/2, COM, IR, CD In, 8-core AMD CPU support or 4-core Intel i7, up to 64GB DDR3 memory, USB 3.1 etc.
But aren’t defined at every driver? My point is, at least, factorize on some header and drivers only have to define some macro with the name ie: define DEBUG_NAME “foo”.
Would be great to add a parseable timestamp at syslog start and and a delta time for each entry ie:
syslog start: 2026/01/01/22:00:00
[…]
[4.001] [foo] driver init()
This may help understanding syslogs and would allow a gui/cli to make some filtering
But then this doesn’t end up in the log in a standardized and easy to parse way, and it’s also not configurable at runtime to enable debug logs without recompiling.
So, as I wrote: first centralize the definition of the macro, then we can see how to make it better and more useful. The usage of the macros may not need to change to get the extra functionality.
I said it already a couple of times, but my DriveEncryption package (which unfortunately does not build anymore ATM) can not only encrypt disks (but not the boot disk), but also includes a login application that I specifically wrote the launch_server to be usable with package management.
It shouldn’t be too hard to get it to work again, although the launch_daemon support is actually still missing from it.
I’m not too sure about that honestly.
I think posix users are not a good “fit” for what people normally consider users nowadays, and overloading them to in one instant mean “an instance of a system service” and in another “a physical user”, while re-assiging ids when neccesary means if you ever unplug some disk you are left with broken or wierd files that seems to give you some permission.
On Linux I often have this with files saves as the user1 (with uid 1000) not beeing able to opened, from an external drive, from some other linux because the user there happens to be uid 1001, but the files never had the same context, the uid 1000 == 1000 match that allows me to open files on an external drive, despite not beeing “root” happens completely by accident
In addition to that if you want to use these posix users to lock down your apps, do you now make a libreoffiice account? one per-user? do you use groups for this so that some file is in the libreoffice group? does calligra also have access to these?
Also posix users work for file permissions only, atleast in the unix/posix model. There is no seperation for network, ipc, settings, in our system installing or de-installing packages etc. And almost all implementations of these systems I’ve seen do not use any posix users.
For example FreeBSD, Jails → not related to users
Linux namespaces → multiplexes and hised ressources, ignores users
OpenBSD Pledge → forces applications to simply not have permission to use certain system ressources when their operation does not require them (cat can never use the network, for example)
Out of these using a dirivation of pledge seems the most logical place to start for me. We have lots of applications that require only settings from the disk, or some cache dir. Both could be an api provided by the roster that gives you a file handel for these purposes, but not any access to the file system. That way we already have a large swath of applications physically unable to delete your files; which is one “threat” I’d care about (and one you identified for the case of children using your pc)
What if your children get a Haiku on pendrive or external USB drive ?
It’s cheaper than a whole computer -
Then they can do it with their Haiku what they want - and if you have created one, then you double it - even onto a image file, that matches in size with the drive, and then you can simply recover it - reinstalling the Haiku from it to the pendrive or external USB drive …
All the data is most safe on network drives, that mounted only when needed, and specifically those needed for them, and can mount even in read-only mode, if you want to avoid damage -
I wish that it will be eventually possible to uninstall a program and its accompanying dependencies that no other program needs in a few clicks.
I sometimes like to try multiple programs at once with no intention of keeping all of them long, I also do this on other operating systems.
but removing them is tricky on haiku, especially when some programs’ dependencies are in the double digit, it makes me more hesitant. Later, I usually just reinstall the system and the programs I want to keep.
You could delete a program on ms dos from the 80s by deleting the directory, on mac by dragging it to the bin, and I am guessing that it was done similarly on BeOS.
being able to (fully) remove a program in a minute may not be a lifesaver but it is, in my opinion, one of the kind of features one would expect from a complete desktop operating system, and I think it would make sens to implement it in some form in haiku in the future before considering it no longer Beta.
it had been suggested to add metadata to packages or to create a list of user-chosen ones; I think that a third possibility would be to install dependencies in a ‘dependencies’ folder.
A button could be added in haikudepot to check one or multiple packages in /dependencies. For each one, we search through the regular packages and stop when one is found to need it. If none need it, it is deleted.
We could also remove redundancies in this operation by caching the names of multiple dependencies at once and ‘validate’ them without a loop.
by establishing a dependencies folder, existing apps that don’t use it would keep working, but next time an app is installed, it will use /dependencies; the transition won’t break existing systems, the only flaw is that one dependency will exist in both /dependencies and /packages for a time.
