What is the future of the BSD?

[profoundWHALE]

@JS987
That's what I meant. I want there to be competition in the Open Source arena, but at this point, it's like we all split into different teams, all trying to beat each other and these proprietary guys who simply stayed in one piece and stayed relatively consistent.

Correction.

[randomizer]

Lots of companies end up grabbing BSD source code and modifying it for custom solutions.

How is that any different from GPL source code? If it is there fore the taking it will be taken.

[profoundWHALE]

How is that any different from GPL source code? If it is there fore the taking it will be taken.

In this particular case I was referring to the OS, like FreeBSD -> PS4 OS

But you are right that Linux can also be taken and used in such a way too like say Android, but any changes to the kernel that they made (if I remember right) would have to be made public. Some people just aren't comfortable with that.

[0xBADCODE]

You seem to have problems debating... You claimed that BSD is "failing to recognize modern requirements"; I'm providing evidence that this is not the case.

That's a way too primitive trolling and not going to work well. For example I do not see where you've told anything about package management. Ah, FBSD got package manager? Nice try. But wait, they "solved" problem? "Recognized modern requirements"? Bah, it turns out there are no repos and no packages. Then, there is still some moron crap about "base system". But of course, just 10 more years and they will get idea about metapackages.

Now, "Btrfs internals seems to be seriously superior to ZFS"... Really? Could you provide some proof about this and the other things you claim?

Some few random things I can imagine immediately:
1) Btrfs implements extent-based alolcator. So even ancient benchmarks of unoptimized version beated crap out of ZFS...
2) Sane memory management integrated with rest of kernel memory management. So it can use system memory as cache but kernel can revoke this memory in reliable way. Not a case with ZFS who in fact brings own set of memory management routines for ARC. Which is suboptimal to say the least. IIRC, this was because Solaris had no own advanced cache management so ZFS had to do it self. But it's really silly in systems like Linux/BSDs/etc who implement own cache memory management. And it looks like nobody is in mood to fix that. As it requires a lot of changes.
3) Btrfs can selectively disable CoW for certain files. Now imagine databases. Their journal logic would do same work as CoW does. This leads to very suboptimal performance. Oracle clearly got this idea and requested their architect to something about it in new design. So you can disable CoW logic per file or per subvolume. Needless to say it could be far better for databases. I'm pretty sure oracle cares. Btrfs takes their needs to account. ZFS does not.
4) Btrfs has been designed to allow easy and fast removal of devices from pool. Its damn flexible in how it places structures and can move away from device any time, granted there is enough free space on other devices. ZFS never really cared about this.
5) Fragmentation. CoW is inherently all about fragments. When file changed, CoW logic does not touches original blocks. Instead, new fragment created which contains changed data. Then metadata changed in way where they describe new version of file. Since change is not destructive, its possible to access old version as well, as matter of another set of metadata. Obviously, new version of file is no longer sequential. It's fragmented. Changed part located somewhere else. What Btrfs did? They integrated defragger to garbage collector which trashes unneeded blocks. What Sun did in ZFS? They posted marketing bullshit telling it's "not needed". Which is marketing bullshit for sure, intended for those who does not haves even basic idea WTF CoW algo is and how it works.

You seem to have some concentration issues...

Its rather you who haves very selective views, skipping "inconvenient" remarks. Somehow, Linux is being used even as desktop. And Valve even dares to turn it into gaming station. There is difference: Valve haves open ecosystem. Everyone can join and change parts of system and benefit is quite global, actually. Then we can see Sony. They have nice games and good hardware. Ironically, neither FBSD can run high-profile games, nor even it haves adequate drivers for hardware similar to PS4. Only Sony benefits. That's the main difference..

[randomizer]

But you are right that Linux can also be taken and used in such a way too like say Android, but any changes to the kernel that they made (if I remember right) would have to be made public.

If the binaries are distributed, then the source must be (undistributed binaries don't require release of source). That's what the licence says, but who cares what licences say? How many companies run illegitimate copies of Windows, or legitimate copies that have been reused on 15 different computers simultaneously? Then you have consumers who certainly don't care about licences or copyright either, though this is primarily an issue for proprietary software. The licence provides very little real protection. Nobody reads them, and few ever get caught. Proprietary, GPL, BSD, MIT, WTFPL, MPL... it doesn't matter to the real world. It's primarily those interested in politics who argue about which acronym is better.

[0xBADCODE]

How is that any different from GPL source code? If it is there fore the taking it will be taken.

At the end of day...

• If you buy device and it contains GPLed code like Linux, you can usually expect to be able to get source and actually change it to suit your needs. There are some cheats with signatures, so that's why GPLv3 appeared. But anyway, it works most of time.
• If you buy device and it contanis BSD-based sytem, you can expect proprietary firmware/OS/... to land on your head. No source. No freedom. Blobs and EULA inside.

So, with BSDs, only few huge corporations who can do full hardware development cycle and full OS porting cycle are up for using BSDs. Everyone else selects linux due to drastically lower amount of work to achieve same result. Not to mention it's counterproductive to redo already completed jobs more than once. In Linux there is code share which prevents this. In BSDs ...they always sucked thanks to proprietary forks who never release code. This is some local gain for one entity and global loss in development for a project as whole. Nature experiment shown us it can't really compete with approaches taken in Linux

[Sergio]

That's a way too primitive trolling and not going to work well. For example I do not see where you've told anything about package management. Ah, FBSD got package manager? Nice try. But wait, they "solved" problem? "Recognized modern requirements"? Bah, it turns out there are no repos and no packages. Then, there is still some moron crap about "base system". But of course, just 10 more years and they will get idea about metapackages.

This is supposed to prove your point?

Some few random things I can imagine immediately:
1) Btrfs implements extent-based alolcator. So even ancient benchmarks of unoptimized version beated crap out of ZFS...
2) Sane memory management integrated with rest of kernel memory management. So it can use system memory as cache but kernel can revoke this memory in reliable way. Not a case with ZFS who in fact brings own set of memory management routines for ARC. Which is suboptimal to say the least. IIRC, this was because Solaris had no own advanced cache management so ZFS had to do it self. But it's really silly in systems like Linux/BSDs/etc who implement own cache memory management. And it looks like nobody is in mood to fix that. As it requires a lot of changes.
3) Btrfs can selectively disable CoW for certain files. Now imagine databases. Their journal logic would do same work as CoW does. This leads to very suboptimal performance. Oracle clearly got this idea and requested their architect to something about it in new design. So you can disable CoW logic per file or per subvolume. Needless to say it could be far better for databases. I'm pretty sure oracle cares. Btrfs takes their needs to account. ZFS does not.
4) Btrfs has been designed to allow easy and fast removal of devices from pool. Its damn flexible in how it places structures and can move away from device any time, granted there is enough free space on other devices. ZFS never really cared about this.
5) Fragmentation. CoW is inherently all about fragments. When file changed, CoW logic does not touches original blocks. Instead, new fragment created which contains changed data. Then metadata changed in way where they describe new version of file. Since change is not destructive, its possible to access old version as well, as matter of another set of metadata. Obviously, new version of file is no longer sequential. It's fragmented. Changed part located somewhere else. What Btrfs did? They integrated defragger to garbage collector which trashes unneeded blocks. What Sun did in ZFS? They posted marketing bullshit telling it's "not needed". Which is marketing bullshit for sure, intended for those who does not haves even basic idea WTF CoW algo is and how it works.

I love how you conveniently (or ignorantely?) don't realize that complex systems are about tradeoffs...
What you say here, either true or not, does nothing to prove that Btrfs is superior to ZFS: Here is a Masters' degree on the subject; there is a special section comparing both filesystems: http://faif.objectis.net/download-co...d-file-systems
Note how tradeoffs in both ZFS and Btrfs implies a different set of advantages/disadvantages.

So, no... Btrfs' is not a superior design. Moreover, you can say that by design both filesystems are equivalent. But now, obviously ZFS is far more mature, tested, etc, in the real world, so that keeps me sceptical about it being effectively an alternative. With time, however, I hope it does.

Its rather you who haves very selective views, skipping "inconvenient" remarks. Somehow, Linux is being used even as desktop. And Valve even dares to turn it into gaming station. There is difference: Valve haves open ecosystem. Everyone can join and change parts of system and benefit is quite global, actually. Then we can see Sony. They have nice games and good hardware. Ironically, neither FBSD can run high-profile games, nor even it haves adequate drivers for hardware similar to PS4. Only Sony benefits. That's the main difference..

The point is that you suggested the irrelevant position of BSD on the desktop is worrying, yet somehow this does not apply to the also irrelevant position of Linux here... So no, being irrelevant on the desktop says nothing at all...

[endman]

Please refer to the last 2 boxes of this flow chart:

Only drunken people will try to waste time installing BSD.

[Truth]

You have to laugh at GPL sluts, patriot-act supporting scum that they are.

The endless FUD they spread to try and justify their removal of freedom just like the US government uses to justify the NSA/TSA.

And yet after all the claims they invent and attribute to the GPL, they go and spread the same FUD about projects like systemd - even when said project uses the LGPL! Hah!

GPL sluts get wrecked once again by my vastly superior intellect.

[profoundWHALE]

Well would you look at that, two trolls in one place. This reminds me of what's going on right now.