BSD Hardware Database | Hacker News Reader

BSD Hardware Database

bsd-hardware.info

84 pointsvermaden65 comments

Open articleView on HN

>https://github.com/linuxhw/hw-probe/blob/master/LICENSE

What in the world were they thinking. This is now how you appeal to the BSD community.

Damn! I already executed it, my system is tainted!

It probably automatically uploaded details about your system online, before you could blink.

That's not the problem, i executed gpl2 software on a BSD-System...shame on me ;)

BSD owes GPL software a lot. I seem to recall that for a long time GCC was the only realistic compiler available.

I know, just making fun.

One of the biggest turn-offs I have about BSD is the License zealotry that runs so rampant in that community.

Oh, even more than the zealotry of Linux and ZFS?

I've only experienced "Linux zealotry" from Free Software Foundation types, and I make an effort to avoid them as well because I find it just as odious. However there's a massive chunk of Linux community who aren't interested in licensing debates and seemingly just want to get things done.

Case in point: I've been using various Linux and BSD distros off and on for about 15 years and have never experienced the zealotry you are referring to coming from the Linux side of the fence. Not saying it doesn't happen, but it seems a far smaller proportion of the Linux community is spending their time arguing (loudly, obnoxiously) about minor philosophical issues and blasting those opinions into the internet than compared to BSD.

Maybe you met the wrong people, from my PoV the BSD peoples like the BSD2/MIT/ISC/FreeBSD-License, but have no problem too import the CDDL the Apache or the GPLx (at least in the pkg), whatever works. On the other hand with Linux, CDDL absolutely NOT acceptable (hi Linus) but ultra-proprietary Firmware-Blobs are ok.

Some zealotry experience from a Linux foundation guy?

https://news.ycombinator.com/item?id=22005181

Yeah see the difference is that I just don't care about software licenses. At all. It's such an inconsequential issue that gets a small frothy-mouthed minority so worked-up that I find it baffling how anyone could spend so much time and energy worrying about.

Absolutely, at the beginning of my career i was a big fan of Stallman and the FSF, until i realized that he loves to hear himself and repeat's over an over the same stuff. What he says is the only truth and nothing else. I want cool technologie with a free license and ZERO lawyer's involved.

The proprietary firmware is in another git repository [1], there are no blobs in the mainline kernel to my knowledge. Further, distributions ship this firmware as a separate package, so it's not bundled with the kernel. This approach appears to be fairly similar to what OpenBSD does [2]. This doesn't seem too different from how the Linux community treats other licence-incompatible software such as OpenZFS.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/firmware/lin...

[2] http://firmware.openbsd.org/firmware/

Oh whait...why is then ZFS such a big problem? Just put it in a different repo at kernel.org right?

Well on the other hand, no one wants ZFS in the mainline kernel, it is perfect like it is, at least for me :)

I'm not sure what you mean by ZFS being such a big problem, the CDDL license is considered incompatible and therefore OpenZFS isn't going to be considered for upstreaming. Also, most of OpenZFS development is driven by companies that use it with the Linux kernel, so clearly there isn't that much of a problem with using OpenZFS and Linux. It's pretty similar to how the BSDs may not allow something in base due to licensing, but will allow it in ports/pkg.

If you're asking why OpenZFS is not hosted kernel.org, why would kernel.org host an out of tree kernel module that is never going to be upstreamed? Firmware on the other hand is needed to initialize and use a ton of hardware, and so it makes sense to have a central repository for vendors to submit required firmware. More importantly, why would the OpenZFS community even want to be on kernel.org when they support multiple operating systems and have also not pushed for upstreaming? I really don't think OpenZFS is being treated any better or worse than other license-incompatible kernel modules.

I just don't see how you can characterize it as zealtory any more so than FreeBSD wanting to remove all GPL'd software from base [1], or OpenBSD sticking with Clang 8 in base because of the switch to the Apache 2.0 license [2]. It's pretty normal for software projects to care about licensing.

[1] https://wiki.freebsd.org/GPLinBase

[2] https://lists.llvm.org/pipermail/llvm-dev/2017-April/112300....

Of course ZFS can't be upstreamed (anymore than assorted blobs), but Linux devs have expressed outright animosity towards ZFS: https://www.phoronix.com/scan.php?page=news_item&px=ZFS-On-L...

> My tolerance for ZFS is pretty non-existant. Sun explicitly did not want their code to work on Linux, so why would we do extra work to get their code to work properly?

Sure, but that's been Greg KH's stance on pretty much every kernel module that has no chance of going upstream [1].

"Simple, get your kernel driver into the main kernel tree (remember we are talking about drivers released under a GPL-compatible license here, if your code doesn't fall under this category, good luck, you are on your own here, you leech)."

Also in the post you are citing, the technical change makes no reference to ZFS [2] or implies that the motivation is to break out of tree modules. The upstream community simply doesn't even consider out of tree projects when making changes. Whether that's good or bad is another discussion, but I don't see anything that's specific to ZFS.

I should also note that to my knowledge, OpenZFS (formerly ZoL) was the only (open source) ZFS implementation that utilized vectorized checksums. At the very least FreeBSD's in-tree ZFS did not have vectorized checksums, as that was listed as one of the features FreeBSD would gain by moving to OpenZFS [3]. So the cited change didn't break ZFS, it just meant those checksums weren't as fast as they used to be.

[1] https://www.kernel.org/doc/Documentation/process/stable-api-...

[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

[3] https://lists.freebsd.org/pipermail/freebsd-current/2018-Dec...

>good luck, you are on your own here, you leech

Man i just love that warm, lovely atmosphere in that project..and thats not even the leader....ahem sorry dictator (and he is even proud of that)

Linux just loves good filesystems (not).

The way they are handling ZFS reminds me of the way they handled Reiser4, Tux3 and Reiserfs.

Basically, any filesystem not made by the filesystem establishment (and their friends) gets bullied. Of course, the only filesystems they can make are all crap like ext4 and btrfs.

Fortunately, there's the BSDs, and there's the likes of HAMMER2 from Dragonfly.

And, with seL4[0], Fuchsia and HarmonyOS making progress, Linux is going to fall into irrelevance, sooner than most think.

Good riddance.

[0]: https://sel4.systems/About/seL4-whitepaper.pdf

> The way they are handling ZFS reminds me of the way they handled Reiser4, Tux3 and Reiserfs.

The latter file systems were trying to be upstreamed and ultimately did not succeed, I don't know of any interest or attempts at upstreaming ZFS. Their handling of ZFS reminds me how they handle any kernel module that will never be upstream, not because some file system establishment sees it as a threat.

> Basically, any filesystem not made by the filesystem establishment (and their friends) gets bullied.

What/who is the "establishment (and their friends)"?

f2fs from Samsung was added in 3.8, erofs from Huawei was added in 5.4, and exfat from Samsung was added in 5.7. Before those file systems were upstreamed I don't think many people would list Samsung and Huawei as part of the filesystem "establishment".

>What/who is the "establishment (and their friends)"?

Maybe he thinks of Linux Foundation Platinum Members ;)

https://www.linuxfoundation.org/membership/members/

XFS is actually really good, but Linux definitely need's a check-summing COW Filesystem that's usable.

FWIW, we do have CoW on XFS, but yeah no data-checksumming other than BTRFS. Hopefully bcachefs will be the go-to option someday.

Yes true and check-summing for metadata too, but not for the data. I have bigger hopes for XFS then bcachefs (maturity and really great dev's) but hopefully not that Stratis-thing from redhat....that sound's like a terrible idea.

Writeback latency spikes and lack of data checksums is the main issue with ext4 and xfs.

Btrfs has the checksums, but is a toy.

To my knowledge, NILFS2 (by NTT) is still the best filesystem Linux has in mainline. And, ironically, practically nobody does use it.

Does NILFS2 ensure data integrity? [0] claims that it doesn't actually check data checksums, but that's from 2011...

[0] https://www.spinics.net/lists/linux-nilfs/msg01063.html

Yes it does:

https://en.wikipedia.org/wiki/NILFS#Additional_features

> the way they handled Reiser4, Tux3 and Reiserfs

Reiserfs is in-tree. Reiser4 failed after losing its lead dev, but my impression was that it was on-track to become the next Linux filesystem of choice. I have no clue about Tux3.

> Basically, any filesystem not made by the filesystem establishment (and their friends) gets bullied.

Linux has XFS from IRIX and JFS from AIX; the only way to have that and a "filesystem establishment" conspiracy is to resort to no-true-scotsman.

> Of course, the only filesystems they can make are all crap like ext4 and btrfs.

I'll agree that BTRFS is ... suboptimal, but what do you have against ext4? I'd like it to have data checksums and maybe CoW, but it's been the workhorse of the Linux world for ages and performs quite well, and even has some nice new features like encryption in recent times.

>Reiserfs is in-tree.

Yes it is, but it got bullied either way. Linux filesystem devs made incompatible changes to it against the ReiserFS teams' wishes, breaking it. IIRC it had to do with ACL support.

>CDDL license is considered incompatible

Well NO its not, that's pure FUD from the FSF:

https://zonena.me/2019/01/the-cddl-is-not-incompatible-with-...

>If you're asking why OpenZFS is not hosted kernel.org

No im asking why Linus thinks its acceptable to distribute proprietary Firmware, but needs a personal letter from Lord Elison and ZFS needs to be GPL'd....otherwise just don't use it.

>I just don't see how you can characterize it as zealtory any more so than FreeBSD wanting to remove all GPL'd software from base

That is because you can close and still distribute BSD licensed Software, but not when it contains GPL'd Software, thats why you dont want it in the Base-System, no one has something against GPL there, but FreeBSD wants to distribute a complete Operating-system under the BSD (or compatible like Apache/MIT etc) License.

> Well NO its not, that's pure FUD from the FSF:

What matters is if the upstream Linux community is comfortable enough with the license to allow it upstream, which is why I said "considered".

> No im asking why Linus thinks its acceptable to distribute proprietary Firmware, but needs a personal letter from Lord Elison and ZFS needs to be GPL'd....otherwise just don't use it.

There's a big difference between these two things. The first is redistributing proprietary firmware in a completely separate repository from the Linux source code. All firmware included in the linux-firmware repository is explicitly allowed to be redistributed [1], which is why they do not have fears about distributing those binary files.

I'll quote the readme: "If your commit adds new firmware, it must update the WHENCE file to clearly state the license under which the firmware is available, and that it is redistributable."

The second is introducing CDDL licensed code into a GPLv2 project, where that project considers the CDDL license to be incompatible, along with worries (however unfounded) about a notoriously litigious company.

> That is because you can close and still distribute BSD licensed Software, but not when it contains GPL'd Software, thats why you dont want it in the Base-System, no one has something against GPL there, but FreeBSD wants to distribute a complete Operating-system under the BSD License.

Yes the FreeBSD community does not want GPL code in the base system as it prevents them from from distributing a 100% permissively licensed system, and it's understandable why that is a goal. But how is that meaningfully different than the Linux community not wanting code with a license they feel is incompatible with their goals?

[1] https://git.kernel.org/pub/scm/linux/kernel/git/firmware/lin...

Again NO one wants ZFS being in the mainline kernel, but being openly hostile against it, but accept closed Firmware (because they have to...who is the leech now?) is not completely honest.

I've already said that the OpenZFS community is not trying to upstream it, why do you keep thinking that I'm suggesting otherwise?

You continue to conflate support for out of tree kernel modules as being similar to having a separate repository for firmware when they aren't the same thing at all. The Linux developers are not accepting firmware into the kernel at all, so there is no contradiction. The firmware is kept separate, just like OpenZFS is kept as a separate project from Linux. In both instances the user can choose to install an out of tree module such as OpenZFS as well as choose to install firmware on their system.

Furthermore it is not the Linux kernel developers that are packaging and shipping the firmware, it is the various Linux distributions who do that (or not in the case of FSF-approved distributions).

> BSD peoples like the BSD2/MIT/ISC/FreeBSD-License, but have no problem too import the CDDL the Apache or the GPLx (at least in the pkg), whatever works.

If by "BSD peoples" you mean the FreeBSD/NetBSD community, then yes. But OpenBSD devs deem CDDL to be unacceptable:

http://quigon.bsws.de/papers/2015/asiabsdcon/mgp00020.html

https://flak.tedunangst.com/post/ZFS-on-OpenBSD

OpenBSD was always different, just talking about FreeBSD.

Licensing issues are always a big problem for any community, you can look at the whole tivoization debacle for an example in the linux community specifically. Changing a copyfree project to copyleft is a huge problem. Projects deliberately choose a license that works with their business model, An upside to the copyfree model is incorporating the code into a proprietary project without releasing the code. It is of course in the best interest of the one using the code to keep it in sync and submit their patches with the open source project for security and performance reasons. But they are not forced to do so.

There are 33 computers in their database.

and 33.000 on bsdstats.org. I guess this is a new and unrelated endeavour

Can someone help me understand what's the difference works and detected?

Detected means you see a device at a certain port or address. Works means that after detection you can actually interact with the device and do things.

These survey sites tend to miss large numbers of FreeBSD machines in use in corporate environs. Eg, Netflix Openconnect CDN and similar.

idk but wager to say there are maybe a couple of thousand OC machines worldwide. not really "large numbers".

on other fronts i rekon that other infrastructure manufacturers are big on BSD (eg. dell/emc, juniper)

Yes, openconnect was just one example that I know well because I work on it, and I know we don't report to these survey sites. If we did, we would make up a sizable percent of bsdstats.org, and over 99% of the BSD Hardware Database in the title.

And I'm sure there are others (like your infrastructure manufacturers) that could say the same.

Here's a list:

https://en.wikipedia.org/wiki/List_of_products_based_on_Free...

Some of it is outdated, like Whats-app

What is the difference between this and bsdstats.org ?

Very disappointed by BSDs and FreeBSD in particular. The other day I wanted to build a pihole set-up using it - do you think it works seamlessly with raspberry pi? It doesn't. Wanted to install it on my UEFI bios - have to take more steps than I should. Wanted to run it on an nvidia jetson i have lying around. Good luck with that! Basically it only works with very common or old hardware. A shame really. I don't want to sound entitled, would have been happy to allocate time to build eyecandy apps to make it more suitable for a desktop (had an app included in the ports tree in the past), but I simply can't without spending too much time to even make it work. I wish this would change, as FreeBSD is my first "love", and for good reason - it's tidy and logically organised.

rpi and many other boards use proprietary drivers that are not open to the community. the hardware vendor makes a Linux blob and that's it. What can FreeBSD do about it?

> What can FreeBSD do about it?

That's a good question, and I don't have a clue. I know my comment sounds a bit entitled, because now that I think of it FreeBSD has provided that platform for vendors and the wider community to port drivers, or reverse engineer where possible. If i could do it I would do it myself, but I lack the skill and time. So i'll rephrase my statement: s/Very disappointed by BSDs and FreeBSD in particular/Very disappointed that vendors do not provide better hardware support for BSDs and FreeBSD in particular/. It really is a shame that such a great OS doesn't have wider support and adoption.

NDISwrapper

>...FreeBSD in particular.

Which other BSDs did you try?

Tried NetBSD and OpenBSD in the past, and had worse issues in terms of compatibility. However, I had to rephrase my comment based on someone else's comment, and based on the realization that it's not FreeBSD and BSDs at fault: s/Very disappointed by BSDs and FreeBSD in particular/Very disappointed that vendors do not provide better hardware support for BSDs and FreeBSD in particular/

NetBSD supports those boards, iirc

Indeed it does, and I've been running RPi3B+ / NetBSD for years successfully. Try it!

If you're wanting to use FreeBSD for something pihole-like, check out pfsense and pfBlockerNG.

Well... you could have tried https://www.invisible.ca/arm/ and https://wiki.netbsd.org/ports/evbarm/ along with https://www.netbsd.org/docs/guide/en/

BSD "distro"? Really?

The D in BSD is...distribution.

But there's only one distribution. Though dragonfly is a fork, it's not a redistribution.. or is it?

But "Linux" is just a kernel.

> But there's only one distribution.

No, there are BSD distros, like nomad BSD or ghost BSD, but not all BSDs are distros, unlike Linux distros.

> Though dragonfly is a fork, it's not a redistribution.. or is it?

Dragonfly is diverged enough to count as its own thing, I think.

DragonFlyBSD is definitely it’s own seperate branch of the evolutionary tree.

I think they’re pointing out the duplication in “Berkeley Software Distribution disto/distribution”; similar to “ATM machine”, “PIN number”, “LCD display/screen”, etc.

No I am not. I am saying that BSD world is not distro driven. You would not call Android or ChromeOS a Linux distro. The difference between BSDs is very serious, and they are not by any means distros. They are variants for sure, but not "distros".

> You would not call Android or ChromeOS a Linux distro.

i do.

nevertheless this debate is quite pointless

But distro comes from distribution, i think i would call Android with store a plattform, but Android without store a Distribution.

True, yes true, but it is there for entirely different reason than in the term "Linux distribution". Even more, if we follow your argument it makes even less sense, "distribution distribution". There some genuine "distibutions" among BSD, such as NomadBSD, PC-BSD etc (FreeBSD derived systems), but in most cases, BSDs are very different OSes, incompatible with each other, with very different kernels (OpenBSD, NetBSD, FreeBSD, DragonFlyBSD).

Thus redundant.

Reply on news.ycombinator.com