Haiku... building an OS for whom?

i wonder whats the purpose for Haiku?
should it ran on legacy machines like Pentium 1,2,3 or Hightech
Quadcore Processors? i personally like OSes that are free to use but also think that they
never gain enough publicity like Win or OSX. Which kind of users should use it? Sadly it lacks in
compatibility and software. There is no good office Suite to do productivity. No serious games for the gamer fraction. But the biggest fail is the missing Java and Flash support with an working,fast and stable Browser - so nothing for daily using. it runs on an very small collection of hardware.

i personally think that haiku will never get the big audience that it should.
dont get me wrong, i like the spirit of haiku but i think it will take a long long time to grow to an adult state.
first it should be fit for daily using like surfing the internet, listen to music streams, do some office stuff,
picture editing etc…

id like to see an alternative OS to big players like Win,OSX and Linux for people to enjoy for daily using.

time will tell

regards,
nemesis2k3

i guess it doesnt need to get a big audience. I think it’s enough if for some people it’s a useful OS. And in my case haiku works fine (since i dont need a lot of applications).
If it would have a complete port of chrome, and QT being in a good shape to be able to run LyX without problems, I would be most of the time using haiku.

Haiku does have a Java port as of a few weeks ago.
http://openjdk.java.net/projects/haiku-port/
As to Flash…well I seem to recall hearing there is a gnash port. Gnash is no good for web-browser gaming, but it will play Youtube these days.

What I love about Haiku is that it’s different like me. It’s not Win or OSX, it’s like me, part of the many neither represented by the loud oomplah of both extremes. It just works and is different. That I value above fanfare.

In my case, it is having an OS that I can understand all the parts of to write the wierd little programs I want to write.

Windows and Mac hide parts of the OS from a programmer like me (One not tried into their developer programs).

Linux is too massive and complex to understand if you don’t want to devote your life to it.

Plus Haiku’s source code is written to a very defined standard.

I can’t speak for the Haiku team, but for me, what Haiku offers is a free alternative to commercial operating systems that’s actually designed to be simple and usable for normal desktop users, as opposed to Linux which is hacked into that state from a very different baseline, and it shows. The prospect of being able to get used to the way the system works and no longer have to either readjust to or go to great lengths to avoid the continual, endless fiddling with UI elements that were perfectly fine the way they were (as I do with Windows) is more than enough of a draw for me; the prospect of a fully multi-threaded, lightweight and responsive OS is just gravy.

I believe that Haiku has a expertise: multimedia.
Commonly it’s referred as “Silicon Graphics for poor people”, like BeOS.
So, I think that is the Haiku’s way and focus.
But it’s very important that Haiku have a significant community of users and developers around the world, to give it improvement and support.

Do you know why the strongest core of Haiku developers are having so much fun working with it? Because all they need is a terminal window and Vim and the rest is wrapping their head around a kernel or driver problem to solve…happy as pigs in slop.

But if you want to develop at the GUI level, welcome to the early 90’s. I think the best chance of a decent GUI dev system is to get Mono ported and then beat MonoDevelop into submission where it can build either C# or C++ apps with the native GUI components. You should never have to mock up a GUI for your app in straight C++ these days. That is, unless you’re deliberately trying to keep your application dev population to a bare minimum.

This is why you see alpha after alpha come out, and, after that, beta after beta. There’s no hurry to go to R1 because kernel hackers have zero interest in building complex software at the application level anyway. No sane person is going to do a Gobe or TuneTracker app these days working with stone knives and bear skins for dev tools.

If a new app developer comes along, loads up Haiku in Virtual Box, the first thing s/he is going to say after seeing the GUI is, “Okay, now where’s the dev tools? What? You’re telling me in 2012, after I’ve experienced working with Visual Studio and Xcode already, that Pe or Paladin is the place to get crackin’? Ctrl-F to get back to Virtual Box…remove the Haiku disk image to save space. Too bad…I even kinda liked the GUI elements and was getting excited about building something.”

Lots of great things going on in system dev land on Haiku though. Advanced GUI stuff is the last thing on your mind in that space though.

The most fun I’m having right now is just bringing up Java apps with hamish’s OpenJDK port and being in awe of how ONE PERSON ported this monstrous platform to Haiku during a 3 month GSOC stint. But, this is write once, run everywhere. The better experience to attract converts to Haiku is going to be a great developer experience catering to Haiku native apps or a Ruby, Python or C# environ with native GUI. [bethon isn’t a dev environ. MonoDevelop, which is a fork of the SharpDevelop Project, can encompass what I’m saying…

More smart people need to be on the app dev tools side. Darkwyrm did a great recreation of the BeIDE(++). But it’s not 1995 anymore. No one wants to code like it’s 1995.

[That’s my rant. I’ve said my piece and it won’t be repeated]

There is no good office Suite to do productivity.

You mean native or what? Cause you know, you can run KOffice and ThinkFree Office on Haiku. First one needs a bit of work since it’s Qt software.

I think you’re right that coding of standard GUIs has advanced a lot on most other platforms. Still, this is achieved not by the OS but via IDEs and runtime libs that

  • avoid explicit coding of GUI element placing, initialization and setting of attributes
  • let you specify and assign event handlers to controls and dialogs instead of creating the central switch/case message-loop
  • integrate resource definition, loading and assignment (i.e. icon buttons)
  • usually also help with data access, be it web services or databases
AFAIK none of the "big" OSs provide event handlers for controls as an OS service - it's just that all of them run powerful IDEs that offer that abstraction level to designers and take over the lower level stuff. There have been attempts like MeTOS who tried to address that issue for BeOS but never got near the point where other OSs are today.

My view is we’ll need both - frameworks like OpenJDK that allow to run portable apps, including the usually equally portable IDEs employed in their creation. Those things will provide convenience, aka not requiring you to boot into Windows to create or revise a document/spreadsheet.

But if there’s going to be a killer app, I’m pretty sure it will be coded against the Haiku API to make use of it’s features. Tunetracker is not for everybody, but people want it and are ready to install BeOS/Haiku just to that purpose.
Of course, the creation of the killer app will be way easier and therefore more probable with a modern IDE that takes care at least of standard dialog/form creation and supports an event handler paradigm.

I’d rather see more push for better support of Qt and Java than .NET and/or Mono.

[quote=steveh]Do you know why the strongest core of Haiku developers are having so much fun working with it? Because all they need is a terminal window and Vim and the rest is wrapping their head around a kernel or driver problem to solve…happy as pigs in slop.

But if you want to develop at the GUI level, welcome to the early 90’s. I think the best chance of a decent GUI dev system is to get Mono ported and then beat MonoDevelop into submission where it can build either C# or C++ apps with the native GUI components. You should never have to mock up a GUI for your app in straight C++ these days. That is, unless you’re deliberately trying to keep your application dev population to a bare minimum.

This is why you see alpha after alpha come out, and, after that, beta after beta. There’s no hurry to go to R1 because kernel hackers have zero interest in building complex software at the application level anyway. No sane person is going to do a Gobe or TuneTracker app these days working with stone knives and bear skins for dev tools.

If a new app developer comes along, loads up Haiku in Virtual Box, the first thing s/he is going to say after seeing the GUI is, “Okay, now where’s the dev tools? What? You’re telling me in 2012, after I’ve experienced working with Visual Studio and Xcode already, that Pe or Paladin is the place to get crackin’? Ctrl-F to get back to Virtual Box…remove the Haiku disk image to save space. Too bad…I even kinda liked the GUI elements and was getting excited about building something.”

Lots of great things going on in system dev land on Haiku though. Advanced GUI stuff is the last thing on your mind in that space though.

The most fun I’m having right now is just bringing up Java apps with hamish’s OpenJDK port and being in awe of how ONE PERSON ported this monstrous platform to Haiku during a 3 month GSOC stint. But, this is write once, run everywhere. The better experience to attract converts to Haiku is going to be a great developer experience catering to Haiku native apps or a Ruby, Python or C# environ with native GUI. [bethon isn’t a dev environ. MonoDevelop, which is a fork of the SharpDevelop Project, can encompass what I’m saying…

More smart people need to be on the app dev tools side. Darkwyrm did a great recreation of the BeIDE(++). But it’s not 1995 anymore. No one wants to code like it’s 1995.

[That’s my rant. I’ve said my piece and it won’t be repeated][/quote]

Uhm… no one interested in… pigs in slop (nice)… what do you call this that was posted only last week… http://www.haiku-os.org/blog/czeidler/2012-09-03_ale_auckland_layout_editor

Sure its a layout and property editor not a full IDE. But its one piece of the puzzle. Add a way to double click on an event and have it auto-generate the event code and open it in paladin, and you’re basically there.

Personally, I think making mono work natively sounds like a real ugly way to move forward, and probably a huge amount of work. It’s not like many Linux apps are really using Mono anyway in my experience. Its a nice way to make your .net apps work on Linux or to develop if you dont know much else but C# and .Net, but I can’t see many other people using it. Mono doesnt have WPF even. And if youve done much WPF development you quickly learn that its much nicer and easier to code your GUI in XAML with the benefit of being able to see the changes you make live than actually laying the stuff out manually yourself. I have to say I’d welcome something like XAML inside the auckland layout editor.

Not that I don’t see your point. This is something that needs to be addressed, but I do think that more programmers than you imagine are happy working without an IDE like the one you describe for the time being. And when this is done, it should be done properly, not by cludging on .Net or a non-native toolkit. IMHO, the reason the majority of core haiku developers arent spending time on this is because they are core haiku developers trying to get the core of haiku to a stable and useful place. I imagine with the advent of R1 (which is looking pretty close right now) things like this will take higher priority, but right now they’ve got bigger fish to fry!

Is .NET even used for anything really worthwhile? All I’ve seen it for is little single-purpose utilities that are typically Windows-specific, or just complicated enough that a command-line interface would be a hassle to write. Paint.NET is actually the most complex, useful, and general-purpose program I’ve seen developed on the platform…

C# is used much for web development. Microsoft pushes releases frequently and there’s a growing ecosystem of open source. (Linux can share much of it via Mono, but not all of the Microsoft frameworks are available in Mono out of the box.)

It’s easy to get started, BTW. Free dev tools at www.asp.net.
Project community over at www.codeplex.com.

Argh, scratch that, Oblivion Mod Manager is the most useful thing you need it for, as I just discovered. Gah, I hate how it’s becoming the standard for quick-'n-dirty GUI frontends for utility programs - it’s like Visual Basic used to be, only instead of a 500KB DLL it’s a 50MB+ framework…

This. I’d rather enjoy more polished Qt and Java ports with most of the software working without additional input.

This. I’d rather enjoy more polished Qt and Java ports with most of the software working without additional input.[/quote]

Both Qt and Java have good support for multi-threaded code. How good is .NET or Mono?

The reason I ask is while I can’t write the high end programs some people want to be written for Haiku, there is some stuff I do plan to write and release. The main thing holding me back is finding free time and learning all the basics of multi-threading.

Lately, some of my personal programs have shown major gains in speed because of the use of Haiku’s MT functions with speed-ups of 4-6 times being common in my type of programs and a few times an increase of 8 or more times. And this is on a dual core CPU with two extra hyper-thread CPUs.

The promise of Haiku is that well written programs that use it clean APIs will out-do on the other OSs out there. But it does take time to learn how to write good programs and no IDE can lift the burden of good planning and design of the programmer`s shoulders.

A good IDE will handle the grunt work of laying out a program, but good programs first must start with a good idea.

For multi-threaded support on .Net/Mono, lookup PLINQ, the TPL Library, the Rx Library and the new async / await keywords in C#.

Right. The things you mention attempt to make multithreading easier or even leave it to the runtime when to parallelize tasks. Long before that, .Net has provided the worker class as an interface towards explicit thread management by the developer. Method delegates (basically a method usable as a callback function) are important as well as those take care of the locking required when a worker changes data owned by the main or in general another thread.

That’s not bad at all, really. Still I’d rather see all effort focused on completing the OpenJDK port. BTW, something like Oracle’s SQL Developer has about 50% higher performance on Haiku compared to WIndows (Core i7 Quad). That thing is heavily multithreaded.

Haiku has been built for people with older hardware. Haiku was never intended to become mainstream as such. But personally I think that it will become quite big with XP users in a few years time when there hardware is ancient

Gamers. No need. Windows will never be beaten for gaming on computers.