PC-BSD Rolls Into A Rolling Release Distribution

[0xBADCODE]

http://www.freebsdfoundation.org/donate/sponsors.shtml

I think you're well aware this list is laughable if we'll compare it with Linux. So BSD fanboys are traditionally crying that corporations don't pay enough attention to them. And as for me, there are too much entities I dislike. Proprietary guys who never guives back. Or, for example, DRM f...ks like Netflix. It's so double-standard to give a project some bucks in one hand and then deny access to their own DRMed video service on other hand by using MS-only techs which BSDs cant handle. So BSDs are placed at disadvantage as desktops. Once more. Thank you Netflix, lol! Just as usually, those proprietary nuts are smiling in your face and give some bucks when backstabbing you. Sure, such impressive exercise in double standards is truly worth of epic tales and songs XD. Giving donation while f...g up as desktop is a really impressive combo!

[Vim_User]

Hey, CthuIhux, (the fake one, not the real one), evading the questions and trolling around?
I know that you are somewhat slower than other people when it comes to comprehension and thinking for yourself, so I will repeat it for you:

Is there a valid reason you used an already existing username, slightly modified in a way to resemble the look of the username?

Hey, what is with this one:

essentially most of the BSDs projects are a nothing more then a very bad stand up comedy. For example, thier BSD license

I asked you already in one of your prior incarnations, I think you was the guy with the anal fixation back then, to remove all code with permissive licenses from your systems and look how it works out for you. Have you tried this yet?

Oh, and this one:

extremely bad system design

Show us your expertise, come up with the design flaws in BSD, show us your analysis of the design, not something you have read somewhere on your antiBSD blogs and are now mindlessly repeating.

[TestingTe]

The BSD fuckers put google up there to fool people into thinking that even open source companies support them.

Google *does* use some FreeBSD coding (albeit not much)

You see, right now AMD GPUs support in FBSD appears to be real crap.

intellivision is right. If you'd been keeping up with Phoronix you'd know that KMS support *is* being worked on for AMD cards.

That said: I have an ATI Mobility Radeon X1300. Performance in FreeBSD is almost as good as it is in GNU/Linux. BUT!! I can still boot into the latest FreeBSD kernel and get full 3d and resolution. If I try in Linux's latest kernel I have to disable KMS to even boot. So I get stuck in VESA

[Cthulhux]

BSD has been always about being proprietary company's bitch (a lot similiar to a sex slave but BSD loves self harming and degration and so they enjoy it).

Hmm. Well, yes. So which Linux distribution lives without "proprietary company's" donations? Even Debian fails.

[Cthulhux]

Corporate guys would not invest men or money if they can't expect return.

http://www.freebsdfoundation.org/donate/sponsors.shtml

[0xBADCODE]

Also, (actually) FreeBSD does not really have much manpower.

Granted that BSD-based projects are nearly 10 years older than any Linux, they had plenty time to correct this problem. And in fact they had even more chances than Linux. Losing race due to crappy project management and other silly issues is not Linux fault. Yes, I think Linux is much better when it comes to project management. Good project manager is awfully rare person with somewhat unique set of skills. Such people are true legends in software world. Linus Torvalds managed to become one of these legendary guys who can actually guide their projects to success, gather adequate team, avoid pitfalls and so on. Then it has turned into a real powerhouse and corporations started to jump on board as well as it has been obvious these guys could achieve new heights.

And why should we as users care about the market?

Because... because you would have some troubles manufacturing 6-layered motherboard PCB on your kitchen. And it's not like if you can diffuse GPU IC yourself anyhow easily, isn't it? So you can't completely disregard market situation at this point. This approach has turned against BSD guys. You disregard market. Market disregards FBSD. Crappy hardware support is one of immediate outcomes. Lack of manpower is another one. Corporate guys would not invest men or money if they can't expect return. And granted such a crappy project management they surely can't. Or to be exact, Linux just happens to be a better bet. Welcome to real world.

[0xBADCODE]

So, what exactly is it that UFS2 lacks that EXT4 has?
Specifics please, not buzzwords, and correct spelling. Wow, you're even worse than that BSDbullshitDistro and SolarisCrap guy.

Virtually all modern filesystem designs switched to using so called "extents" (see Wikipedia to get basic idea). Basically, extent is a compact metadata record on FS which allocates large contigiuous area of disk space when filesystem attempts to execute requested write operation. This technique considered to be a major improvement over previously used block-based allocation techniques where each block is explicitly marked as used, etc. Because of one-shot allocation of relatively large areas it's fast and potentially reduces fragmentation compared to block-by-block allocation. You see, disk devices are large these days. So there are many blocks. Dealing with each and every block on it's own becomes major bottleneck. As a result, better techniques were invented. And nearly all modern designs switched to "extents" allocation techniques for speed reasons. Even old-school ext3 has been seriously reworked. Though well-thought designs without very old heritage (like JFS, XFS, ...) were faster to implement these techniques. So they in fact were outperforming ext3 in many workloads. So this caused strong competition to EXTs. And EXT4 has been an answer to this "pressure". You see, ext4 really beats ext3 to a hell in terms of speed on almost all workloads, especially when it comes to dealing with large files. Because extents are faster for quite obvious reason. But BSD guys lacked manpower to do such a major piece of job like ext3 to ext4 rewrite required. This is serious change in some basic ways of handling allocation. It requires quite a lot work to rewrite things and it unlikely to retain compatibility because of inherently different ways of doing the same things. BSD guys told they don't have manpower to do this job. This could be somewhat right, sure. But at the same time BSD guys wasted lot of manpower on some generic journling subsystems. Fundamental solutions for "any" filesystem without journal to get journalling abilities. Ironically it has been a waste of time. Only UFS2 uses these "achievements" and since it's slow and old design, it's still crap from user standpoint.

Then we come to next page in filesystems history and stuff like journalling. It has turned out that classic filesysterms are tradeoffs in engineering, again. In classic journalling filesystem design if you want full journal, first you commit data+metadata to journal area. This is "transaction intent". Then you transfer them to main data area. This is "transaction commit" (the similar notion also used some databases). If system crashes when "transaction intent" is not completely written to journal, it's completely discarded and it's rather "rollback". "All or nothing" principle returns "nothing". Filesystem is going to old state. If crash occurs after whole "transaction intent" is in journal, system will be able to complete crashed write using data from journal. Filesystem goes to new state, transaction completes. "All or nothing" returns all. This is basic theory. It works for databases and so on. But there is one major annoyance: in this ideal approach data have to be written TWICE. One time data+metadata go journal and another time they go to main area. Needless to say it haves huge write speed penalty. So actual filesystems are usually don't do things like this. They journal only metadata this way but not file data. As a result upon crash filesystem state is logically correct either way. However ... it's not applied to file data. It's possible to have half-old and half-new file in this way. And since there is no data in journal area, there is no way to complete partially written transaction for DATA. Only metadata would be correct. It saves a lot of time on fsck but does not really warrants files integrity and predictable states on crash. This is major problem of classic jornalling designs. In fact it's quite a bad tradeoff. Either you have poor write speed or sometimes you can face bad files.

Some bright heads invented really bright thing with all these journals: let the whole filesystem area to be "journal". No dedicated main data areas. So no commits to that area. No double writes. No speed losses. Problem solved! And it still retains full journalling properties: if write crashes, crashed record completely discarded. Filesystem is in old state. If write completes, record is here and filesystem in new state. And let overwrites not to destroy old data but hit new place instead. Then actual state of file is composed from the chain of logs (or equivalent structure). Hence it earned it's name: Copy On Write. This design copies written data to new place instead of rewriting them on old place. Yet another page in filesystem design history has been written. New designs started to appear. So called "log structured", "version-based" and other similar subflavours of technology started to appear. Some DBs also adopted this approach for similar reasons. ZFS has been one of early implementers of this technique. And you see, this technique really different. Ironically, generic journalling things from BSD guys never expected this kind of designs. They were meant for classic filesystems with classic journal approach or no journal. Ironically enough ZFS does not needs any kind of such subsystems and does CoW on it's own. Most new filesystems designs recognized that it could work better and adopted this approach. This way of doing things also makes it easy and straightforward to implement snapshots. Such filesystem inherently keeps multiple states. To travel back in time this design just have to ignore log records newer than X and voila - you can see pre-X state of things. Easy and cool. So snapshots are native part of this design. Sure, there are some drawbacks as well. It increases fragmentation and requires quite complex garbage collector to prevent volume from being filled by infinite older versions of previous states. But overall design is quite promising and most new designs usually center around CoW techniques.

So you see, FBSD guys essentially solved journalling problem in complex, generic ways. Only UFS could use it. And it has turned out not to work for newer CoW based designs which are quite custom and benefit from custom ways of doing journal-related things themselves.

Result? Awesome amounts of manpower wasted with almost zero user-visible results. Epic fail in project management, guys.

Also, AMD KMS support is being worked on

Standard bsd fanboys mumblings. The only problem is that I need working computer here and now, not "maybe some time later". And if you remember Nvidia, oh, lol, there is no driver for Tegra SoCs. Ha-ha. Nvidia only released blob-only drivers for some Linux distros and android. Effectively locking out BSD guys out of mobile markets. It's really laughable when someone moron logic backfires and applies to it's proponent itself in most unpleasant ways you can have. Sure, you guys truly deserve this fate. It's perfectly fair to my taste after all your crappy fanboy mumblings.

and will ship with FreeBSD 10, which isn't really an issue since most people use Intel or Nvidia chipsets these days anyway.

That's what I call "crappy hardware support", actually. Either systerm supports my current hardware here and now or I have a trouble on my way. It's amusing how stupid fanboys could fail to understand such a simple things in their blind rage. The only epic fail is that you fail to understand that my GPU is 3 generations old. It's not actively manufactured at this point and stocks are mostly sold out. It's EOL device. And you only starting to write support to get it working? You guys are so blazing fast with your hardware support thar I could not describe it with my words!

[Cthulhux]

Also, (actually) FreeBSD does not really have much manpower.

And why should we as users care about the market?

[intellivision]

Nope, I don't. You see, right now AMD GPUs support in FBSD appears to be real crap. So if you happen to have more or less recent AMD GPU, it's likely to be very crappy experience. Sure, you can find some ancient Linux to beat it. But why BSD guys always try to compete with some crap and weaklings? Come on, market does not needs losers and weaklings. Can't you get this simple thing?


Nope, I don't. I've seen in their mailing list how they developed it. They told they don't have resources for major disk structures overhaul due to lack of manpower. So UFS2 is almost the same as UFS in terms of actual on-disk structures. It even lacks extents. While EXT4 got those. Just as each and every modern design around. Sure, it required major disk structures rework and partial loss of compatibility. But at least Linux guys could afford enough resources to rework their ancient block-based allocator to extent-based allocator. This in fact dramatically speeded up EXT4 over EXT3 on modern volumes, files and most workloads. But BSD guys proven once more they're pathetic losers. Instead, they rather created very generic jornalling subsystem. Sure, idea itself it not so bad in theory. But it took awful time and effort to implement that. And at the end of day only crappy and ancient UFS could use these services. So while UFS2 does not needs fsck on every crash, it's still slow and antique design inside. And virtually every benchmark shows it's crappy nature. You can't fool laws of physics after all. And LOL, ZFS is CoW-based design and it simply does not uses or needs such services as it does journalling equivalent on it's own. Guys created cool generic solution for ... one defective and old filesystem! Bah, that's impressive!

No, honestly, it's absolutely amazing example of how people could waste so many manpower with so little user-visible results at the end. Quite the same with clang replacement, etc. In fact it's a decent example of really poor project management.

So, what exactly is it that UFS2 lacks that EXT4 has?
Specifics please, not buzzwords, and correct spelling. Wow, you're even worse than that BSDbullshitDistro and SolarisCrap guy.

Also, AMD KMS support is being worked on and will ship with FreeBSD 10, which isn't really an issue since most people use Intel or Nvidia chipsets these days anyway.

[0xBADCODE]

1. You mix up Linux with some of its distributions. To be fair, you should consider comparing it with PC-BSD.

Nope, I don't. You see, right now AMD GPUs support in FBSD appears to be real crap. So if you happen to have more or less recent AMD GPU, it's likely to be very crappy experience. Sure, you can find some ancient Linux to beat it. But why BSD guys always try to compete with some crap and weaklings? Come on, market does not needs losers and weaklings. Can't you get this simple thing?

2. You mix up UFS with UFS2.

Nope, I don't. I've seen in their mailing list how they developed it. They told they don't have resources for major disk structures overhaul due to lack of manpower. So UFS2 is almost the same as UFS in terms of actual on-disk structures. It even lacks extents. While EXT4 got those. Just as each and every modern design around. Sure, it required major disk structures rework and partial loss of compatibility. But at least Linux guys could afford enough resources to rework their ancient block-based allocator to extent-based allocator. This in fact dramatically speeded up EXT4 over EXT3 on modern volumes, files and most workloads. But BSD guys proven once more they're pathetic losers. Instead, they rather created very generic jornalling subsystem. Sure, idea itself it not so bad in theory. But it took awful time and effort to implement that. And at the end of day only crappy and ancient UFS could use these services. So while UFS2 does not needs fsck on every crash, it's still slow and antique design inside. And virtually every benchmark shows it's crappy nature. You can't fool laws of physics after all. And LOL, ZFS is CoW-based design and it simply does not uses or needs such services as it does journalling equivalent on it's own. Guys created cool generic solution for ... one defective and old filesystem! Bah, that's impressive!

No, honestly, it's absolutely amazing example of how people could waste so many manpower with so little user-visible results at the end. Quite the same with clang replacement, etc. In fact it's a decent example of really poor project management.