Workstation (
workstation) is an open source reference design for Fuchsia. Workstation is not a consumer-oriented product. Workstation is a tool for developers and enthusiasts to explore Fuchsia and experiment with evolving concepts and features.
Workstation is one of the many “product configurations” Fuchsia can be set up with, and it targets both the Fuchsia emulator as well as an Intel NUC – so real hardware. This configuration’s goal is to be “a basis for a general purpose development environment, good for working on UI, media and many other high-level features. This is also the best environment for enthusiasts to play with and explore.”
They’re emphasizing this is not some ploy to desktop dominance, but there’s no denying that with every step Fuchsia takes – from shipping it on Google Home devices to porting and running Chrome – they’re getting it ready for more than just some IoT project.
Haiku and fuscia is fairly convergent (even uses the newos kernel by geist as base). Does google intend to embrace or extinguish haiku?
Um. Neither? It’s not like either are based on a continually updating NewOS base system that Google can hijack. The last updates in the NewOS git repo were 14 years ago.
Fuchsia’s Zircon is not based on NewOS.
Correct.
As far as I understand it; for Fuchsia, NewOS is (was?) mostly used like a boot loader (and Fuchsia’s own kernel has nothing to do with NewOS); and for Haiku the kernel was originally forked from NewOS but has been radically changed since (including an early change from “micro-kernel” to “hybrid”).
NewOS was never a true microkernel to begin with, nor was BeOS. That’s one of those urban myths that seems to persist for some reason. They are both modular in the sense that drivers and various other things are dynamically loaded rather than being compiled into the base kernel image, but otherwise they have a ton of things in kernel space that a true microkernel never would. In any case, if memory serves, Zircon’s base was Lk.
Well the reason for that “myth” is simply, that one of the developers is the same: Travis Geiselbrecht
@cybergorf I meant the myth that they’re microkernels. None of them ever were.
Ah OK.
Yes they are not pure microkernels … but most of the drivers in Zircon/Fuchsia seem to be outside to the kernel, so its not a monolithic kernel either …
@cybergorf I meant BeOS, NewOS and Haiku specifically. Zircon is about as microkernel as it gets from what I’ve seen of its design.
According to Wikipedia, the Zircon Kernel is based in LK. But I don’t what what does NewOS uses. But I guess Travis Geiselbrecht is using similar ideas for all the kernels.
https://en.wikipedia.org/wiki/Fuchsia_(operating_system)#Kernel
Yes, Google intends to knock out Haiku OS. LOL Fuchsia has literally nothing to do with Haiku OS.
Haiku has added an extremely large amount of features on top of the original New OS kernel… I wouldn’t be supprised if there is more Haiku code in the kernel itself there than from Travis (and that isn’t a bad thing).
Does anyone have experience with Intel AMT?
It looks like the NUC can have a remote KVM using Fushia + Intel AMT / vPro:
https://fuchsia.dev/fuchsia-src/development/hardware/nuc-remote-management
It is kinda interesting, and worrying at the same time.
sukru,
Yes. It can be handy for remote access. I really wish it were open however, it’s the proprietary black boxes that are most concerning. Exploits have been found in the past. Security aside, the technology is held back by being limited to intel’s implementation.
Alfman,
For contrast, IPMI is also a black box, but at least partially open:
https://github.com/devicenull/supermicro_ipmi_firmware, and getting more open:
https://en.wikipedia.org/wiki/OpenBMC
But I am curious if AMT can also be managed in a similar way. Open source firmware? Open source / free remote tools? Dedicated Ethernet port (of course not all NUCs have dual nics), or complete disabling of it (all of which are possible in IPMI)?
Have you done any work or demos with AMT?
sukru,
Yes, anyone can create an implementation of the IPMI specification and there are plenty of FOSS tools that support it. But in general the hardware based solutions that are used with servers like DRAC and ILO remain proprietary (including their IPMI stacks). The existence of FOSS alternatives like OpenBMC is awesome, but if the hardware vendors aren’t going to support it then it’s still an issue. I haven’t tried supermicro servers(*). If it’s like the others then they provide a copy of the GPL source code that they used, but this is usually just a copy of the linux kernel source. Notably absent are the tools used to control their proprietary hardware. This problem combined with access restrictions create hurdles for customization.
There are FOSS projects that target external hardware to capture video, control virtual usb peripherals, and power & reset relays. This is cool since it gets around the proprietary hardware issues, but it’s a bit of a shame that it can’t run directly on the host system. Nevertheless, for ~$200, external hardware may be a more feasible than running FOSS on the proprietary hardware that ships with the servers.
* If anyone knows whether supermicro servers can run a fully open source IPMI/BMC, then let me know because that sounds great.
No the firmware is not open source.
Yes, there are free remote tools…
https://www.meshcommander.com/meshcommander
The AMT systems I’ve dealt with used a shared NIC. This probably won’t work for a NUC, but in a normal form factor you might be able to add a second NIC dedicated for the OS.
Well, some years ago I wanted to replace all the proprietary remote access tools used by the manufactures with a standard browser based solution requiring no tools at all (think of something like DD-WRT for remote server access). At the time many vendors required java applets and other local executables, which we all hated. I think this would have been extremely popular but with the machines being so closed I had no easy path forward. I’d have to reverse engineer every system I wanted to support with no guaranty that my work wouldn’t get blocked by manufacturers in future models. It just wasn’t viable for me.
Alfman,
Thanks,
I have heard about mesh commander, but did not give it much thought. Maybe it is time, I pull out my old NUC and test these over the weekend.
As for the open source tools, I think you are right about the effort needed. Even large open source vendors tend to lock out their server management tools to pay for the development costs (Ubuntu MAAS for example).
Redfish https://www.dmtf.org/standards/redfish
Flatland_Spider,
I don’t have hardware that supports those specifications 🙁
Supermicro seems to support redfish APIs on their systems:
https://www.supermicro.com/en/solutions/management-software/redfish
But I could not find a list of motherboards that support it. There is a mention of IPMI being replaced by that in X10: https://www.truenas.com/community/threads/supermicro-redfish-firmware-replaces-ipmi-on-x10-bmcs.39135/ (need to find one to test)
No, it required a RealVNC Viewer Plus license when it would have been helpful to me. It looks like there are free tools now though.
https://www.scivision.dev/intel-amt-vpro-kvm-port-forwarding-necessary
Certain NUCs have vPro. As always, Intel product segmentation makes something simple a labyrinth.
Flatland_Spider,
I looked at your link wondering if you had found a different solution, but it describes the same mesh commander I linked to earlier. I don’t know when you needed it, but mesh commander has worked with intel AMT for a long time.
It always annoyed me that intel took an essentially open protocol and modified it so it wouldn’t work with the the normal open VNC clients. It was such a hostile move, but they probably got a kickback from realvnc for doing so.
While mesh commander isn’t bad, it just ends up being one more client I have to install alongside the others, which is frustrating. Hypothetically I wouldn’t have a problem with one client that does it all: connect from any platform to any platform. But I know this is wishful thinking. Hardware vendors aren’t going to play ball. I really wish I could do away with all local clients for good and just use a browser. It would solve several problems in one go. Like being able to remotely connect even if I’m away from my work computer. I may not even be at a computer at all and all I have is a phone. This kind of remote access is less about perfecting user experience and more about restoring services quickly during an emergency. I don’t want to deal with installing proprietary clients, unsupported operating systems, incompatible versions of java, or god forbid even IE.
It’s so easy to use SSH tunneling to connect securely behind firewalls. I want to be able to eliminate of all the clients & middleware & complexity. If the hardware were open & modable, I’m convinced we could develop much better firmware, but as is we’re usually stuck with their proprietary solutions and having to interface with it.
This seems like little more than the classic “can it build itself?” test.
The “One Kernel to Rule them All” may be a utopia, but I want to see how close we can get to it. Maybe “Zircon” can became the microkernel open alternative to the Linux monokernel.