Wait, what the fsck is going on? I don’t remember making this topic. The first post in here was a reply to someone else’s comment in a different topic.
I took the liberty to move this to a new thread, as it’s off-topic for “What apps do you need on Haiku?”. Makes sense to distinguish apps fromt he system.
If you ask me, the comment that I replied to originally should have been moved here as well to add context to my reply. I take it that all comments from the prior thread that are more related to this topic will also be moved over, right? In any case, I agree with your rationale for moving this to somewhere else.
You’re probably right. Though he started off with discussing apps and wishing for LaTex, so I figured that you’re quotes caught the gist of his system ideas. But now that another user has replied to that post referencing the login screen idea, I’ll move those post here as well. No idea how the forum software will handle that… we’ll find out. 
It wouldn’t be “layerception” as Haiku effectively has no hardware acceleration layer and the Linux one would become the native one via the FreeBSD wrapper which compiles down to a native single layer as the compiler is smart enough to inline everything.
So in theory performance should be as good as the equivalent version of Linux. 4.17 is what FreeBSD has parity with currently.
The same is the case with the Ethernet and Wifi layer we have from FreeBSD, they are effectively native drivers.
I think everything I want is here minus a few things I’ll discuss later. Emacs, Qupzilla (need to get Falkon!), LibreOffice, an IRC client, package manager, a PDF reader, and some media player applications.
What isn’t here as of Beta 1:
-
A full featured LaTeX editor. I write a lot of scientific documents and I need LaTeX for quick preparation of high quality documents.
-
A login/session manager. I really need something that can remember my previous working state and restore it upon logging in again. This supposes something else I’ll discuss in a moment.
What I really want are features - suspend/resume functionality, overall system resiliency, automatic power management (kind of there already minus a few things), and perhaps most importantly, hardware acceleration.
On another note, I am looking into designing a simple login manager for Haiku. What features would the users here like, and what would you all require before you would use such a program?
Basically, this would be perfect for me:
-
Simple logon screen, with just the OS logo, username and password, like on Windows 2000:
http://www.labtestproject.com/files/win/images/w2kinstall/w2kpro/031-logon.png -
Simple way to change password or whether the user wants a password to be required at all
-
Ability to configure the system to skip/auto log on, for setups where this kind of security isn’t desirable
I don’t think that it is a good idea to start thinking about logon screen designs just yet; multi-user support is planned for beyond R1. The most that would make sense would be a simple dialog with just a password box for (very) basic security at boot and after screensaver. BTW, feature requests should be made in this topic instead since this one is about requested apps.
Wow, this is going to be one confusing topic to read for others not already in here. 
I’m curious as to why the decision was made to adapt/port FreeBSD’s Linux network driver compat layer in lieu of only using it as a reference for creating one made specifically for Haiku. I can think of a few reasons for and against both approaches:
Former:
- Lots of testing already done from FreeBSD devs and users
- Less time required to accomplish it (?)
- May incur performance lesser than native due to the translating involved (Linux -> FreeBSD -> Haiku)
- Less support than Linux
Latter:
- Possibly better performance due to less translation going on (Linux -> Haiku)
- Hardware support would be practically equal to that of Linux
- More time required (?)
- Less testing
Just a heads up, there is actually experimental multi-user support with a login dialog and all, but it’s not built in by default, and of course, it’s very experimental.
You don’t seem to understand…
The ported FreeBSD layers are native period. There is nothing Haiku would have really done differently here of significance.
Technically you could write the drivers in C++ but to no real advantage.
There is no performance penalty to using the compat layer as once compiled there is no layer it compiles away to nothing (Edit: on performance critical paths anyway there may be some mon inlinable stuff still). There is no translation going on at runtime.
Using the FreeBSD / Linux drivers as reference only would likely only mean more work… And worse performance due to far fewer people working on it.
1 Like
Alrighty, then.
If the FreeBSD network driver compat layers allow Haiku to use Linux drivers, then how come not all of the NICs and adapters working on Linux function in Haiku. For example, Broadcom drivers on Linux have support for BCM4313; however, Haiku doesn’t despite using the same drivers with the FreeBSD compat layer. I am sincerely curious to know the answers to this.
Because that isn’t what it does!!?
The network compat layer is for FreeBSD drivers on Haiku it has nothing to do with Linux. With some work other BSD drivers can be ported to it also as all BSDs try to work together a little on this.
The graphics acceleration layer would be porting FreeBSD’s Linux graphics driver wrapper to Haiku. And I’ll mention this again when written properly these layers exist only in code… And all the translation between Haiku FreeBSD and Linux goes away when compiled.
FreeBSD has it’s own network driver subsystem but is adopting Linux’s graphics drivers with source level compatibility…
If you see performance difference it probably comes down to how functionality the driver uses performs differently between the two systems.
Ooooooooh, now it makes sense! 
I think I was getting confused with the various FreeBSD compat layers being used/planned to be used. 
Dang, egg on my face.
Speaking of driver wrappers, would it be possible to integrate some of the work done on ndiswrapper to get Windows network drivers working in Haiku? This was the stopgap measure for Linux until more networking hardware support came their way.
1 Like
Theoretically… But ndis is buggy anyway and only works on x86. Probably not worth the time/effort these days when most of the time you can swap your WiFi card to a nice working one.
A big difference is ndis on windows isn’t open source… So it was written half blindfolded. Whereas a driver wrapper developer for FreeBSD has all the code to look at right there.
Also ndis actually is a translation layer at runtime since you can’t recompile the driver side of things. So won’t perform as well.
Also with ndis I’ve seen people using it on Linux for wifi adapters that had perfectly working Linux drivers…so it can cause confusion.
you can swap your WiFi card to a nice working one
Not with devices like laptops and netbooks, you can’t. The only exceptions that I know of are older models with ExpressCard slots; the problem is that said cards are almost nowhere to be found these days. USB WiFi adapters exist, but those are usually some subpar hardware that barely works even in Windows. Are there any other possible stopgap solutions to filling in the holes in Haiku’s network adapter support?
Modern laptops use mini pcie cards… Every laptop own and even one desktop I have has a swappable wifi card it’s just inside similar to swapping ram.
The only devices you’ll find that may not have swappable cards are tablets and I bet even alot of those have them. About the size of two quarters.
1 Like
I can tell you right now that there really are laptops that don’t use mini PCI-E cards for WiFi. My main machine (an ASUS laptop) has a weird way of connecting the WiFI card to the motherboard. It connects using some kind of wire with one end that snaps into a receptacle in the mainboard. And my main laptop is three years old now, so it isn’t one of those newfangled Ultrabooks where many components are soldered.
It doesn’t; FreeBSD’s Linux compatibility layer does not run under our FreeBSD compatibility layer, and there are not any WiFi drivers that use this feature in FreeBSD anyway.
The BCM4313 is supported by a native FreeBSD driver, not a Linux-ported one. The reason I haven’t attempted porting it to our FreeBSD layer is its use of some weird Broadcom-specific busses that will be a pain to get wired into our compatibility layer correctly.
At this point, I’m pretty close to abandoning this approach; FreeBSD’s code here is just a huge mess and not worth that effort. I’m looking at OpenBSD’s drivers instead.
This is also not true. For the most performance-critical functions, most of the wrapping is inlined indeed; but there are still wrapper functions which would be wrappers of wrappers.
There are actually some FreeBSD network drivers dependent on the Linux compatibility layer (some strange 10Gb Ethernet drivers, not anything WiFi related, but still.)
1 Like