Just read a thread on the new and buzzy V\OS chat about how, in their opinion, some of our servers/kits are no longer needed. Any thoughts?
Screenshots from private Telegram chat removed after request from people taking part in that discussion
1 Like
Here’s more of the discussion
Jimmy Shaka:
I’m curious, why would the mail kit be outdated? Something has to check for mail if you want mail.
Numerio:
the whole architecture mail server, kit, ABI in the middle, the mail client, the attrs and everything around it makes it heavily over engineered for what it has to do
easily replaced by a tiny minimal client that can optionally save mail as attrs and that’s it
Indeed separate “power_server” that is used only for handling power button sounds strange and redundant.
Mail Kit is a thing from BeOS and with public API, so it can’t be removed because Haiku R1 goal is BeOS R5 compatibility.
6 Likes
Maybe its time to start implementing the Glass Elevator/R2 goals as another “version” of Haiku. We have x86, x86_64 etc.. Why not Haiku_GE?
It would be exciting for the community
2 Likes
I don’t see a purpose in removing working code shrug
2 Likes
I don’t see a purpose in keeping useless code. Unless it’s planned to do something in the future with it.
2 Likes
Yet another useless thread.
2 Likes
Wow. Just a question.
But responses do reveal character. So perhaps not completely useless.
You asked for our opinion. You got it.
2 Likes
Ok maybe you want to know why this thread is useless.
- do you think Haiku users should not be able to send and receive email?
- do you think they should not be aole to turn off their machine cleanly by pressing the power button?
- otherwise, what do you suggest we should replace these components with? Why would that solution be better than the current one?
You don’t have any info on that. Just that someone who is working on an incompatible but related project, with different goals and architecture, has reached a different conclusion. I guess the power button is already handled by Linux in their case, but we’re not going to do that. And the whole mails as file thing is unusable for them as they don’t have attribute indexing and queries yet. So they’ll either design something else, or use Thunderbird maybe? But we’re not going to do that.
2 Likes
I suppose input_server filter add-on is a better place to handle power button. It also allows to handle power button on regular keyboard.
ACPI button is too x86 IBM PC centric and do not often work on non x86-hardware.
1 Like
I’m sorry can you rephrase that?
Maybe I’m misunderstanding you calling me stupid.
This is getting way out of hand
Sure, but there are other things power daemon can be expanded to deal with. Batteries on mobile devices for example. A more advanced power saving mode would be another. So the fact that it doesn’t do much right now isn’t necessarily an argument in favor of deleting it.
4 Likes
The “this” here refers to “the idea that we also need to remove these servers because V/OS wants to”.
Pulkomandy was not calling you stupid, if they were they’d have used “you” as a pronoun 
In any case, you copied a discussion basically without context and just asked us to comment, and of course the main takeway is “okay, so V/OS is doing stuff?”. Most things V/OS does don’t apply to Haiku, and likely are not upstreamable. IIRC the main Author of V/OS had a falling out with the Haiku community, among other things by consistent agressive behaviour in relation to maintenance of servers/kits; and the repeated suggestions that we also need to deprecate most kits and just do new ones now. (I am sumarizing from Mailing threads here, I was not actually here as a project member then)
It is threfore a bit unsuprising that they’d try to “clean out” what they perceive as cruft in Haiku, for us we’d rather improve and build on what we havbe, prefering incremental improvements over the “throw it all out and rewrite it” aproach Linux has. Sure they can throw out the mail kit if they want, but then they will have a problem… how do they get mail now? Make some other Client compatible? fix up beam? have some app ship a out-of-tree version of the mail server? Port thunderbird?
In any case, Haiku is open source, and our code is re-useable. Currently the trees are similar in aspects, but given time they will diverge more and mode. I somehow doubt that improvements I do now to colors will make their way over neccesarily, and I also doubt improvements made there will move over (otherwise, I guess some would have been already proposed?)
2 Likes
In fact, if I was a dev, I probably would have more kits.
For example, I don’t know if Haiku has an encryption kit yet but, it seems that encryption is everywhere nowadays. Also, it would ensure that algorithms are implemented correctly.
Then if someone want to generate a fancy interface with help of whatever tech, it is less problematic and anyway you don’t have to use it if you don’t want to.
IMHO, a good side of having kits is that you can keep critical things part of the OS and let users play with trivial things.
I would go even further with some kind of Haiku coding school as apparently, people are needing help to begin. It would be a good opportunity to show them good practices and how to use kits.
1 Like
V\OS doesn’t have a goal to be BeOS compatible.
But Haiku does.
And Mail Kit is part of BeOS compatibility. One can debate if it make sense to have in an OS a public API to create a BMailMessage object, have a service running in background managing incoming and outcoming emails files or have a public list of attributes for emails files, aka debate the design and the actual needs for such public API.
But the fact it’s part of BeOS compatibility that Haiku has to support is not, it has to be there.
And it’s not wasting cpu and memory for nothing, a all-in-one email app like thunderbird etc will also need cpu and memory (probably even more, due to the graphical part, which mail_daemon doesn’t need) to do the exact same thing: periodically check for incoming messages and sending outcoming ones.
I also consider that having to manually launch an email app before being able to see if new emails are available, enforcing the user to have to choose which all-in-one email app he want to use as not that user friendly. Even on Android or iOS emails apps are using some background “service” task to do that even when the full app is not actually running.
It’s ironic that the historic way to manage mails in Unix, one file per message and a “maildir” layout, letting user free to use any app to write/read those messages, can be considerate now deprecated in favor to monolithic, quite jailing all-in-one email apps.
Regarding power_daemon, it’s more debatable indeed, maybe it could be better to be managed by input_server for the power button.
4 Likes
I edited the post. Sorry, even more exhausting day than usual, and clearly I should take a break from Haiku for a while.
3 Likes
HaiSchool!
Yes, I thought of that too. And if devs can be paid for their time or sponsored it could be a win-win for everyone. Even if it was posted on YouTube with any revenue from the views going to the project could help
I’m a member of the Vitruvian development team.
We certainly did not intend for this to happen, the excerpt was taken out of context and relates to internal community discussion.
It was inappropriate for you, shaka444, to share it. Please avoid fueling conflict within the community.
We also suggest that nephele consider their standing within the community, which, to our ears, doesn’t sound very good, and a honest advice and warning to refrain from personal attacks in the future; everyone should respect the right to be forgotten.
We appreciate your work as a team, but it does not meet our needs. We are not interested in community drama and wish to be left to develop our vision in peace.
We will not engage further, so please do not reply.
1 Like
2 posts were split to a new topic: Mail kit discussion