Live data from Hacker News

FreeBSD Device Drivers Book

github.com

31–40 of 47 posts

Re: FreeBSD Device Drivers Book

#31
post #7

Earlier quoted context omitted.

Even if it was, the author is not a random person and is part of the FreeBSD team and I'd rather trust them to write the book than someone else outside of the organization. So I would expect that they would thoroughly check the book for inaccuracies, errors and issues before releasing it after proof-reading, otherwise it would say a lot about how they use LLMs and not checking over it would hurt their own reputation.

I guarantee they didn't read a single word of this book. Look at the introduction to C and tell me that a) it's a good introduction to C b) a human read any of it https://github.com/ebrandi/FDD-book/blob/main/content/chapte... This book is a dishonest AI scam.

I'm not reading that whole thing right now (that is a lot of text), but I read as far as "What Is a Variable?" and nothing stands out as bad or AI-written. What problems do you see?

Re: FreeBSD Device Drivers Book

#32

Earlier quoted context omitted.

There is nothing wrong with using an LLM so long as a human takes ownership for the artefact (be that books, code etc). I would rather the author automate the mundane and focus on conveying their ideas clearly. As an aside, is there a Linux version for this ?

There is something wrong with it because LLMs are really not capable of writing a useful book, and this book is 100% LLM slop. Look at this totally useless """introduction""" to C: https://github.com/ebrandi/FDD-book/blob/main/content/chapte... First of all this is an entire book, it's 76,000 words. But look at the first nontrivial example of C after "hello world," under "Bonus learning point about C return values" e…

> I assume Brandi is just trying to make a quick buck,

By publishing a free book without even a way to donate?

Re: FreeBSD Device Drivers Book

#33
post #20

My exposure to FreeBSD has been mostly through routers and firewalls, plus reading about jails and finding the concept genuinely impressive. Always wanted to dig deeper but the existing material assumes you already know the things I was hoping to learn. A book that explicitly starts before that wall sounds like exactly what's been missing. Going to give it a real shot.

For me, boot environments are the killer feature. I think it's the only mainstream OS to really support the concept. Void linux (which is great) and (probably?) the Illumos distributions are the other open source choices, but those are much more niche. Or you could bolt it on to another linux distro using ZBM, but then you're on your own. Every update I clone the current boot environment, execute it as a jail, run up…

> For me, boot environments are the killer feature. I think it's the only mainstream OS to really support the concept. Void linux (which is great) and (probably?) the Illumos distributions are the other open source choices, but those are much more niche. Or you could bolt it on to another linux distro using ZBM, but then you're on your own.

I think (Open)SUSE does something similar using BTRFS snapshots. But yes, ZFS-backed BEs are the best IMHO:) OpenIndiana still does them, of course, but yeah that's sadly niche.

Re: FreeBSD Device Drivers Book

#34

Earlier quoted context omitted.

There is nothing wrong with using an LLM so long as a human takes ownership for the artefact (be that books, code etc). I would rather the author automate the mundane and focus on conveying their ideas clearly. As an aside, is there a Linux version for this ?

There is something wrong with it because LLMs are really not capable of writing a useful book, and this book is 100% LLM slop. Look at this totally useless """introduction""" to C: https://github.com/ebrandi/FDD-book/blob/main/content/chapte... First of all this is an entire book, it's 76,000 words. But look at the first nontrivial example of C after "hello world," under "Bonus learning point about C return values" e…

[deleted]

Re: FreeBSD Device Drivers Book

#36
post #20

Earlier quoted context omitted.

For me, boot environments are the killer feature. I think it's the only mainstream OS to really support the concept. Void linux (which is great) and (probably?) the Illumos distributions are the other open source choices, but those are much more niche. Or you could bolt it on to another linux distro using ZBM, but then you're on your own. Every update I clone the current boot environment, execute it as a jail, run up…

> For me, boot environments are the killer feature. I think it's the only mainstream OS to really support the concept. Void linux (which is great) and (probably?) the Illumos distributions are the other open source choices, but those are much more niche. Or you could bolt it on to another linux distro using ZBM, but then you're on your own. I think (Open)SUSE does something similar using BTRFS snapshots. But yes, ZFS…

A Brief Word About Btrfs A fair-minded reader will point out that Linux has its own copy-on-write filesystem: Btrfs. And openSUSE's integration of Btrfs with Snapper deserves genuine credit. Snapper, developed by Arvin Schnell at SUSE and first shipped with openSUSE 12.1 in November 2011, creates automatic snapshots in pre/post pairs around every zypper transaction. GRUB is patched to offer a submenu for booting from snap‐ shots. The rollback workflow is coherent: reboot, select the snapshot, verify, run snapper rollback , reboot again. On openSUSE, this works out of the box. The caveats are worth mentioning. Btrfs's RAID5 and RAID6 implementations still carry an official data loss warning in the documentation, a caveat that has per‐ sisted for years. ZFS's equivalent (RAIDZ, RAIDZ2, RAIDZ3) has been production- ready since 2005. Btrfs has no equivalent to zfs send and zfs receive for efficient incremental replication between hosts. And while Btrfs reached general production readiness around 2015, ZFS had a decade's head start. None of this makes Btrfs a bad filesystem. It makes it a younger one. And the openSUSE team deserves genuine credit for building what they have built. But even in the best case, the Btrfs workflow on openSUSE is a distribution-level achievement. It is SUSE's integration work on top of a filesystem, a bootloader, and a snapshot manager that are all developed separately. The GRUB integration is openSUSE-specific; other distributions using Snapper do not get the boot-from- snapshot feature without additional patching. The whole edifice is one team's excel‐ lent work within the assembled model. On FreeBSD, it is one team, one repository, one design, one release.

Re: FreeBSD Device Drivers Book

#37
post #7

Earlier quoted context omitted.

Even if it was, the author is not a random person and is part of the FreeBSD team and I'd rather trust them to write the book than someone else outside of the organization. So I would expect that they would thoroughly check the book for inaccuracies, errors and issues before releasing it after proof-reading, otherwise it would say a lot about how they use LLMs and not checking over it would hurt their own reputation.

I guarantee they didn't read a single word of this book. Look at the introduction to C and tell me that a) it's a good introduction to C b) a human read any of it https://github.com/ebrandi/FDD-book/blob/main/content/chapte... This book is a dishonest AI scam.

> This book is a dishonest AI scam.

Indeed! I read through a couple of paragraphs. Each begins with a bloated introduction where each sentence repeats same idea many times in different words. Lot's of bullets repeating same statement. That's exactly how LLM scam looks like. The whole book is full of water. It can be reduced in size by a factor of 5.

Re: FreeBSD Device Drivers Book

#38

Earlier quoted context omitted.

It's a free book, he's not selling you anything.

Being LLM slop in particular, this book cost way more of my time than it should have. It really does look superficially competent, until you realize that competence is paragraph-to-paragraph, not section-to-section. The scam is not stating up front "this was written by an LLM and I haven't read it." The dishonesty is claiming this book will teach you such-and-such when the author actually has no idea. It really is a…

> This book has negative value. It is actively destructive to FreeBSD, even if in the short term it boosts the author's public profile.

I won't be that radical, the book still has value. There are many useful code samples with descriptions and explanations of concepts I did not know before. But to get to them one has to dig through a forrest of useless tokens. Someone has to pass it through an LLM and publish distilled edition. :-)

Re: FreeBSD Device Drivers Book

#39
post #29
post #14

Earlier quoted context omitted.

Quite common back when books were the main learning source.

Much nicer than the current approach of throwing you in the deep end and expecting you to already know everything the author does.

I think I know quite some things about OS internals, but not that much as a guy how writes device drivers daily. Would happily read such book to get in par with the author.

Re: FreeBSD Device Drivers Book

#40
post #20

My exposure to FreeBSD has been mostly through routers and firewalls, plus reading about jails and finding the concept genuinely impressive. Always wanted to dig deeper but the existing material assumes you already know the things I was hoping to learn. A book that explicitly starts before that wall sounds like exactly what's been missing. Going to give it a real shot.

For me, boot environments are the killer feature. I think it's the only mainstream OS to really support the concept. Void linux (which is great) and (probably?) the Illumos distributions are the other open source choices, but those are much more niche. Or you could bolt it on to another linux distro using ZBM, but then you're on your own. Every update I clone the current boot environment, execute it as a jail, run up…

That's a really compelling workflow. On the Linux side I've heard of openSUSE's MicroOS doing something conceptually similar with BTRFS snapshots and atomic transactional updates, though I haven't actually run it. Different mechanism but it sounds like the same instinct. Never let the running system get into an inconsistent state during an upgrade. The "boot just once" plus jail-the-clone-to-upgrade combo you described sounds genuinely clever, hadn't realised the bectl integration was that smooth. Void Linux is just a name to me at this point, might be time to actually look it up.
Post reply on HN