General Haiku Discussion

http://usbip.sourceforge.net/

It looks like it just relays all the USB data over IP and recreates it locally and even works for webcams and printers.

I'm not sure how well it work work over a wan but if the connections were fast enough it might be good for testing less common USB hardware like wifi (USB wifi doesn't seem to care how slow you run it as even 1.0 USB ports work with mine) and cameras and other hardware.

In any case it would be a very nice feature to have in Haiku.

Perhaps this would make a good GSoC project?

I've started porting Haiku to the ATNGW100 board using AT32AP7000 processor (the board has 32MB of RAM installed). You can see it in "action": http://www.youtube.com/watch?v=VMe2gY3IMMM. Well, it's just bootloader via serial console for now. What is done:
1. GCC patched & recompiled for target avr32-haiku (required recompiling gcc first with newlib, then porting stuff from libroot and finally rebuilding gcc with Haiku libc ;))
2. Modified build scripts
3. Initial port of the bootloader
4. Most of the Haiku code simply compiles for the new architecture
5. arch/avr32 code written in many places which require this

For now I'm working on changing the bootloader u-boot port to support multiple architectures, writing AVR32 ELF relocation code and writing basic SD card driver to be able to load kernel from the SD card. libroot still requires some work to fully compile (mostly floating point library and syscalls, but this should wait until I decide on the virtual memory layout of the system).

Ultimately I'm programming a lot on Qt on Linux, not so bad but shouldn't it be beautiful to can use Haiku/BeOs API on Linux (or Windows or OSX)?
This is not the usual proposal to port BeOS on a Linux Kernel, please not misunderstand me!
I'm absolutely contrary, to this as you know, but in a cert-sense is exactly the contrary make Linux better using Be API!
In the end is the same thing done by Nokia for QT and Sun for JAVA: a framework targeting a Virtual Machine that in this case is incidentally real(Haiku/X86).
In the end Haiku has advantages to this as applications developed for other OSes using this imaginary framework can run natively on it!

So we have:

1. Command line applications works out the box in all OS
2. GUI applications on Haiku works out the box as it is a normal application for it! (it uses libbe, Application Kit, etc...)
3. GUI applications on Linux links the Haiku libraries compiled for Linux, Application Kit uses in some way native Linux APIs (GTK and so on...)
4. GUI applications on Mac OSX links the Haiku libraries compiled for Mac OSX, Application Kit uses in some way native Cocoa APIs
5. GUI applications on Windows links the Haiku libraries compiled for Windows, Application Kit uses in some way native Win32 APIs

If you want you can think to do something similar to that Google done per NACL:
http://www.chromium.org/nativeclient/getting-started/getting-started-bac...

that is, we can create our "runtime", our gcc, our unified posix library, our ABI (that is the Haiku/Be ABI); that is in Linux not use system printf() but our own implementation for example, so in the end we can obtain a marvelous result:
I create an APP on Windows and it runs without recompiling (!) works out-of-the-box on Linux (and Win32, MacOSX, etc...) and NATIVELY in Haiku!

It will be fantastic and I suppose very possible, if we want :-)

And we can imagine to do the same pass of PNACL, targeting an Haiku on immaginary and then jitting (compilin just-in-time after during the runto the native CPU) using LLVM for X86, ARM, PPC, MIPS...

What you think?

olá, não sou muito bom com o inglês por isso escrevo no bom e velho português tupiniquim a minha duvida é o haiku é compativel com o notebook positivo sim intel core 2duo t6400 já testei durandte um bom tempo no meu desktop gostei e agora queria usalo em meu notbook tmbm