Like everything I post related to Technology, nobody will listen to me, so this time probably won't be any different.
What is the biggest Problem for different Kernel/ Operating Systems to gain traction?
Easy, it's drivers.
Linux is popular because it supports more hardware than anything else free software has to offer. But where is the problem if it's source code is open and avaible?
You have to understand the inner workings of linux, it's interfaces and that's not something many do. Even if they learn it, with all the time invested they'll probably just stick with it and stop bothering about anything else.
I have no idea how feasable this is, but how about creating a "Universal Driver Descripting Format" something that describes hardware, interfaces and quirks in a fashion so this file can be used to generate a driver/module for any kernel no matter whenever it's written in C or GayLang2.
What is Device Tree? On the surface it somewhat seems like to fit the bill, but I'm pretty fed up with it. I had an out-of-tree source of an ARM based tablet, I can no longer use because board-files got replaced by DT. It was said to merge ARM stuff and keep it simply but that wasn't the case at all. You again have to have a DT file for each Board and.... forget it....
What I wanted to say, one such a Universal Driver Descripting Format has been designed, Linux drivers could be translated to it. Maybe by programmed extracting tool (I'm sure someone could come up with one) or something.
Hmm, after re-reading the name is sound a lot like Universal Hardware description format and I think this already exists. Too bad we most often don't know enough about the Hardware to make this happen.
Levi Wright
having drivers obscured and locked into the eco system is part of the plan.
Samuel Cruz
Couldn't a hypothetical new kernel implement Linux's driver API to run Linux drivers? IIRC, they wanted to do this with Genode. Maybe even run whole Linux as a module, with fake virtual drivers for everything that's not going to run with Linux drivers, but I imagine that's gonna have a good overhead.
Ian Green
Your CPU itself has many layers as well, the intel management engine even has an ssh-server running (cia-nigger backdoor)
Jeremiah Allen
that has been done but linux kernel changes the api with each new version, so you'll either be stuck with one specific linux version or you'll have to re-write it each time.
Brandon White
I think the easiest way to gain traction is to limit your focus to specific hardware. Like one or a few sbpc's. That way you can larp as Be Inc. without getting bogged down in hardware.
Luke Taylor
The solution is not a way of managing the useless abstraction that is the driver model but rather to get back to directly programming the hardware.
Colton Thomas
That has also been done before. Once it support is completed, it's outdated hardware is either broken or not longer avaible on the market.
Any "community" hardware project always ended in either:
"Oops, it failed. Thanks for the donations though. Had nice vacation because of it, hehehehe"
or
"There it is! Just like promised! Don't mind those properitary driver blobs we added, there is absolutely nothing suspicious going on, hehehehe".
or
"Yeah, after 10 years of development we present underpowered and artificially limited thing and it only costs you 200 times more than any comparible hardware on the marked! Well, freedom has it's price, hehehehe".
So I'm not against concentrating on specific hardware but if it's comercial/ china or something it usually will imediately be taken from the marked once it's pried open for freedom.
Joseph Clark
...
William Martin
Which is why the plan needs a dick in its mouth. couldn't find dickinmouth.webm. Enjoy this instead
Just target something like the sjwPi. Since you can still get the first one so they have reasonably support, and everyone has one gathering dust anyway. You still have the blobs to deal with though on some boards. But since the community is so massive, there is at least some effort exerted on getting rid of those blobs. At least when you compare it to generic chink board 658.
Alexander Morgan
we dont give a fuck nigger everything is shit otherwise id be using it and writing my own drivers and software if i have to
Eli Gutierrez
I've been looking for an ARM board to replace my laptop and looked into this one because someone here mentioned (months ago) that it was possible now to boot it without their firmware blobs. Only thing I found is this: github.com/christinaa/rpi-open-firmware And it doesn't handle video output or USB, among other things, and it doens't look like this project is going to get far anytime soon, becuase the author gave up after finding out that Broadcom "cut corners" and thus the board was unsuitable for whatever purpose they had in mind. Anyway, Broadcom is a big shit company that likes to make life hard for open source people who have to reverse engineer their devices. And the RPi itself is manufactured by an SJW-friendly company. So it's kind of a bad situation all-around. Instead, you might want to look at the hardware suggested on this site: linux-sunxi.org/Buying_guide Particularly the Olimex stuff seems interesting because it's the most open design, and the release all their own documentations for everything. See here: linux-sunxi.org/OSHW olimex.com/Products/OLinuXino/open-source-hardware This also addresses the issues raised about cost and availability. Quite simply, if you click one of their OLinuXino board models, like say A64: olimex.com/Products/OLinuXino/A64/A64-OLinuXino/open-source-hardware And if you follow that link, it takes you to (pic-related): olimex.wordpress.com/2014/11/27/how-long-olinuxino-with-allwinner-socs-will-be-produced-again-now-we-know-the-answer-forever/ So pretty much it looks like they can just keep making these boards for at least as long as anyone would have some use for them. Now that doesn't mean either that every component on the board is open with excellent documtation. No, that's why the Lima project exists to reverse-engineer the Mali chipset, as mentioned on the FSF site: fsf.org/resources/hw/single-board-computers But even without this finished, it looks like it's possible to run Xorg on NetBSD (via software framebuffer), and maybe even OpenBSD too. On Linux of course you can too, because they use the blob driver. Bonus: Olimex is a bulgarian company. They probably don't have a lot of SJW types over there.
last time I looked they claimed to be in favor of open hardware (they released some files too) but for that one laptop thingy they refused to make something 100% free software (even though they could have), said they don't care about that or something.
Kevin Parker
That's what ACPI does (for a specific subset of hardware and if I understand it correctly) and look how that works out. Lots of ACPI capable hardware has quirks that driver developers have to work around.
Landon Thompson
I think they just release their own board designs as open, with schematics and such. But the chips on them, they don't make those. So in the case of Allwinner SoC's, they don't own that and can't release any open drivers for it, because they don't have the full documentation to it. Only Allwinner and/or whoever makes that Mali GPU has this. AFAIK, there isn't any completely open hardware for ARM boards, much less x86. So it's a matter of degrees. The more open it is, the better for us. With that RPi shit, you can't even start the ARM cores without their blob. Or you can use that rpi-open-firware thing and start the cores but have a computer with very little functionality. None of that is interesting to me. At least I can use a software framebuffer to run a console or Xorg. Hell, I've been stuck doing that anyway with my past two laptops since one had an Nvidia GPU (T61p), and the current one was simply too new to have a driver in OpenBSD. And now that there is a working driver, the laptop is broken. So I'm getting the hell away from these laptops. TBQH, their build quality is shit now anyway, and the last good one I touched was an IBM Thinkpad (not that T61p, other ones from before Lenovo took over). But they all have the Intel botnet (bugnet?), so I wouldn't want them now anyway.
Lincoln Lewis
Why do you believe that?
Adam Brown
I think you would be better off describing the actual hardware interface more formally rather than a whole driver. How exactly you want to drive your hardware is a part of your OSs unique design. Look into interface description languages, which are used most often for rpc.
Regarding implementing drivers for a new operating system, a lot of that grunt work can be done for you using code generation based on an IDL. The interesting bits of your drivers should be new anyway, you do want something different from linux yes?
Sebastian Flores
Click on the word and they clarify what they mean.
Aaron Edwards
no idea. I can program an µC to put it's pins to high or low and that just might let some letters appear on a small LCD but once the OS abstraction layer comes, like on a PC, I have no idea what's going on anymore. It's simply going over my head.
I simply thought, drivers aren't just hardware interfaces. There is some communication going on and that's what actually makes the difference, doesn't it?
that's the reason for this thread. translate linux drivers and it's functions to something more abstract and then you have some "logic" you could implement in your own kernel and are not limited by linux design.
Brandon Russell
Hmm, they actually claim they ordered 50k at once, so I guess that settles it.
Wyatt Harris
The basic problem is that linux doesn't guarantee ABI stability. If they did, you could just write drivers as kernel modules, then create a new kernel exporting the same interface. Why doesn't linux have a stable ABI?
Brayden Myers
It probably helps too that they also produce boards rated for industrial use. With consumer-only stuff, the demand falls more quickly. But I guess the same SoCs are used both in industrial and consummer boards. It must be actual PCB and other components that are different (like maybe having more/better capacitors and whatnot).
Matthew Turner
There are already things like this for certain types of drivers, such as NDISwrapper and NDISulator, which allow the use of Windows networking drivers on Linux and BSD, respectively. I too have often thought (especially for something threadbare like Haiku), this would be the easiest approach.
I've heard it said that this is intentional, supposedly to make kernel development easier, and and to make life harder for closed-source developers. Of course, it also pushes a significant workload of bugfixing onto the shoulders of non-kernel devs due to constant unpredictable breakages.
On the other hand, Linux does have a stable API, and basically every non-Linux kernel, including all the BSDs, do have stable ABIs.
