Exactly this. It is the same reason why macOS is also an OS that doesn’t have tons of separate inconsistent subsystems for the GUI, Sound, Network, Input, clobbered inside to make a distro. Ported apps and wine apps also exist on MacOS and they are always third party.
I don’t see anything wrong with having both native apps and ported apps, just as long as the ported apps can fit in by using the Haiku icons just like the Qt apps and we don’t start bundling an actual xserver or wayland frontend just to run those apps.
I don’t understand what is so offensive about ports. If they’re useless to you, don’t use them. Personally, if a native application exists for what I want to do, I will jump at the opportunity to try it out. But if such an application doesn’t exist, then I will try a ported application instead. At the end of the day, my PC, its operating system and applications, are tools to get stuff done. Some tools are better than others, but having tools is better than not having them.
All of the applications that are included with Haiku are native. Also, because “native” actually exists as a concept on Haiku (unlike Linux where every toolkit and so on is equal), ported applications tend to be adjusted in various ways to fit the rest of the operating system. Qt applications on Haiku are a whole lot less jarring than they are in GNOME for example.
So to say ports make Haiku into a Linux clone doesn’t make sense to me at all. If you want to make Haiku less like Linux, there are other areas that could be worked on. For example:
Use file extensions for differentiating file types. File type detection is pretty wonky on Unix-likes
Implement case insensitivity
Make a “device manager”, so that devices can be disabled or have their drivers changed through a GUI
Allow more than one version of an application to be installed. A lot of people need this, either for reporting regressions, or for simply using a version that works better for them
Linux devs do have coding standards - for the kernel only. After that it’s open slather. But even distros can have their own coding standards. Also, some distros stick to the traditional purpose of linux: servers, hacking, pentesting, etc… So there’s no reason why Haiku couldn’t keep coding standards, keep a traditional version with native apps, but still allow freedom for others to do as they please (in forks for example).
There are many OS’s that have gone nowhere, because their outlook was too narrow, and they cultivated few users & conributors.
Look at Minix: a unix-like OS with few users and developers. Yet it is believed to be the most utilised OS in the world - because Intel uses it for free in its processors. If Minix had played its cards right, and charged a small licence fee for commercial use, it could be a wealthy entity by now. Instead, it missed an opportunity and is still a struggling OS.
The freedom of Linux & FOSS led to an ecosystem that has included hardware like laptops, SBCs, phones, etc.; Android OS that dominates the phone market; and Chrome OS that led to chromebooks (and soon to be released gaming Chromebooks).
So if Haiku supporters think “ecosystem” and not just “OS”, there is no reason why it couldn’t follow - and even surpass - Linux’s ecosystem, should it prove to be a better coded system. Wouldn’t you like to see Haikubooks, Haikutablets, SBCs, phones, etc? You’ve already got the T-shirts, so you’re kinda on the way there
Just my 2 cents on the whole ported vs. native discussion, for what it’s worth:
I don’t think ported applications are inherently bad for Haiku, and as @Begasus pointed out, ported libraries and programming languages (remember, also gcc is a port) are vital also for native application development.
The problem is not that we have too many people porting applications, but rather that we have too few writing or (contributing to) native apps. I propose a quite simple solution to this: Everybody that complains about too few native apps and hasn’t already written one, starts doing so . It doesn`t necessarily always have to be C++, there is also YAB (a BASIC dialect) which has bindings to the Haiku API and a small but quite active developer community. Too bad that the python bindings seem to be unmaintained and are not available as package. Would be great to see python as a top tier language for Haiku app development.
If you really wanted, you could implement statistics in your app (with the appropriate processes to let the user know that you’re doing this etc.), but I don’t think system-wide statistics is a good idea - it would be an unpopular idea.
Some other alternatives are just asking your users directly for feedback, either through here on the forums, in the Third-Party Development IRC channel, providing your contact details (a feedback form or email address in a “Feedback” section of your app), or prompting users to complete some sort of survey. That way you don’t just get quantitative data, but you also get some great suggestions from your users.
It would be better to start a own project instead of shouting, i want this and that. We have many languages available, some easy to learn too. Languages like yab, egsl, python…
My main motivation is my interest. Haiku is a “hobby OS” and in such cases, interest is the main driving force. I don’t need to research user needs and collect statistics because I’m not going to sell my product. I do everything solely for myself, and then (if it works, of course) give it back to everyone.
I don’t understand this at all, getting rid of file extensions is a good thing, our mime types for differentiation are much better (and actually allows you to remember the mime type of files you get from the web or mails)
Exactly that’s the point. This is the current situation now, and the creator of this thread/post complained about that too little native apps are created. And I gave one idea, what could be done for developers to be more attracted to develop native apps.
Yes, the down side is: you need to set up an own server, making a secure connection, creating data bases, this is work that many are not very comfortable with, and the other disadvantage is: If I collect data, it’s only for me, the others don’t have access to it to use it. But if it is done system wide, by haiku, it could be public information accessible to everybody and the collection and evaluation would be done the haiku, which you trust more than a 3-rd party developer.
You know how annoying this is to users (and how many are just not answering to question, and even if they do, it is usually not very reliable information).
I meant more flagship applications, flecks (there are a lot of small apps). There are no applications that would, for example, interfere with the development of the Haiku toolbar and gui.
It’s a storm in a glass of water, I understand there are developers from Haiku who fix the bugs of the system. We need users who program and can think creatively while creating native apps.
If you want to be spied on,you can simply use Windows or Android.
Haiku is here to make things better,and violating the privacy of users is no improvement.
Yes,it would be cool to have more native applications,but if that is the price,then it’s too high and I’ll rather stay with ported stuff.
The developers of the system can not be the same people making apps at same time.
There are some people around, making new stuff and other one try to port. I do not see a problem here.
Developers from outside, coming to haiku, want to make there available apps working in haiku too. So these are ports too. Ports are not a bad thing.
If you have an idea for a native app, you can try to do by yourself or found someone doing it. It is not the right way to say we need more native apps, without doing something by youself.
And many people do that they can do. If someone is good in porting apps and games, why he should do that not?
You can help making haiku more popular, so we get more users. More users, more ideal, more apps.
It really isn’t. Countless times I’ve had video files be detected as audio or text files in Haiku, even though I can open them in a video player and see that they are video files. A user also doesn’t necessarily want to open .txt, .ini and .cue files with the same program even though they are all technically text files.
So with MIME type based file type detection, you have to use workarounds like using a launcher or opening the program first and then opening the file that way. Simply double-clicking a file in the file manager becomes a lot less reliable and less flexible.
Case sensitivity is a major source of confusion and false bugs. To a lot of people, “A” and “a” are the same character and casing is often ignored entirely in casual conversations. With case sensitivity, you get situations like not being able to find a file because you searched for “door” instead of “Door”.
Or a program might expect a file with a certain name to be present, and then a user will report a “bug”, only to find out that the file had a capital letter somewhere. Search engines online also understand this problem and they are all case insensitive.
That’s not a solution. You can’t have a database of every single file type in existence and have it work 100% all the time. There are just too many different file types out there. It also takes away power from the user, because it turns an issue (wrong program associated with a file) that the user can otherwise easily solve himself in 2 seconds, into something that he needs to report to developers - who “might” fix it in a few days, weeks, months or years.
