Two interesting bits of news from the Haiku front. First, Haiku now has basic support for FireWire, thanks to GSOC student JiSheng Zhang. You cannot connect a FireWire hard drive just yet, though. Second, Russian BeOS hacker Troeglazov Gerasim has ported Samba 3.10 to Haiku, so you can now browse your Windows shares in Haiku, as well as share files through Samba in Haiku. IsComputerOn has the details, as well as some screenshots.
He is Gerasim Troeglazov, not Troeglazov Gerasim. Gerasim is the first name.
The progress seems to be great. Especially Samba/CIFS support is something that boosts usability-level in many environments. Hope it will really reliable and fast.
Then we need a powerful UI to configure it
All good news obviously, however as far I’m concerned. If FW is in place, it’s great, that means wider support for a lot of devices and USB has overtaken the standard so one could say that with this, FW is a completed step that doesn’t really has to be looked back at.
Very good job all though and a special thank you to the one bringing the actual “report” about it.
Well, USB has taken over FW only for non-video things basicly. FW is still very much “there” for high-end video related devices. Since Haiku aims to be a BeOS replacement, which was always good in esp. the audio/video market, FW is an absolute must-have for also becoming a serious contender in that area.
However, for normal desktop usage, I agree USB has gone where FW was intended to go
Don’t forget that most external audio interfaces out there use firewire as well as many external HDDs.
But it’s true that for normal desktop usage there’s not much need for firewire.
Edited 2007-09-03 12:43
I disagree, an external FW/USB2 combo external drive is still way more useful than vanilla USB drive and the FW connection is noticeably faster than USB2. Since BeOS never had any real support for USB2, getting FW for drives would be excellent. I find USB to be pretty tacky anyway.
Nice thing with combo drives is that you can reuse the casing and bridge with bigger drives so you can keep the better interface. It’s a shame that FW interfaces on drives are usually priced to make buying them a harder choice though.
Isn’t that because FW is more expensive to implement?
In the same volumes there is no real reason why a 480MBps USB2 chipset should be any cheaper than the slightly slower (but much more efficient) 400MBps FW chipset Since the market sidelined FW to Apple and the high end video equipment, the NREs have less place to be spread around and both of those markets usually can bear higher prices anyway. Its like VHS v Betamax.
Anyway, I will now look for eSata as an FW alternative so that the drives are running at full speed over serial wire, that would be 1.5GBps or even 3GBps (raw rate). Remember FW is really very old now. I hope the Haiku team will have eSata support one day too, no idea if thats difficult, Sata already works for me on R5.
Sata already works for me on R5.
You mean SATA in legacy emulation mode?
I’m not aware of any SATA support for R5…
Update:
Haiku already has more SATA support than R5 ever did (which was nil, since SATA was created after Be, Inc. went out of business) – in fact, Haiku should nearly have as much SATA support as Zeta did at this point
Edited 2007-09-04 02:12
I was also surprised about getting plain old R5 working on a SATA drive (took a few months fiddling though), am I the only one?. FWIW it is on a cheapo PCChips A31G socket 754 with an included 2800 Barton? for about $70 awhile back.
When SATA was first touted by Intel it was promised as an upgrade to PATA that wouldn’t need OS changes and just work as is. That didn’t pan out when I first tried it. Still never got W2K booting on an Intel mobo with SATA boot drive. I don’t expect R5 to just work on other SATA boards, I got lucky the compatibility was okay. Another bonus was my best case transfer rate went from 5MBs to around 30MBs similar to W2K for large files, that was a real unexpected bonus.
When SATA was first touted by Intel it was promised as an upgrade to PATA that wouldn’t need OS changes and just work as is.
That’s generally known as “compatibility/legacy mode” – where it emulates PATA.
I think the intent was to phase that out as drivers were created for various modern OSes.
FW is more expensive, due to the fact the interface is much more intelligent than USB. That functionality isn’t utilized in smaller devices, so manufacturers have gone to cheaper USB. FW is faster because is has it’s own dedicated clock wires, where USB has to embed a clock signal in it’s 2 wire implementation ( the other 2 are power, ground). That means that many of the bits in the 480Mbps are used only for the clock synchronization, and your actual data throughput is much lower for USB.
FW actually allows devices to be daisy-chained, up to 63 devices, and hot-pluggable. There is FW800, and the spec actually is defined to go to 1.6gbps, but hasn’t really been adopted.
Now that would be a cool Haiku screenshot… 63 FW devices.
But I think your right, eSata will prevail in the future.
Actually, the main reason AFAIK why firewire is more expensive is because Apple charges hardware manufacturers relatively exorbitant licensing fees for each firewire port used on a device. USB has prevailed because Intel chose not to charge excessive licensing fees for it & it is a fairly open standard to implement. Though yes, firewire hardware is a bit more expensive to manufacture as well, so the expense has been compounded, hence its unpopularity with manufacturers.
Can’t wait to see support for floppy disk and hard-disk drive as well.
When can we expect a R1 release of Haiku? Is it on the map? Does anyone know if you can run Firefox on Haiku, it worked in the past but does it work now?
Edited 2007-09-03 12:46
The standard answer is “when it’s done.” Software development on this scale, especially working with volunteers, is _so_ unpredictable. Every time anyone has said “this’ll be the year!” — Haiku developer or otherwise — they’ve been wrong. Just so you know, though, the consensus that I’ve seen from the guys is that there’ll be an official alpha release once we are able to do self-hosted development. It’s possible to use gcc under Haiku right now, but it’s very much hit-or-miss and it’s more of a state where you can say, “hey, I can compile something… wait a second — that just worked a moment ago?!”
Roadmap != deadline
The reluctance to have a roadmap may have its roots in the early (unrealistic) predictions that Haiku would have a beta in one year or two (which obviously never materialized). This is understandable, but there is no need to go from one extreme to the other.
A roadmap does not have to be a deadline set in stone, but rather a set of milestones (for alpha, beta, R1 and so on) with flexible time frames (instead of dates; for example, 2008 Q1) subject to change depending on how development progress. This would not only show those watching the project what to expect down the line, but it would also avoid having to answer ad nauseam the “when will R1 be released?” question.
Roadmap != deadline
Wow, I completely missed this comment earlier.
This is *exactly* how I feel. What Haiku needs is a “well defined” goal, regardless of dates.
Right now everyone is just plugging away to complete R1 without knowing what’s really left to complete. There’s just a loose “it will be a replacement for BeOS R5” goal that is repeated over and over.
There are some milestones setup in Trac, but I think they’re not complete. Trac also is not a very good way to publish your roadmap.
What needs to be done is define the areas and or milestones required for an R1 alpha/beta/final and publish them. Without that, everyone will keep asking the questions over and over.
Also with milestones, newcomers know what the priorities are, and where they can help first.
Finally, as soon as you feel you can set deadlines confidently, then they should be set (with some room for error). This increases confidence in the team. It increases confidence in themselves. Setting and achieving goals (even if they’re smaller ones) is what drives people forward.
I misunderstood the original comment — sorry that I haven’t gotten back on this sooner. I’m working on one. It might take a bit, but there will be one for public knowledge soon.
I misunderstood the original comment — sorry that I haven’t gotten back on this sooner. I’m working on one. It might take a bit, but there will be one for public knowledge soon.
DW, Thanks for responding again
Honestly, I think the “when it’s done” response needs to just stop being uttered entirely (especially in public).
As much as this may be the truth in the eyes of the people working on Haiku, it is an extremely poor answer at this point in the game. It also tends to sound somewhat pretentious to those who aren’t actually doing development work on Haiku.
Every time I hear it, it drums up the same questions – most often: “How will you know you’re done?”
DW, thanks for listening. In the best Haiku spirit, apply the KISS principle, and keep it simple.
http://www.iltuosistema.it/immagini/haiku_test1/haiku_test_10.jpg
http://www.iltuosistema.it/articolo27.php
Ah, that picture is a thing of beauty.
http://youtube.com/watch?v=yAc-NDR35Sk
Anyone having flashbacks?
Ye, that was cool when Windows 95 was the rage. You do that these days on just about any OS without batting an eye lid.
I wonder if you can do the same using “just about any other OS without batting an eye lid” on the same hardware. I could not.
When I tried Ubuntu Studio (which uses a low latency Linux kernel) on the same hardware that I ran that Haiku demo on the video, by the third instance of the video the mouse became jumpy and the sound started stuttering, and by the fourth instance the mouse stopped responding and would not even move, the sound and video came to a halt, the hard disk started churning like crazy, and all I could, short of doing a hard reset, was try to force a log off by restarting X, which did work but took several minutes.
I also use Windows XP regularly (on a different machine with double the amount of RAM), and I find myself having to wait for the system or an app to respond even the OS is not under heavy load. I will not talk about Vista, which I tried and uninstalled immediately as it was slow as molasses even with no apps running.
The point is that Haiku (like BeOS was in its days) aims and is designed to be more responsive than other OSes on the same (low-end) hardware. Of course, you don’t have to take my word for it.
It’s not just video. It seems any number of programs can slow Windows down while do some basic house-keeping.
My girlfriend uses Plan3D a house design program, from the time you double click on the icon to the time you can start using the program is over a minute, with no dialog boxes on display during that program boot-up. But while that program is setting itself up I can’t start up any other program not IE, not MSWrite, nothing, no even any of MS’s games that all all small any light in hardware needed.
On BeOS even a hog like FireFox does not prevent me from starting other programs while it sorts itself out.
I downloaded the large Ratatouille trailer from Apple’s quicktime site. http://www.apple.com/trailers/disney/ratatouille/
I duplicated the file 8 times and opened those 9 files in Quicktime. Launched all of them and hit exposé to view all the screens at once. No stuttering, no slowdowns of mouse movement. It was a bit freaky seeing 9 copies of the same video running at once, but that’s beside the point It’s a shame I can’t make a video out of it and post it on youtube in response to the Haiku video, unless someone knows of a free video capture program. Things started slowing down at 12 instances, but I guess you can’t have everything.
So no, it’ll take more than a video showing simultaneous playback of 6 video files to make me bat an eyelid
edit: I’m using a 1st gen Macbook with a 2 Ghz Core Duo and 2 GB RAM. I don’t know what machine was used in the demo, but if it was a PIII or something, then I’d be impressed.
Edited 2007-09-04 14:53
> I’m using a 1st gen Macbook with a 2 Ghz Core Duo and 2 GB RAM.
Nice try. But do that on on a machine with an AMD 3000+ CPU than runs at 1.8GHz (or equivalent) + 512MB RAM.
Shall I make you a coffee while you wait for your MAC to boot?
Disabling one processor core still allows me to play 7 videos without any dropped frames. Granted, there is still a 200 MHz advantage and more RAM but it’s not that bad for an OS where people were going OMG, look mach-kernel sucks!!111!1!
I think I’ve learned two things from this little exercise:
1) OS X ain’t that bad despite benchmarks showing processes being 5 – 10x slower compared to Linux (remember the whole Anandtech nonsense where threading performance was benchmarked using fork..) . If anything, it is much more responsive than Linux and closer to Haiku in terms of coping with load.
2) Something is not right with OS X’s multi processing support. 1 core handles 7 videos flawlessly. 2 cores handles 10. Surely if the OS utilized the cores as efficiently as possible, this should result in 2 cores handling 14? Maybe this will be fixed in Leopard?
3) Linux ain’t that hot and Haiku is pretty neat. I haven’t run Linux on my macbook so I can’t say what kinda performance I would get, so I’m just taking what you guys say about how it can’t handle 3 video streams. Same goes for Windows.
4) I cant count for squat…
I suspect that OSX would crawl with 512MB, like Ubuntu did in my case. I cannot prove it, though, as I don’t have a MAC.
One thing to also keep in mind is that Haiku is still un-optimized pre-alpha code; a new and hopefully better scheduler is being worked on (GSoC project), and many other components will most likely be optimized, so it looks like there is still room for improvement.
Anyway, OS X is a really cool system, and if it works nicely for you, that’s a cool thing too.
I suspect that OSX would crawl with 512MB, like Ubuntu did in my case. I cannot prove it, though, as I don’t have a MAC.
Its… not great. Its absolutely unusable with 256MB (well 10.4 is anyway), 768 is the least I’d suggest as “OK”.
Hehe evangs! i think you won’t even believe what BeOS can do with a dual PII 266Mhz, 64MB ram, 3GB drive 😎
http://www.youtube.com/watch?v=ticLQ4T_wVg (this is on R4.5, around 1999) you can skip the first 4 minutes
Haiku is not optimized (not even finished) yet so you can’t compare with OSX right now, but this BeOS demo can give you an idea of the potential
Edited 2007-09-04 18:26
That is impressive! I remember seeing that video years ago. It’s good to see it again I remember getting BeOS 5 personal edition off a magazine cover back in 2000 and was so excited. Shame it didn’t have the drivers needed for my ATI graphics card but it was much more usable than Linux was back then.
Pity it died out. Here’s hoping Haiku will amount to something in due time. I might try playing with it via VirtualBox.
If by ATI graphics you had a Radeon, then you would have been in luck. granted it took a year or so between R5 being released until the Radeon was supported but it got there.
http://www.bebits.com/app/2938
Edited 2007-09-04 21:40
And here I thought OS X used the 3d-hardware in your graphics card, making it a completly unfair comparison. So maybe you can cut Haiku some more slack
And here I thought OS X used the 3d-hardware in your graphics card, making it a completly unfair comparison.
I was thinking the same thing – doesn’t each window represent a 3d surface allowing the OS to rely on the hardware to do all the clipping, etc?
Can’t edit my other post anymore
Anyway, here’s the video of my Macbook doing 10 instances of video playback smoothly. http://www.youtube.com/watch?v=UoAWEoN8e3c
Excuse the mobile phone quality, but you should still be able to see what’s going on.
“You do that these days on just about any OS without batting an eye lid.”
not true…
The type of response Haiku (or BeOS) is capable of is simply not possible on the same [my] machine running opensuse 10.2 without extensive tweaking. That amounts to real time kernel installation, jack audio installation etc.
Even then, the resulting performance is not nearly as good.
All other mainstream OS’es uses the 3d-acceleration of your gfx-card as well.
A couple month ago, my USB mouse would eat up about maybe 25% CPU whenever I’d move it. This was a lot, compared to a PS/2 mouse, which barely blipped the CPU meter. A little more than BeOS R5, but…
Now, whenever I use the mouse, it devours a whopping 75-80% of my CPU whenever I move it!
You might think… “it’s a USB issue”. And you might be right, except for one thing…
I can run GLTeapot and hold down any key on the keyboard (repeating a given character on and on) and the Teapot slows down, maybe, 10fps or so.
I move the mouse and I lose about 50-60fps.
From what I can tell, this is not a USB issue. It’s a mouse priority issue.
Why in blazes is the mouse being given “god status” (all CPU cycles must stop and worship the almighty USB mouse, whenever it moves)?
Of course, if this were always the case, even a PS/2 mouse should probably exhibit the same thing, which I don’t think happens…
Eh…
Something’s up and I dun like it!
We have 4 months left before the end of the year. Any liklihood of seeing File Copying working *correctly* before then? Any wagers?
I will donate $500 to the responsible individual (via PayPal) who finishes this, if it’s completed this month. Or I can give it to Haiku, Inc. Or HaikuWare Bounties…
That amount drops by $125 at the first of every month that goes by.
From what I can tell, this is not a USB issue. It’s a mouse priority issue.
Why in blazes is the mouse being given “god status” (all CPU cycles must stop and worship the almighty USB mouse, whenever it moves)?
Under the original BeOS USB stack (inputserver) usb mouse/tablets didn’t use so many resources, you could set the priority pretty high so that the pointer was responsive but because it wasn’t doing much, just copy a few bytes only once in a while (100Hz) it didn’t have that much impact.
I think USB is probably not the big consumer of CPU cycles in this case. Screen areas have to be redrawn whenever the pointer is moved. The mouse pointer is currently software rendered and not a hardware bitmap that the card could simply overlay. (There’s a pointer in every Haiku screenshot.) I’m sure someone will eliminate this little performance thief eventually, and make Haiku use pointer overlay when supported by hardware.