I’ve seen that
recently you provided some additional Haiku kernel and buildtools improvements to the officially unsupported ppc and m68k architectures.
Regarding to those updates - may I have some questions ?..
(just from curiosity from my side … :j )
Are those related only to GCC13 upgrade (buildtools - assume : surely )
or
a) you have personal interest too into those platforms : one of them or both;
this way you would add what you added to arm and arm64 already ?
b) you got such hardware(s) and/or someone else would work on it with you to move forward Haiku itself on those environments too ?
c) or I went too far and you just playing with them in QUEMU to see what beyond you can reach with them to check out what you can achieve - using lessons you learnt on ARM development ?
If this is only for GCC13 switch : were you volunteered to help out @nielx, @kallisti5 , @waddlesplash (and those ones whom are also work on it but i dit not mentioned here) or you were asked for to care for the necessary things ?
If this is more than just dustin’ off old codes
and
you devs may setup buildmaster server(s?) as well to build experimental Haiku images for ppc and m68k architectures – as those available for arm and risc-v 64bit or even an oldersparc actually – would be they publish for download ?
(I ask as ‘ppc’ and ‘md8k’ are in so early stage - based on text warnings at download page , but against it on the port matri page - seems files which needed to experiment with them are not provided at download pages which opens after clicking on tabs ppc and m68k )
DISCLAIMER :
I do not write to you in private message and in Hungarian,
but on this forum and in English, …
as I think there are some members, visitors herewho own such bare metalsand would like to know morenews about upcoming possibilities - if ANY would be …
… but they arenot peeking new patches and not follow Haiku mail threads( those : me included ;-)) ) , BUT reads the posts they are interested in…<|8{D
For me, myself, it’s just simple curiosity - I am not affected actually such hardwares or emotions toward them as a former owner … :))
END of DISCLAIMER
Thanks in advance for your reply
and sharing with us what we can know about these updates and their goal and future.
Basically it’s option 1c from your post.
After adjusting arm/arm64 to to new gcc-13.2.0 toolchain, I just played around with the m68k and ppc ports as well, to see if they still compile and if we can get any meaningful output without major effort.
I don’t have any m68k hardware and even if I had some, not sure it would be a realistic target for Haiku in terms of memory and CPU cycles. So for m68k I just tried it in Hatari emulator. Still reaches the boot menu with a little kludge but not much more than that.
I actually have a bunch of m68k and powerpc hardware laying around here, I might even be able to jack up something m68k enough to run Haiku, I’d have to look through my inventory to see if anything has enough memory sockets…
I see … so now those are architectures refreshed to new toolchain but still not rolling over by one of you.
Anyway it is good to see you at least taking care of them - at least for not letting them behind …
And who knows … a few experienced c++ OS maintainer from NetBSD or Debian retires and then they pick up such projects to make it alive … for fun … or for new Open Source PPC machines.
About md8k resource requirements :
I know it is heretic idea … because of BeOS legacy and basical GUI focused user interface of Haiku …
… but what about Haiku without GUI and a character graphical interface ?..
Once in a forum thread it was confirmed : Haiku could boot into terminal, but never targeted, as of GUI offers the full Haiku experience and elementary user expectations to easy and intuitive(?) usage.
However , for a user - socialized on any other OS -, must learn usage anyway : it cannot be evaded.
I assume the question is then :
is it really Haiku (BeOS) without the well known Desktop, and GUI … as Haiku boots directly into desktop and its facilities.
Yes, you are right … but what about
coding ?
it needs a terminal only if you use vim for writing the code … also for building … it happens in command line.
Using Midnight Commander the file management can be done.
github services - if network access established - can be used from command line.
NFS can be used.
(S)FTP can be used.
wget as well…
And if finally some GUI needed - to check what can be tested only on a Haiku GUI - an another Haiku on another machine can be available to test it.
You can even listen music as well - there are commandline music players and some player does not require GUI - they are play back from commandline as well.
You can launch the program from commandline … of course you need app_server and other system services … but you do not need a permanent desktop environment as well ?
An m68k machine can be a very SMART terminal - with Haiku , and more …
If you want a TUI-based operating system, tbh it would be easier to use Linux instead than to try and get Haiku to be one. There is even a textmode environment for Linux (might work with BSDs too), mouse control and all:
Thanks - I just mentioned as a possibility as if in case m68k machines has low CPU/GPU power and memory resources
to get a full Haiku environment run on them without hiccups -
so I offered to boot without a GUI - that way Haiku might hick up ;-))
Just in case if you have time
to continue toying Haiku boot improvements
in Hatari emulator …
could you link here a short video about what happens in Hatari window when exp. Haiku boots ?
… or at least some taken shots about phases you catched during fixing upcoming issues ?,
You may remember how we , forum members (and later random visitors ) how much liked to peek above your shoulders
if / when you , X12 , 3deyes , waddlesplash , pulkomandy , nipos or someone else - e.g. GSOC students - shared some screen-feeds about your / their progress and stages …
Also
I can speak up in the name of many of us
we feel sorry in case arm stuff you had stopped to broadcast
what happens
possibly as nothing or almost nothing
as you may thinks about it
Of course - we must accept it
It was done voluntarily in your spare time - by all of you - so we just hope(d) in further co’ops … but we felt enthusiastically when so much projects bloomed around Haiku - in parallel.
We just rushed from one post to another it was so much exciting news to read them all … day-by-day :))
We may got on high from these big dose of dizzyer ‘Haiku-drugs’ and now hard the sobering of shiny future …
We were just like this → and this →
I hope I was not misunderstandable - it was not criticism at all … just expressing now you cook new stuffs on your own and lesser publish.
We must rely on monthly reports - and who has time and mode can check Gerrit, Trac for stuffs.
This way I did this post to send a ping about …
we would like to know … if there is something to share …
Even some small you think it is not worth to talk about.
Ok then do not talk about it :))
we like pics and silent videos as well 8D
I had an Amiga 4000 with 128MB of RAM at some point (on an accelerator board). Modern ones with Vampire boards probably have even more. But not all machines have an MMU, which is also required in our case.
So, yes, there are some hardware options. But it will need someone willing to spend time on it, and, honestly, will it be really that useful? One of the goals in BeOS was “let’s start from scratch. Let’s remove all the legacy quirks from old systems and design our own clean hardware and software”. Porting it to a Vampire board running in an old Amiga 1200 seems quite a strange idea, then. Especially if you also start saying “let’s remove the GUI because there is no space for it here”. Ok, sure, a fun technical experiment, but then, what use is there for it?
Personally I will spend my time on more modern hardware instead but to each their own thing of course.
re emulator:
Hatari seems to support up to 1024MB “TT RAM”
see: Hatari User's Manual
but ARAnyM might be a better option, even though it’s more complicated to set it up properly so that’s why I tried hatari
re screencast:
I’m not so familiar with screencast tools and not sure how many people would be interested. I can post some screenshots though.
re architectures:
of course it’s just a little experiment. I agree that we should focus on modern architectures (in my understanding that would be x86_64, riscv64, arm64 for tier 1, 32-bit arm for tier 2 - and I’m never sure if 32-bit x86 should be considered tier 1 or tier 2) and I don’t intend to burn too much time on this experiment with what we could call a tier #3 architecture.
I don’t think there is really a notion of “tiers” here. Developers work on whatever they find useful, fun, or interesting. If an architecture is none of these to any of the developers, it doesn’t get a port.
32bit x86 is useful for the handful of people still wanting to run BeOS apps (at least until the patches to support those in the 64bit version get merged), and interesting as an experiment on maintaining an ABI compatibility with a 20-25 years old closed source system for as long as possible.
arm64 is useful for the cheap hardware (like the raspberry Pi), and also maybe for current and future Apple machines.
RISC-V is new and shiny, making it fun and interesting. And it will probably find its own market somewhere in there?
Not to forgot that 32bit x86 is also important for those who still own 32bit-only hardware.
I used to have a laptop where that was true (first generation Intel Atom or something like that) and it gets increasingly difficult to find operating systems that still work there.
While I personally don’t have use for 32bit x86 anymore (current Haiku PC is 64bit),I really hope that it will stay supported for a long time to keep these older devices alive.
I used to run qemu with lower and lower mem to see how low it could go and where it would stop.
IIRC it is probably more like 200 MB on x86_64. I think it can be reduced quite a bit though. The first start with the installer seems to use the most memory.
Yes, packagefs is still in an early shape, would be nice if someone decided to focus on that area to make it more polished.
(Personally I’d swap so it was “packaged” instead of “non-packaged” it seems backwards to me. I wan’t the non-package’d to be easier to access, as that is where I can change, now I need to know a technical term and understand some packagefs internals which I don’t think a regular user should need.)
and this → 
but to each their own thing of course.