Time for another monthly report! It covers hrev51254-hrev51346
Waddlesplash merged some changes to netresolv (the DNS resolver), from NetBSD.
This is a companion discussion topic for the original entry at https://www.haiku-os.org/blog/pulkomandy/2017-08-04_haiku_monthly_activity_report_july_2017/
Really good news in this is, I read this here for the first time, that the Beta release will support 64 bit machines. This will be essential for acceptance of HAIKU because these days all desktops sold are 64 bit and people will only consider 64 bit OS’es for their machines even if 32 would do in theory.
Lots of good stuff happening lately, keep up the good work, the Beta release will be soon then!
Another excellent report on the high level of activities leading to R1 - Beta 1.
Yes, 64 bit is becoming more important than ever as the newer systems have 64 bit capable CPUs. However, not much is said about a 32 bit «=» 64 bit bridge to enable running older BeOS era applications existing only as binaries. .
That was one of our GSoC project but none of the students submitted a proposal for it. Maybe one of the devs will take care of it at some point?
Each release will only provide support for the previous release binaries. So R1 will support BeOS binaries, R2 will support R1 but not BeOS, etc. However I think this only applies to the same architectures of each release. So 64 bit R1 won’t support any 32 bit binaries, which includes BeOS. Someone correct me if I am wrong.
Of course any 3rd party package for a 32 bit emulator/wrapper on x64 would be awesome!
Well, we would include it in R1 (or R2, or…) if someone worked on it. However, with the great work of HaikuArchives on recovering sources for all the old apps, soon BeOS compatibility will become irrelevant and we can just recompile everything to run on 64bit systems. Which avoids writing a lot of code for what is essentially a one-time jump (there are no plans for 128 bit CPUs anytime soon).
In a way some offtop, but there is interesting reading abuot:
Yep,… 64-bit must go forward and BeOS apps into 32-bit layer (or some type of virtualization) in 64-bit Haiku.
…and about 128-bit CPUs, maybe we will need them for trasporting technology like in StarTrek movies… if that technology is possible.
Regarding virtio_net driver, let’s me give you some details about that “somewhat working” wording in the report:
- most importantly, it’s still unstable: it’s quite inevitable currently that at some point using this driver you get a KDL crash in Virtio queue management. I’m investigating why.
- I’ve made tests only under VirtualBox, which implement only “virtio legacy interface”, not the more recent Virtio 1.x specification. Thus, I don’t know yet how it work or not under other VM hypervisors like KVM/Qemue or Parallels or others VM stacks.
- My current performance test under VirtualBox shows that (beside it ends by a KDL…) while TX speed is correct, RX is suboptimal. I know why, will improve that point after fixing first that little annoying stability issue.
Obviously, I’ll be glad for any feedbacks from you curious guys who will try it meanwhile.