Submitted by Gnash (open source implementation of Flash) is now working on Haiku. “I’ve been busy porting the latest Gnash 0.7.2 release to BeOS this weekend. I did start this port as the other version that was apparently ported earlier this year never had a public release. I’ve achieved a full port that is using the AGG rendering backend and a native BeOS GUI. I also wrote a Firefox plugin based on my SVG plugin. The native BeOS audio handler is yet incomplete, which is the reason why I didn’t release anything yet.”
Haiku and mr. Lotz rocks!
I will very happy when I can see my kids playing their flash games (pbskids.org) on a BeOS machine, hope to see it at BeBits soon, (does require Bone though!).
Thanks indeed Michael ! I’ve been waiting for years for such news.
Now, all we need is a network stack and java
Well… what about Kaffe? Could it be used?
Edit: forgot the letters “bout” in “about”. Please, somebody slap me :p
Edited 2006-11-28 22:40
..but I never got it working right even under GNU/Linux.
Is it usable nowadays?
Is it usable nowadays?
It’s good enough to watch ads, but it still isn’t good enough to watch YouTube. None the less, it’s a great effort that is coming along quite nicely.
Great!
I can’t wait for Haiku’s final realease. It really looks promising, and I’ll surely install it on my old hardware which is looking for an OS like this.
On the other hand, I don’t understand how a bloated (read slow, not feature bloated) browser like firefox is having attention on Haiku. Well, I haven’t experimented Haiku yet, I’m just basing my experience from Linux, Windows and Mac OS….
I do think the same, so I’m organizing a group on college to port WebKit, but it will take quite a time before my mates get to know the BeOS API.
Point to start with WebKit on BeOS/Haiku
http://nirvana.berlios.de/
Thanks! That will help us a lot, I hope.
Here is the Google Group: http://groups.google.com/group/nirvana-browser?lnk=li
> On the other hand, I don’t understand how a bloated (read slow, not feature bloated) browser like firefox is having attention on Haiku.
The slow and not feature bloated browser that you say is the only multiplataform browser really updated that runs on Haiku/BeOS, and for me and others BeOS/Haiku users, runs very fine.
GNASH port is a giant step for Haiku… only remains Network and USB now..
It’s amazing, Michael!
Michael Vinícius de Oliveira
When I used BeOS as my main OS about a year ago, Firefox ran quiet well on it, even though my system was just 600mhz.
The BeOS firefix port has a lot of performance hacks done to it if I remember correctly… Like making it more multithreaded, At least as far as the GUI is concerned.
The BeOS port was the most responsive port of firefox I have used to date
On the other hand, I don’t understand how a bloated (read slow, not feature bloated) browser like firefox is having attention on Haiku.
The people who ported Mozilla to BeOS ran into all sorts of problems due to the Windows specific assumptions the original Mozilla developers used, which failed miserably in other OS’s which did not adhere to these assumptions. For instance, BeOS forces multithreading onto you, like it or not. The original Mozilla code base was by a significant magnitude less multithreaded (the GUI and platform specific portions, at least).
Under a BeOS system, the weirdest race condition would manifest itself almost immediately. The BeOS porters had to find these issues, and then fix them, one race condition at a time. This is why Mozilla for BeOS took ages to materialise compared to other platforms which were immune from these race conditions. Finally, the excellent developers succeeded in squashing every single multithreaded bug they could find, and backported these fixes into the original Mozilla codebase, making Mozilla more robust for all platforms.
The BeOS developers also identified unresponsive areas of Mozilla, where the code would be unresponsive for seconds at a time. Under other systems this is common, but sticks out like a sore thumb under BeOS. They made Mozilla more multithreaded in certain areas to improve responsiveness under BeOS. This was also backported to Mozilla tree, hence making Mozilla more responsive on other platforms as well. All Firefox users should thank BeOS developers for making Firefox for other platforms work exceptionally well with todays multicore CPU’s.
Having said all that, Firefox for BeOS feels more responsive than Firefox for Windows. I’ve got both installed, and the difference is noticable.
Actually I don’t think there has been much backporting by the BeOS-devs.
I’d also say the problem isn’t that BeOS is multithreaded, the problem is Mozilla forces single-threading on you in the most painful ways. You can notice this on all platforms when you open several tabs and the browser will be a bit unresponsive. Having one big event processor thread for all windows and tabs are a really bad idea and I hope it goes away. One thread per page would be a nicer fit IMO.
Yes Yes YES YES YES!!!!!!
Another one, who understands that bloat is not about features, but about the code.
Wrrauuuuffff
You can’t really copy files. On my 512Mb system, running Haiku, I can only copy a 200Mb file. And, when you have that [whatever it’s called] CPU/RAM monitor tool enabled in the Deskbar, you see what’s really going on…
Haiku copies the file from disk into memory… and then COPIES that file in memory AGAIN! Thus, a 200MB file takes up over 400Mb of RAM! And, on top of that, the file that is copied, isn’t copied to disk… it’s just copied in memory! Proof? Delete the 200Mb worth of file(s) from the destination and watch your “eaten up memory” drop by half! (i.e. you regain half your RAM) You thought it was written to disk, when you copied it? Guess again… seems Haiku has been taught how to read… but not how to write. Well, at least Haiku isn’t illiterate!
The initial 200Mb worth of RAM “eaten up” isn’t recoverable…, because Haiku never purges the *first* copy (in memory) of the file you just “copied”. Thus, if you copy a different 200Mb file… guess what will happen… I think you know.
Everyone is yelling “networking!” and “USB!”, for Haiku, but they’re failing to realize that, unless you can COPY files, networking and USB support are fairly useless.
Try downloading a 250Mb archive of some game/app/whatever, via networking (when it’s enabled), and then try copying that file elsewhere on your drive. On a 512Mb system, you will *CRASH* Haiku. You will enter the lovely realm of KDL every… single… time. This assumes that the very act of SAVING the file you’re downloading off the Internet/network, isn’t going into RAM, instead of onto the disk. If it’s being saved to RAM, how do you save it to disk? Reboot Haiku! That’s when it “finalizes” everything and cleans up. Gonna do that every single time you copy a large file? How annoying!
Got a nice USB hard drive you can use, when USB support is enabled? Oooh! Try copying a 250Mb file to/from it, and watch as you gracefully CRASH into the lovely realm of KDL…
No matter what anyone says, I still believe people are “putting the cart before the horse” in this area. And I think people are going to see how annoying this little mentioned (or maybe even realized) problem is going to become, when they’ve finally got access to their precious networking and USB.
The more *access* you have to large files, the more annoying this problem is going to be, and maybe even enough for some people to consider Haiku almost worthless as an OS!
If this is a simple problem to fix, then lets take the “5-10 minutes” to fix it and then get back onto what everyone is clamoring for. If this is a more difficult problem to fix, how much more stress do you think the programmer(s) will be under, when people are ranting and raving that they can’t copy large files, now that they have access to them, hmm?
Something to consider, methinks.
Edited 2006-11-28 15:58
I agree!
This bug is serious…. do you report to Haiku team?
And I agree too that have many bugfixes to do before release Haiku… But the bug list is going down… Network, USB and Flash are missing parts to be “feature complete”.. This not means that nothing more remains to finish the final version…
Michael Vinícius de Oliveira
Yes, this is a known bug. And there is someone looking at it, last I knew. But it isn’t a 5-10 minute fix.
This is *EXACTLY* why we aren’t providing ISO images. We know it isn’t done. We aren’t advising ANYONE to install except people that wish to bug hunt.
It is fine for people to not agree with our development priorities. Luposian and I have discussed this in private email. But the “people are ranting and raving” will not be an issue, since we won’t build a release with this bug. I mean – look – if you go download a nightly of linux and install it, you may well wipe your whole system. That isn’t to knock linux, but to say that nightlies are like that. It is their nature. The test VM images that we post are, well, just that. If you think that you should replace your work system or even a fun system with ***ANY*** OSS nightly build, well, you are braver than I am.
We have a huge desire to release perfect code. BeOS was known for stable releases and infrequent but solid revisions. We want to go in the same direction. Do you think that every build Be ever did, internally, was as stable as the published builds? Of course not. These releases are no different.
Awwhh… I couldn’t mod you up
Hey Luposian, no need to write a bible revolving around a single issue.
Haiku is still under development, so there sure are bugs and missing or unfinished features in it. That does not mean that it is not making progress, does it?
When I feel that “issue” is serious enough to affect overall perception of the OS, I think it deserves attention. If you can’t copy large files after you have networking and USB support, people are going to notice it even more than they do now. My concern is that the backlash from this “issue” could be very harmful, to those that think that, once they have USB and networking, the OS will be almost perfectly useable!
Be, Inc. put “wow” (look at all the cool stuff this OS can do with media files and stuff!) before “usability” (drivers! drivers! drivers!) and when the “wow” wore off, people were left, going… “but my video card…” this and “my printer…” that, and “my [whatever]…” else.
An argument I heard is that the reason they’re working on networking right now is so that Haiku can be a self-sufficient developer platform. This is a great idea, but if every single file you create/amend/copy is never taken out of RAM and written to disk, how much actual development do you think is going to get accomplished when your HaikuBox is KDLing because all your RAM gets eaten up? And, since every file you copy, takes up TWICE as much RAM as the filesize (it’s copied twice in RAM), memory will get eaten up in a hurry.
This issue does not mean progress isn’t being made. There is TONS of progress being made. And I love every bit of it! BUT… let us not forget that an OS is only as useful as it can be used. And I honestly believe this particular issue could be a real PITA, once people really start expecting this OS to replace BeOS. And Networking/USB is a big step towards that objective.
I just don’t want people to be angered and frustrated when they’re thinking that Networking and USB are the two biggest obstacles to really being able to use Haiku on a daily basis, and their system is KDLing because their memory all goes bye-bye when they’re copying files like there is no tomorrow.
Yes, this issue can be solved at any time. Before or after anything/everything else, but… should it be? USB and Networking are not fundemental to an OS’s daily functionality. But copying files, is!
Back in the days of the Atari 1040ST, no such thing as networking or the Internet or USB even existed for it. But try to use the system without having to copy/save/write files to floppy disk (or a HD, later on)… the system would be considered unusable!
I simply feel this issue is going to be a lot more annoying, the more people expect of Haiku. And getting Networking/USB is going to also make the system seem much more viable, which means people will expect more from Haiku at that point.
I simply do not want to see a repeat of BeOS’s fate, that’s all.
Luposian, you don’t get it, do you? Do you realize Haiku is still pre-alpha? Why do you keep writing as if this will not be fixed, when one of the devs has already acknowledged the problem and another has told you that it is being looked into? What is it that you want?
I know Haiku is pre-Alpha. Well, actually, I think it’s closer to true Alpha than that, but… that’s just my own feelings about it.
I’m not saying it WON’T be fixed, I’m simply saying I think it needs to be fixed sooner rather than later. For us all… not just me.
Do you realize that, if this one issue were resolved, I would actually be *USING* Haiku right now, even with as little as it does? Yes. I would be writing stories, updating my “Haiku Progress Log”, viewing my pictures and images, playing a game or two (does Circus Linux still work in it, like it used to?) and printing stuff to a printer in Haiku instead of BeOS R5 PE (WIND Distro). Why? Because it’s the FUTURE of BeOS!
But all I do now is download the latest build, JAM it, copy the files over to the Haiku partition, reboot, look to see if anything *visibly* has changed (usually not), run GLTeapot once, move some icons around on the desktop, and then call it a day. And I’m back in Windows XP or BeOS.
Do you realize that you can’t even DELETE a file that is over a 250Mb? Once you copy it over from the BeOS side, to the Haiku side, it’s stuck there! I tried it, not many months ago. You can’t copy across partitions from within Haiku, either.
And finally, you ask… “What is it that you want?”
I want to be able to use Haiku. And I can’t right now. I don’t care if it’s pre-Alpha or not. I could be USING Haiku right now (between downloads of the latest Revision) instead of waiting for Haiku to be usable. And that *one issue* is the only thing standing in my way.
I’m in no hurry to use Haiku like I can use BeOS or Windows XP or MacOS X (networking/Internet/USB, etc.) I just want to be able to use it in simple ways.
Maybe you’ve noticed… I tend to write really lengthy replies when I’m passionate about something. Well, this is one of those things… so get used to it!
The other thing is Christianity… get me started on that and you’ll NEVER shut me up! I love talking about God, Jesus, The Rapture, Prophesy, etc.
Good thing Haiku isn’t a Christian OS… my replies would be TWICE as long as they are now!!!
Latre!
Luposian
Edited 2006-11-29 01:22
Luposian,
I am brief and to the point: if you did in fact realize that Haiku was pre-alpha (or even alpha), then you would not be complaining at such length about any particular bug. At this stage of development, Haiku is supposed to have bugs; live with it.
Instead of so much whining, how about some words of encouragement to the Haiku folks who dedicate their time so that some day you can use the OS that you like so much?
Hey Luposian
You know very well how write your feelings 
Ow! I like so much from description of your jammin’ sessions.. I do it to…
If this bug is the wild and only remaining for your hard tests, it’s nice fix it to you feedback more bugs..
I feel the same with BeOS -> Haiku…
Good Luck!
Michael
> Good thing Haiku isn’t a Christian OS… my replies would be TWICE as long as they are now!!!
I’am glad we’re not on religionnews.com
Good thing Haiku isn’t a Christian OS…
Indeed. Haiku has The Church of BeOSology, which is of course greatly superior to all traditional, legacy, single-threaded belief systems.
http://www.bedoper.com/bedoper/2005/thirtyfirst.htm
“My concern is that the backlash from this “issue” could be very harmful, to those that think that, once they have USB and networking, the OS will be almost perfectly useable! ”
Except there wont be a backlash because Haiku is nowhere near finished and the bug is known.
If someone downloads Haiku now and gets a negative impression due to this bug, well, there’s no accounting for stupidity.
Well that’s what you get when you create an OS rewriting nearly everything from scratch instead of say reusing say a Linux kernel, bugs in ‘basic features’ are to be expected..
Eh, it’s not exactly as if Linux is immune from bugs in basic features. I recall a bug in a release in the Gnome 2 series, where copying/moving a file with Nautilus could cause the file to be irreparably lost – and that was in an ostensibly-stable release vesion, if memory serves.
I think you’re confusing application vs kernel bug, here the problem is a kernel bug not an application bug.
It’s quite easy to workaround an application bug: use a different application, whereas for kernel bugs it can be more a problem.
Note that I didn’t say this to criticize Haiku developers, but more as an answer to the original post.
If B.E.OS had produced something, it wouldn’t have had to deal with such ‘basic’ problem..
When Haiku gets mature, it will be interesting to compare the features of Linux and Haiku kernels, I bet that Linux kernel will have better real-time performance, and as good threading (of course Linux OS will still suck).
Oh well, reinventing the wheel is apparently fun: Haiku is alive and B.E.OS is dead.
While i agree with You about that file bug being more important than USB/networking i can’t agree with Your sounding as if HaikuOS project is pointless because there is Linux already.
Oh well, reinventing the wheel is apparently fun: Haiku is alive and B.E.OS is dead.
You tout Linux and then You write such thing… as if Linux didn’t start as a re-write of UNIX.
I didn’t say that HaikuOS was pointless because there is Linux already: current Linux OSs suck mostly for desktop, while a clone of BeOS should be a quite good OS for desktop.
But from a kernel point of view, frankly I doubt that Haiku/NewOS will ever be as good as Linux is, now this is not necessarily a problem, after all MacOS X is built on top of Mach which isn’t exactly the best kernel in the world, but there is a big difference: Apple has enough money to “make work” an antique microkernel but Haiku developpers don’t have that much manpower..
> as if Linux didn’t start as a re-write of UNIX.
Except that UNIX were proprietary and cost big bucks whereas Linux is Free.
[ BSD was embroiled in a legal battle at the time and didn’t work on 386 without FPU if memory serves, that’s why Linus couldn’t use it. ]
But from a kernel point of view, frankly I doubt that Haiku/NewOS will ever be as good as Linux is, now this is not necessarily a problem, after all MacOS X is built on top of Mach which isn’t exactly the best kernel in the world, but there is a big difference: Apple has enough money to “make work” an antique microkernel but Haiku developpers don’t have that much manpower..
Well.. I don’t think Linux kernel is “best thing in a world” and i think there can be something better done
. But those are subjective opinions. So we better use some facts. One of facts is that Linux ABI changes all the time and binary compatibility between versions is close to non-existing.
Haiku developers want to keep binary compatibility at least for Haiku R1 (but i suspect that even if some huge changes happen, there will be a way to EASLY run old apps anyway).
There are also many other reasons why Linux kernel was not used (like: license, modularity, clean & readable code…). It was already disscussed many times, and i don’t think bringing the same old “but why not Linux?” each time there is some talk about Haiku makes any sense at all.
Except that UNIX were proprietary and cost big bucks whereas Linux is Free.
BeOS was proprietary, commercial OS which was discontinued whereas Haiku is Free
.
> Oh well, reinventing the wheel is apparently fun: Haiku is alive and B.E.OS is dead.
B.E.OS is not dead.. simply support Zeta is more important than…
Happly, Haiku is alive and kicking..
Michael Vinícius de Oliveira
B.E.OS != BeOS. B.E.OS as in Blue Eyed OS a rewrite of BeOS ontop of a Linux kernel which went nowhere.
“Oh well, reinventing the wheel is apparently fun”
Good thing Linux didn’t reinvent Minix…
Haiku used the NewOS Kernel because it was the closest thing to the BeOS kernel already available, supported several platforms, and because the design philosophy was somewhat similar, as an ex-BeOS engineer created it
Of course, Haiku split off and had to modify the kernel to be true-to-BeOS, where it mattered.
The Haiku development model is rather nice and manageable and should not need change until there are more than 100 or so devs as members of one team. But I don’t see those problems coming in the next year or more.
The software reflects the organizational layout of that which created it. Haiku has an exacting guideline on not just HOW to write something, but in fact much of WHAT to write is fairly pre-determined in many cases ( though making it work exactly is another thing ).
I have written several rather large programs and system-level replacements ( for Dano ) and achieved a bug rate of about 1 per 10,000 lines of code, and usually just a matter of order of events, or a typo, or something that just never was finished
. I am not a spectacular programmer, as I have only been developing with C++ with some understanding of it for about five years, but WELL MORE than just a few of the Haiku Devs are extraordinary geniuses in areas I cannot even comprehend without an english-version source explanation.
But, even more than the value of the developers ( check out the changes these guys made to Firefox! ), Haiku will succeed simply because of its extreme modularity and clean & understandable organizational habits. From this, you can expect Haiku to be one of the cleanest, most organized, well-built OSes of all-time. Of course, this is subjective, but it will be hard to deny it when R1 comes near. And, very likely, Haiku will be impossible to ignore by R2.
At least for those who care
–The loon
P.S. I am not, currently, nor have I previously been, involved with the Haiku project directly. This, however, I plan to change very soon. Just trying to find where I would fit best, and could help the most.
[sarcasm ON]
OMG! The loon will join Haiku! This is the coming of the saviour!!
[sarcasm OFF]
Never said anything about being a savior.
In fact, all I really have ever done was to create 8 ( yes, eight ) distinct ( but related ) BeOS-based distributions, and spawn the effort and momentum at yellowTAB for the creation of Zeta.
Just to try and ensure clarity, Zeta contains none of my code anymore, and never contained any even beta-quality source from me, alpha was as good as you can say it got in regards to the state of my contribution, code-wise, to the creation of Zeta. The entire idea that yellowTAB create such a system from the Dano base, however, was my idea, proposed to Bernd in a BeShare private chat. It took some time to win him on the idea. I had to make him use PhOS Beta 2 before he was convinced.
So, if you like Zeta, you can thank me for that as well, if you so please. Or not, I don’t really care, just don’t like people talking out their arses about things they know nothing about. Of course, I didn’t spend these years programming for free just to have my contributions overlooked, either. I want them to be used, which is why I give them away.
Also, my release cycle for any apps has slowed to a crawl, use to be that I would have a new version of PhOS out every 2 months, give or take three days – except for the Beta 6 disaster. Sadly, the real world took its toll on me, as it does with everyone else. Even worse is that I have had repeated disasters in my personal life and health that has forced me to stop programming for periods as long as 6 months.
Something about memory… if you don’t use it, you lose it. After each off period, I would have to relearn my own code and thought processes. This was a nightmare the first couple of times, as none of my code was cleanly readable. It was all VERY efficient, and worked really well. But, I learned, that meant little.
So I created liblooncraz.so to help unify the code being employed in my apps. Simple evolution of a self-taught developer. Just happened very fast for me , primarily thanks to my excellent understanding of PC hardware, theory, and reality. Don’t confuse that with me saying I know everything. Not a chance.
The aforementioned Beta 6 disaster, was the result of my complete failure to properly back up more than just one or two revision of liblooncraz.so. I got my library into a corrupted state, and was unable to recover thanks to automatic backups, which lacked version-ing.
As such, I had to start from scratch again. So, I decided to study, research, design, re-design from scratch at least two or three more times, then finally cement an API for loonCAFE ( Core Application Framework Environment/Enabler/Extender ), my replacement for liblooncraz.so. If have already decided to implement a fully functional test of an AI-driven loonCAFE. The AI will be mostly implemented by projects derived from loonCAFE, though loonCAFE will sport surprisingly simple access to AI-Features.
AI ( yes, as in Artificial Intelligence ), as applied to this project, is applied via various AI-Search, AI-Animation, AI-Heuristics, AI-TypeFreeCache, and several other common, rather easy-to-implement in C++ algorithms. Several projects are based upon this project already, and it is still in a design phase!
Of course, they are all my projects. And all will be on SourceForge when loonCAFE gets to a basic standard API level ( i.e. the whats and hows are decided of the core central facilities within loonCAFE, and are beyond proof-of-concept ).
Oh well, I guess we will just see if sogabe can beat me to market the Next Big Thing. Last time I checked, I kept BeOS market alive with interest, nearly single handedly, for a what seemed a VERY long time. Hey, just google me
–The loon ( google: looncraz )
It’s not a bug, it’s a missing feature. Please be aware that Haiku is an operating system under development – it’s not yet a finished and reliable system, and not meant to be really used as is. Else, we would probably have had a release already
Currently, there is no timer to tell Haiku to write back its cached file system data – you either have to do that manually (using the “sync” command), or wait until the file is flushed from the cache (depends on usage and available memory). When you shut down or reboot, the file cache is always sync’d, though.
Thank you.. also I have a suggestion, I’ll post it here in case I don’t have time to e-mail it to you…
When KDL is envoked… please.. PLEASE! ensure that the pending writes occur prior to providing interactivity! Even though I have only seen KDL a dozen times ( in eight years.. every time from in-development drivers, and once from my own code ), on one of those times, I had terrible corruption in several files. Though that is the only time I have ever experienced software-related corruption on BeOS ( in fact, I’ve only seen corruption on Windows 9X, XP (a few times, mostly FAT32)).
Just an idea
–The loon
I am offering $500 to the first person who fixes the aforementioned “copy issue” before the end of 2006. It must be part of the Subversion process (i.e. show up on the “Haiku – CIA” page as a fix) and does not need to involve the (currently uninmplemented) VM, unless that is also required, to address the “copy issue”.
Payment can be either through PayPal or check.
The person interested must let me know they will be working on the problem, so I know who to pay. If a team effort is made, the $500 will be divided up evenly among those in the team. If there is an uneven fractional amount remaining (for 3 or 6 members), it will be paid to the person who did more in the effort.
This offer ends Jan. 1, 2007.