Hi,
On Thu May 09, 2013 at 11:16:17 -0700, BogDan wrote:
Recently I've watched these http://wiki.tudos.org/HOWTOs#Introduction_to_Fiasco.OC_and_L4Re%C2%A0present... on youtube. After I've seen them (many many times) I became fascinated. I started to "play" a little bit with Fiasco.OC and L4Re, I created a few apps and I must confess that I'm extremely impressed by your work. To me Fiasco.OC and L4Re seems way too good to be true, and I wonder if there are any "hidden traps" which prevents people to use it to create a general-purpose operating system on top of Fiasco.OC and L4Re, so my first question is: Can Fiasco.OC and L4Re be used to create free (GPL, BSD, apache, etc.) and non-free apps? I checked L4Re licenses and it seems that it has the necessary exceptions, but I'd like to be 100% sure :).
Yes, that's how it is supposed to work. Applications you write shall not be influenced by the base system.
I also have a few questions about the completeness of Fiasco.OC and L4Re:
- does L4Re have any OpenGL support? I checked the source code and it
seems that the only way to do graphics is via goos and it doesn't seem to have any OpenGL support. If I am right wouldn't be easier to port (and upstream) an existing server (e.g. xorg, wayland, mir, etc.) to L4Re, than to create one from scratch and maintain it?
The graphics system is very small and part of the secure GUI. One part of being secure here is that this component is small. Anything more functional can be built on top of that, including any existing systems. There's no OpenGL support in L4Re.
- does L4Re have any sound support? If it hasn't, then how hard will be to implement or to port an existing implementation?
There's no native support. Implementing/porting is a reasonably sized project, for example for a master thesis. Actually we had such a thesis some years ago. But the bigger problem is to maintain that afterwards, clean it up and so on. This is usually not happening as students leave etc.
- does L4Re have any real filesystem support (e.g. ext2/3/4, xfs, raiser, etc.)? It is ok for testing to use qemu or grub to load simple apps, but for a real o.s., apps need to be loaded from disk. Again, if it hasn't, then how hard will to implement it or to port an existing implementation?
Well, again, reasonably sized project to have a block driver and file system on top of that. To have some existing file system is certainly useful for data exchange and existing tooling. But again, maintenance is required, new block drivers, updating, keeping track with file system features etc. What we usually try to do is to use existing drivers, by using DDE and L4Linux because it has all the drivers mostly ready to use.
- it is possible to use a debugger (e.g gdb(server)) to debug (user space) apps?
No such thing. However, one can use QEmu and attach to the VM via gdb.
Adam