Live data from Hacker News

Haiku Project

haiku-os.org

81–90 of 146 posts

Re: Haiku Project

#81
post #30

I've played with Haiku in a VM in the past. But what is suggested that I do with the OS? Be a daily driver? Does it fit some niche use case? I have an old netbook, I'd load Haiku on the boot partition, I really would. I'm a sucker for something different (given the evils of Big OS and all), and for the underdog. Hell, I might even contribute if I have something (coding wise) to give. So I load 'er up on the ol' boot…

It's a general-purpose OS. Do whatever you normally do on it. More importantly, it's a learning tool. It's been part of many courses and many rounds of Google Summer of Code. It's an embeddable kernel + OS free of the cancerous GPL, under a permissive MIT licence. It is extremely well documented, well tested, and consistent. Writing drivers for it is very simple. This makes it interesting for education, for-profit de…

> free of the cancerous GPL, under a permissive MIT licence

Is this attitude common in the Haiku community? I was interested in checking it out but seeing this sort of rhetoric is discouraging.

Re: Haiku Project

#82

Interesting philosophy on why Haiku is not Linux-based (from the site): Linux-based distributions stack up software -- the Linux kernel, the X Window System, and various DEs with disparate toolkits such as GTK+ and Qt -- that do not necessarily share the same guidelines and/or goals. This lack of consistency and overall vision manifests itself in increased complexity, insufficient integration, and inefficient solutio…

I've always agreed with this, though I've never seen this particular text or seen it stated this way. Linux is a miracle of free software, it shows that a thousand people can come together and make a wonderfully complex system that actually works. But it is not elegant nor is it efficient, nor is there really any vision behind its creation. That's both a good thing (you can customize it and fork it to make it do anyt…

It's true, a working linux desktop system is pretty complicated and somewhat inelegant. But somehow, the more popular competitors are even more inefficient. They spawn and exec processes slower, context switch slower, you can't run a minimal desktop environment on them, only the huge default one. ("min-win" being the minor exception here.)

You can make a 50 MB bootable live USB with a minimal graphical desktop and a minimal web browser, based on linux. No such chance in less than a few gigabytes with the more popular alternatives.

The bloat of actual linux distributions and desktops is mostly down to user demand.

Re: Haiku Project

#83
post #71

Earlier quoted context omitted.

Also: Steve Jobs founded NeXT (which didn't hurt the prospect of a sale IMHO)

Also also: Be Inc. was founded by another ex-apple exec, Jean Louis Gassée. It was in many ways a better fit for Apple's core market (design pros and students who wanted a really slick, single-user multimedia workstation) but Gassée wanted too much money and (speculation here) likely still had bad blood with too many other Apple execs.

He is in agreement https://9to5mac.com/2011/11/11/gassee-thank-god-apple-chose-...

Re: Haiku Project

#84

BeOS (the OS Haiku is a reimplemntation of) has an interesting history. It was an OS that has a fully async C++ API (very novel for it's time and even now). The fact that it was async made the OS much more responsive and had a better CPU utilization. BeOS was another company that Apple considered to purchase but they ended up buying NeXT instead. IIRC they ended up going with NeXT because BeOS didn't have networking…

I wrote third party software for BeOS for a few years, I don't remember anything being asynchronous. BeOS was quite the opposite; everything was threads. Threads were cheap so it didn't matter if you blocked one. One of the demos rendered and displayed realtime video by spawning a new thread for every frame.

Window messages were done using a MessageReceived() function with message codes that was almost exactly like WndProc on Windows. Very C-like despite being a C++ API.

Re: Haiku Project

#85
post #30

Earlier quoted context omitted.

It's a general-purpose OS. Do whatever you normally do on it. More importantly, it's a learning tool. It's been part of many courses and many rounds of Google Summer of Code. It's an embeddable kernel + OS free of the cancerous GPL, under a permissive MIT licence. It is extremely well documented, well tested, and consistent. Writing drivers for it is very simple. This makes it interesting for education, for-profit de…

> free of the cancerous GPL, under a permissive MIT licence Is this attitude common in the Haiku community? I was interested in checking it out but seeing this sort of rhetoric is discouraging.

I guess a better way to start a conversation would be to point at all the effort and argumentation wasted over where the line between GPLed kernel modules and non-GPLed kernel modules is in the Linux kernel, as well as runtime disadvantages in some cases. The efforts to get ZFS encryption on Linux are a good recent example of this problem: they had to port the in-kernel crypto implementation from Illumnos (basically OpenSolaris) even though the Linux kernel has a perfectly good implementation of AES-GCM that would've worked without bloating the kernel modules.

Add to that the resistance to forming stable ABIs (and sometime APIs) in part to push everyone to not only license any kernel module as GPL, but to also commit it to the one true kernel sources, and I think there's at least a discussion worth having. But definitely not one to be started with "cancerous GPL".

Re: Haiku Project

#86
post #14

BeOS (the OS Haiku is a reimplemntation of) has an interesting history. It was an OS that has a fully async C++ API (very novel for it's time and even now). The fact that it was async made the OS much more responsive and had a better CPU utilization. BeOS was another company that Apple considered to purchase but they ended up buying NeXT instead. IIRC they ended up going with NeXT because BeOS didn't have networking…

IIRC, BeOS had networking but no multi-user or printer support. The latter was pretty important for Apple's pro market at the time, which was mostly desktop publishing. Just the other day I found a BeOS Revision 3 manual in a closet. It was the first version that Be released on x86 after getting snubbed by Apple.

It had printer support since at least R4. As I recall it even had some support for printing to network printers. There was an office package called Gobe Productive which was pretty nice for a BeOS application. Similar to AppleWorks or Microsoft Works.

Re: Haiku Project

#87
post #18

Earlier quoted context omitted.

The filesystem metadata queries were real-time back when spinning disks were much slower and neither the processing power or ram was comparable to what we have today. With today's machines we do not have the same experience under Windows, macos, GNOME, KDE. Feature-wise yes, performance no. Is there a technical reason we couldn't have the same filesystem integration? No, there isn't, it's just incompatible priorities…

BeOS did it by writing their own filesystem. The filesystem author wrote a good book about the design and implementation, including overviews of other filesystems (eg NTFS). He has made the book available for free download at http://www.nobius.org/~dbg/practical-file-system-design.pdf Ars Technica also has a nice 2010 article: http://arstechnica.com/information-technology/2010/06/the-be... The way it implemented the…

Yeah, Dominic Giampaolo. He works at Apple now and is heading its new file system efforts.

For years I though he was secretly writing a BeFS like replacement to HFS.

APFS seems less ambitious however.

Re: Haiku Project

#88
post #30

Earlier quoted context omitted.

It's a general-purpose OS. Do whatever you normally do on it. More importantly, it's a learning tool. It's been part of many courses and many rounds of Google Summer of Code. It's an embeddable kernel + OS free of the cancerous GPL, under a permissive MIT licence. It is extremely well documented, well tested, and consistent. Writing drivers for it is very simple. This makes it interesting for education, for-profit de…

> free of the cancerous GPL, under a permissive MIT licence Is this attitude common in the Haiku community? I was interested in checking it out but seeing this sort of rhetoric is discouraging.

That's just reality. In general the GPL is perceived extremely negatively. Almost every company I've worked for has had strict audits to ensure nothing we do or even previously worked on has touched anything potentially GPL.

If you're writing software for fun, enjoy seeing it being used, and still want attribution you licence it under the MIT or BSD, not the GPL. Many people get polarized on the topic and there are many discussion on stackoverflow and around where people seek or design MIT-like, GPL-incompatible licence specifically. Likewise, the GPL has its own cult following.

Regardless of personal opinions, few if any commercial entities willing want to work with the GPL.

Re: Haiku Project

#89
post #72

Earlier quoted context omitted.

Well let's don't get all romantic about something that was, in the end, half-baked. BeOS debuted at the dawn of the web, and it had a barely-working, userspace network stack and a web browser that essentially didn't work at all. It had some novel APIs, a nifty filesystem, and made for a damn good demo, but there wasn't much more to it.

The network stack was totally rewritten and optimized, in kernel mode, about halfway through the BeOS lifetime. The kernel did a better job at heavy threading and SMP than Linux or NT or NextStep at the time. The interrupt model and thus latencies led to much better soft real time performance than the other OSes at the time. I think it was more than half baked, but Linux took over the enthusiast market (with zero dol…

and it wasn't to _Be_

Re: Haiku Project

#90
post #57

Earlier quoted context omitted.

I'm not so sure. When you implement your own OS your hands are mostly free. With browser on the other hand, you have to comply to large, complex and evolving standards (HTML/CSS/Javascript). I might be biased by the fact that I dabbled a bit with the Linux kernel and dislike graphics programming, though.

Browser engines like WebKit are (with some work) portable to any platform with a C++ compiler: that's how the current Haiku browser is built.

So, now you just need to build a highly-optimizing, C++ compiler instead of a browser? That's another project that few got right over a period of a decade or so. Of course, one could use a C++ to C compiler or extend existing C++ compiler with OS-specific backend. Might still be plenty work but easier than clean-slate browser.
Post reply on HN