no problem on my part
2 Likes
@nephele sorry, but it was your comment that demanded (at least that’s how i read it) the author to put source code for review. Why write that productivity is 0, even though it was not about your (or anyone else’s) productivity but x512’s. Why write that work is worthless unless you get access to the source code?
x512 clearly stated there’s no problem to publish source code, it’s just not ready for going through lengthy reviews and discussions - it’s still in “experimenting” phase.
Even if it wasn’t the case, even if source code was to stay closed, it’s up to the author (x512) to decide. Not you or anyone else. Don’t like it? Write your own.
8 Likes
That’s true, but from what I could gather from my quick skim-through was that they had managed to boot the OS, just that they experienced issues with the software.
By the way, have you filed tickets regarding your MacBook Pros? A bit of a shame Haiku doesn’t work on those.
I like how you went from “i read your comment as hostile thus it has to be hostile” to “throw away x512s work and replace it”.
I don’t know in what world that makes sense, in mine it certainly does not.
And I stand by what I said, I am allowed to have an opinion, that beeing that code that is never published does not help anyone.
(And clearly X512 is intending to publish the code at some point, so I do not see how you interpreted that X512s work has to be unproductive into there.)
I don’t see myself or anyone else here demanding X512 to do anything, it was merely a discussion. If you want to interpret that as hostile intent do go ahead, but that is then, so to say, not my problem, it is clearly not what I have written.
Does modern Amiga supports memory protection and preemption?
2 Likes
- memory protection: no
- preemption: yes
It also doesn’t use virtual addressing: any app may access part of the memory.
1 Like
Even the first Amigas supported preemptive multitasking - that was one of the amazing things about the OS at the time. No memory protection - messages passed by pointer to flat memory map… made it very quick, but obviously not too stable or secure.
2 Likes
I agreee here. App looks cool and helps beginners to get into Haiku.
1 Like
Yes, one of them used to boot though, something has changed between Beta 2 and 3. The other Intel based tried first a few weeks back, and the last one is a M1 Max (which I didn’t even bother to try).
I think @waddlesplash had an idea of how to gather info to solve the problem, but it was WIP so I have to wait. No worries, it runs descent on my old iMac.
1 Like
MacBookPro 11.3 (mid 2014) boots Haiku fine with both Macs native bootmanager (hold option) and via rEFInd.
The only trouble I ever had with EFI boot (years ago) was when I had incorrect GPT partition code.
This is getting off topic, there are other topics in the forum which address this very issue.
1 Like
to “throw away x512s work and replace it”.
Your words, i never wrote anything like that. First of all, no one can throw it away, because it’s not part of the Haiku codebase (yet). Second, i only suggested, that if you find unpublished code useless and/or can’t wait for it to published, you can write your own, or pay someone else to write it.
code that is never published does not help anyone.
Oh, but it does help its author. It can also help motivate others.
I understand being all for open source, but let’s not be fanatical about it (or anything else for that matter).
And clearly X512 is intending to publish the code at some point, so I do not see how you interpreted that X512s work has to be unproductive into there
What? It was you who wrote it’s productivity is 0 (Drivers, develop in or out of Haiku tree? - #5 by nephele) and i simply disagreed :).
4 Likes
If you had included the qoute here, as you had with my other quotes, you could clearly see that that simply is not what I have written.
How is ignoring the work and “just” writing my own any different to throwing away the work? I don’t like this attitude at all, you are basically asserting that I should instead of participating in technical discussions, just do whatever and then hope it goes well, in my view that simply isn’t what Haiku is about, I consider the “just write your own” approach incredibly toxic. Its the same as excluding someone from upstreaming work because they are “too slow” to do so, I am happy that Haiku does not do this, nobody ever closed my tickets because they were stale or closed my reviews because they were not updated fast enough. Similarly nobody is going to reject X512s work on the basis of it being too slow to be upstreamed. It would be nice to get it upstreamed before the beta surely, even if it does not work for end users it would allow other developers to improve and contribute then, I would much rather work with other developers on the graphic stack than working against them, especially if this would result in code that would be even more difficult to merge later. I had planned to try and write a gpu driver for a specific card series, but I will hold off on this until I can be sure that I can do it with effective collaboration and not step on other developers toes.
Apple boot manager find the EFI partition on my USB Drive (ALT/Meta key during boot sequense), but after selecting Haiku boot icon it goes black and hangs the computer. The CPU fans spins up to 100% and I have to reset the computer. This happens on both my 2013 (late) and 2017 (also late). The 2013 version booted once, but when it did It showed the Icons, and took like 5 minutes to get to the desktop. After that it was extremely fast.
I am a bit confused here.
Waddlesplash asked X512 if he would submit his work to our code review tool so we could consider integrating it into Haiku. X512 said it would be inconvenient to do it at this time, because it would slow him down. Which I completely agree with: our code review process has very high standards (or some would say excessively picky) on code formatting, and getting code ready for that is a lot of work.
Haiku is a long running project, and one key part of this long term success is the fact that we are doing code reviews, and making sure the code is architectured and formatted in a consistent way. As an Haiku maintainer, this allows me to easily dive into any part of the code that went through this process. I know how the code will be written without even having to look at it, basically.
If we just merged code from everyone without being so strict about these rules, the result would be that people would “own” a part of the codebase: only the person(s) who worote it would fully understand it, and no one else would touch it. This is not what we want to achieve with Haiku, our goal is to have a consistent OS, and this touches not only the user experience, but also the developer experience, and the internals. This is what makes it possible in Haiku to reuse your userland developer skills when suddenly you find out that you must modify some code on the kernel side, for example. Or when you find a bug in interface kit and want to fix it.
Anyway, X512 does not want to spend a lot of time formatting his current code to our (arbitrary) standards, because this code is still work in progress and will be rewritten several times. We don’t want to have the work-in-progress unfinished code in the main Haiku repository (or at least not in the main branch). It seems the proposed solution: have X512 do his 3D acceleration work outside of the Haiku git repository, makes everyone happy. Later on we can see about merging it (when it is stabilized), or if no one puts in the effort to reformat the code to Haiku standards, it can live in a separate repository, and we can still ship it in our release DVDs. We provide a stable API and ABI for the kernel and userspace, and so it is not at all a problem to do this. Unline on Linux, where constant ABI changes make it next to impossible to distribute a driver this way.
So, on the developers side, I think there is no problem, and X512 contributions will be used in a way that satisfies everyone: the original developer (who can design and architecture his code as he wants), the Haiku development team (who don’t get the burden of maintaining code they didn’t write), and the users (who get to enjoy 3D acceleration).
This means, if there is a toxicity problem, surely it is only in the forums? And that means we (the moderation team) should intervene more often when it happens, and not let the pile of trash burn as some people are suggesting here under the excuse of freedom of speech. If you want freedom of speech, you are welcome to set up your own platform (host a blog or whatever). But it doesn’t grant you any rights to use someone else’s communication medium to express yourself, and also it doesn’t force anyone else to read or listen to you.
On a side note: I would be happy to have more people from the user community in the moderation team. Currently it is in large part (but not completely) intersecting with the developer team. This could be improved to have a more impartial moderation team when the conflicts are involving the developers. Anyone wants to help with that?
29 Likes
You could even go so far as to say it’s beneficial to have this code in a separate repository, since it exercises the stable API and ABI and so helps enforce that.
2 Likes
How exactly is Haiku supposed to not have the API/ABI problem that all other OS have? Just asking out of curiosity since personally I think as long as you are in C/C++ land API/ABI breakage can not be prevented if you work with libraries. Most notably this is due to GCC and his quirks.
The in-tree or out-of-tree argument is settled. GitHub will be hosting the Repo for x512’s work. It can be merged in-tree later if the parties so desire. Is there any additional on-topic discussion? If not, I move that we adjourn this thread.
2 Likes
Hey, this article might help:
1 Like
So basically bloating everything with lots of padding.
Apple needs some magic to enable all hardware when it is not MacOS. Refind does this, we don’t as we havn’t been able to have hw to test a good solution. The times we tried it broke booting for everyone.