Fuchsia is open source
Some of the big names working on the project include Travis Geiselbrecht (NewOS, Danger and BeOS) and Brian Swetland (BeOS).
Great newsïŒHope that this project will help the development of Haiku.
I noticed that yesterday Travis Geiselbrecht (geist) discussed his new project in Haiku IRC channel.
Link: https://echelog.com/logs/browse/haiku/1471125600
Logs as follows:
[11:12:26] <stargater> oh oh google working on a new OS https://www.engadget.com/2016/08/13/google-fuchsia-operating-system/ [11:13:05] <stargater> i read beos in the text -> https://news.ycombinator.com/item?id=12271658 [11:16:31] *** Ptrus <Ptrus!vision@68.118.40.186> has quit IRC (Remote host closed the connection) [11:17:06] *** Ptrus <Ptrus!vision@68.118.40.186> has joined #haiku [11:18:33] <moochris> Yes, looks interesting, especially considering the people involved [11:24:13] <geist> yeah it's a project i've been working on for the last year [11:26:17] <moochris> Ah, the famous man himself :) Is Magenta written from scratch or is NewOS reused there at all? [11:28:23] <geist> only secondarily. it's mostly based on LK, which is my second major Os that i've worked on since newos [11:28:41] <geist> and some pieces of LK have some newos heritage [11:29:01] <stargater> geist: nice [11:29:03] <geist> but it's a mostly different direction. we're building a microkernel for this one [11:29:21] <geist> and worrying almost exclusively on 64bit [11:29:30] <geist> which really frees you to do some interesting things [11:29:58] <stargater> i read the new os will using DART? [11:30:28] <geist> that is a language that is supported, yes [11:30:37] <geist> but it's one of many. the system is language agnostic [11:30:52] <stargater> ok, for UI? [11:31:12] <geist> you gotta dig into the source, but it's flutter based [11:31:21] <stargater> ok then i hope golang will play a big roll on the new os [11:31:33] <geist> golang does, yes. it's a first class citizen [11:31:44] <geist> aside from the run time requirements, it makes a half decent system language [11:32:09] <stargater> but all in all, its nice to see geist you kernel goes more and more puplic [11:32:21] <geist> it's all i know how to do [11:32:23] <moochris> Sounds very interesting - I like the filesystem layout, looks a lot more sane than Linux [11:32:39] <geist> i'm actually pushing internally to use BFS as the main fs [11:33:03] <geist> that'd be trippy. full circle [11:33:19] <moochris> Wow, awesome :) [11:33:46] <stargater> :-( when this os came out, can haiku dowside [11:34:03] <moochris> I don't think they would be competitors - different targets? [11:34:42] <geist> it's kinda like an ambitious hobby os project, except we have a lot of folks working full time [11:35:07] <geist> but less time. but we went from deciding to do it in january to actually having a working prototype now [11:35:14] <geist> put together a good team [11:35:22] <geist> it's amazing how fast progress is happening [11:35:27] <stargater> geist: befs or bfs? [11:35:37] <geist> is there a difference? [11:35:41] <geist> when i worked on it it was simply bfs [11:35:43] <stargater> sure [11:36:04] <stargater> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/fs/bfs/Kconfig?id=refs/tags/v4.7 [11:36:24] <stargater> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/fs/befs/Kconfig?id=refs/tags/v4.7 [11:37:31] <geist> that's linux [11:37:40] <geist> dont care what they name it. it'll always be bfs for me [11:37:47] <geist> that's what we called it at Be, and that's what it was [11:38:06] <geist> i dont even know what linux's bfs is [11:38:20] <stargater> yes surce, but i listen some humans have never see beos :-) [11:38:44] <geist> well, i'm in a haiku channel, so i generalyl assume my audience knows what beos is [11:38:56] <moochris> I would hope so :) [11:39:20] <stargater> its an old boot file system from SCO UnixeWare [11:42:31] <stargater> haiku have lost past the right way [11:43:52] <stargater> i have see some plan9 userland tools and apps are rewrite in goolang [11:44:10] <jessicah> geist: it would be fantastic if you guys use bfs [11:44:42] <geist> since file systems run in user space it's much easier to port foreign fs implementations too [11:44:55] <jessicah> would you guys reuse haiku's bfs driver, or would it be from scratch? [11:45:09] <geist> beats me. i'm suggesting that we reuse haiku's driver [11:45:17] <geist> but i have no idea if it'll line up with what we want to do [11:45:26] <jessicah> would be interesting if it means can improve the bfs driver [11:45:28] <geist> sadly though i'm a big fs person, i really have my hands fullwith the kernel [11:45:38] *** DKnoto <DKnoto!~DKnoto@apn-46-169-156-203.dynamic.gprs.plus.pl> has quit IRC (Read error: Connection reset by peer) [11:45:51] <jessicah> and maybe add some new features to bfs perhaps, like hard links, etc. [11:45:58] <geist> i have to sadly let that go to someone else, though mmap() support for a user space service is interesting [11:46:03] <jessicah> and/or improve small file speed improvements [11:46:23] <geist> perhaps. we're not too fixated on posix and traditionally unixy thing, but we'd also like to self host at some point [11:46:27] <geist> so we need enough [11:47:33] *** return0e <return0e!~return0e@178-78-68-13.static.kc.net.uk> has joined #haiku [11:47:44] <jessicah> be good to have extra engineers poking at the bfs driver :) [11:48:38] <geist> yeah totally. we'd absolutely be running stress tests out the wazoo [11:49:13] <geist> hopefully the flavor of c++ the haiku driver is written in isn't too foreign [11:49:51] <stargater> :-) [11:50:43] <stargater> but a rewrite of befs in golang are nice too [11:51:12] <stargater> with unions mounts like plan9 fs [11:51:18] <geist> maybe... i'm pretty leery of writing a fs implementation in go [11:51:30] *** duvjones <duvjones!~duvjones@23-91-227-5.cpe.distributel.net> has joined #haiku [11:51:35] <geist> many other servers maybe, but FSes tend to be highly tied to the VM and whatnot, even in user space [11:51:46] <geist> and you'd have to work around go's implementation a lot [11:52:03] <geist> double so if you ever intend to swap over one
3 Likes
Iâm going to keep my eye on it with cautious optimism⊠To rival Haiku as a desktop OS, for me, it would have to not be dumbed down and throwing out all the desktop paradigms that I like Haiku for. i.e. have a proper spatial desktop, with proper window management and things like Translators and BeFS queries.
Chris
1 Like
First of all, I wish you an excellent year to all and especially to the developer team.
I have a question about Fuchsia-os.
Someone has there news about the possible integration of code in Haiku (drivers âŠ) ?
Thanks
1 Like
From the discussions with geist on IRC, it is more likely to be the other way around: Fuchsia may be borrowing some code from Haiku were applicable. At this point, it is a bit early for Fuchsia to provide us with drivers, they are just started on writing the kernel itself. I see only two drivers in Fuchsia at the moment:
https://fuchsia.googlesource.com/drivers/wifi/
https://fuchsia.googlesource.com/drivers/gpu/msd-intel-gen/
Both make heavy use of C++11, so adopting them in Haiku would exclude using them in the gcc2hybrid build. The driver API looks somewhat similar, which could simplify porting efforts. But, someone has to do the work, still.
1 Like
It is a bit of an ironic twist of fate that ex-BeOS developers would be working on this Fuchsia project. Google`s ChromeOS is essentially a modern day implementation of the concept underlying BeIA - the (failed) last hope of Be for a profitable market niche.
One interesting aspect of BeIA is the use of a âcrushedâ BFS image to make it fit on a 8 MB compact flash memory. Incidentally, this makes it nearly impossible, as far as I understand it, to âinjectâ a malware payload.
Who knows really in which direction the Fuchsia project will eventually take - or even if it will become a product on the market. Nevertheless, this will be an interesting story to follow.
1 Like
It would be interesting to see if the Haiku servers could be ported to the Fuchsia kernel. I would think so. This would mean the BeOS API would be running on Fuchsia.
Time for Haiku Beta 1!!!
I believe that progressing towards Haiku R1 more worthwhile than pursuing a spiritual relationship with the Fuchsia kernel. After all, the NewOS kernel used is also in the spirit of BeOS (Travis Geiselbrecht).
On the other hand, monitoring how the Fuchsia driver API evolves, and how a cross-platform development tool or porting recipe could be put together, could benefit Haiku on the long term for its use on todayâs hardware platforms.
2 Likes
And we must avoid any Google-spread hype.
Oh, if only Haiku would follow that idea. To retire now useless binary compatibility / gcc2 hell, effectively cutting the umbilical cord to a long dead corpse. Keeping all that weight of legacy stuff seems dangerously idiotic in 2017 and further.
âhellâ? Does it get in your way as a user? If so, simple solution: get the 64-bit build.
The already written gcc2 code does not get in the way of anything currently. It does not need much specific maintenance in the OS. It is quite stable and does not need much changes. With outsourced 3rd party sources and packages we can even run more modern versions of our dependencies (mainly ffmpeg and mesa at the moment) on the compilers that support it.
The gcc2 port is going away at some point, but, this depends pretty much on the success of HaikuArchives at retrieving the sourcecode for all the old apps and updating them to work with a modern compiler. It is a long term effort, but the team at HaikuArchives has made a great job already, with hundreds of apps archived and most already updated.
In the meantime, gcc2 does not get in the way of anything, and you can very easily install a system where it isnât available at all, if you donât need it in your use case. There are some users that still rely on it (with the two flagship apps being GoPbe productive and SynC Modular), however, and there is no reason to let these people down.
6 Likes
The fact that x86_gcc5, x86_gcc5hybrid and x86_64 nightlies are still in âunsupportedâ ghetto area tells a lot. I get it, gcc2 is your IdĂ©e fixe, so enjoy it. Just donât act surprised, when a number of 3rd-party devs, which were initially interested in Haiku, but got tired waiting for gcc5+/x86_64 to become âlegitâ, now avoid your project and laugh at every mention of anything Haiku-related (âwhat? theyâre still on gcc2? hahahaâ), largely because of core dev teamâs devotion to legacy code and abandonware without any src available and no way to obtain it (even SoundPlay, ffs). Very few people, who still cared about apps like GoBe, left years ago.
As a user, I see what was left of the community getting smaller and smaller, core team not giving a flying hell about the real world around us and, unsurprisingly, less money donated to your funds (which is a shame, we need more fixes in HaikuDepot and WebPositiveâŠ). Iâd say itâs time to make a change, but it looks like you are happy with current situation and things how they are.
I am very happy with gcc2hybrid as my main operating system, yes.
As I said, the x86_64 WILL be a first class citizen in the next release. We considered doing it already when we released alpha4, but at the time it was a fresh new port and we considered it too early to do so.
If all you want is moving x86_64 download link in the nightly pages, certainly this is something we can do. Will it suddenly bring us dozen of new and highly motivated developers and an amazing flow of donations to Haiku, inc? I doubt it. But if that makes you happy, letâs at least try.
Keeping all that weight of legacy stuff
Please expand on this, where in Haiku is the âweight of legacy stuffâ?
when a number of 3rd-party devs, which were initially interested in
Haiku, but got tired waiting for gcc5+/x86_64 to become âlegitâ
Can you cite examples? There have certainly been devs who lost interest in Haiku for a variety of reasons, but I canât recall cases where that specifically was the reason.
1 Like
Well, it is one of the reasons pdziepak is not so active around Haiku anymore, he really wanted to work with C++11/14 and this is why most of his work was restricted to x86_64 parts of the codebase.
However, it is an issue internal to Haiku only, and does not affect, in any way, people working on applications (even WebPositive is gcc5 only, and no one complains about that).
This can be useful in the haiku develop? maybe the 3d support is not so compatible from linux but fuchsia is not a uberBeos-like just as a deep doubt maybe can be helpful and as i say in the facebook group it is not the little rich brother for haiku?
https://cdn.arstechnica.net/wp-content/uploads/2017/05/7-1-980x577.jpg
1 Like
Fuchsia is related to BeOS because it is for a great part the same team of engineers working on it. However, they now have 15 years more of experience and have (of course) made something free of the legacy (read: mistakes) in the BeOS design. So, it is not directly useful to us.
However, we are watching their work and may start to borrow pieces of their code. We had a look at their USB3 stack when trying to figure out problems in ours. We may also study their graphics drivers and see how they achieve 3D acceleration (if/when they do) and if we can manage to share parts of the code with them.
There is at least one developer with commit access on both sides (but currently more interested in Fuchsia, of course). So we can get some inside views on things and pointers on the code we should investigate when needed.
9 Likes
I would assume that some of the work put into the NewOS kernel were improvements from mistakes learned after developing the BeOS kernel.
It have graphic driver, if you take a look on the article they say are using vulkan, and only support one laptop, then that was what i think.