Announcement

Collapse
No announcement yet.

PC-BSD Rolls Into A Rolling Release Distribution

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by CthuIhux View Post
    Keep dreaming, PCBSD looks like nothing more then a desperate bit by a dying project to attract more users which is clearly not working. Why?

    -Why use PCBSD when there's Linux (You can say the same for Linux and Windows but Windows is crap, proprietary and full of viruses)
    -PCBSD is FAR slower then Linux.
    -PCBSD's apps are out of date (even when compared to Debian)
    -PBI system is a headache compared to the package managment of Linux systems, literally a step back
    -PCBSD is harder to use (GUI managment tools often crash or just don't work)
    -PCBSD only works on some hardware (Only some x86s).
    -Even on the right platform, most people find that X cannot run at installation time or after installation. Sometimes, PCBSD would not even boot at all.
    -A new version of PCBSD often doesn't boot on hardware that supported an older release. (And BSD fucks claim that updating is safer on thier crap) see:http://www.youtube.com/watch?v=Jd2JwtjOohY
    -Many problems on PCBSD are due to FreeBSD but On FreeBSD fourms, they said they are not going to answer any questions on PCBSD. see: http://forums.freebsd.org/showthread.php?t=7290
    -And lost of other problems

    BSD fucks say that PCBSD is getting better. But from less bais sources, PCBSD has actually been getting worse.

    Bet no. of users on PCBSD has actually been declining thats why they have been trying to advertise more by conferences and stupid ads.
    1. Why use Arch Linux over Ubuntu? Why use Debian over CentOS? Why use PC-BSD over OpenSUSE?
    It's all a question of choice and what the user decides to be better for the task.

    2. Do you have any citations, comparisons or scope for this claim?

    3. I suppose why they have up to date Firefox, Midori and Openoffice releases just to name a few.

    4. In what sense? Because it rolls in the relevant libraries into the package rather than fetching them separately? I can see why you'd think this, but there are some benefits to that model, such as not having to worry about updating a library and breaking the programs that use it.

    5. They crash? Not in my experience, nor of the users on PC-BSD. Hell, even Distrowatch praised the tools for being easy to use and they didn't mention instability with the configuration tools.

    6. Explain in further detail, are you referring to hardware in general or CPU architecture?

    7 and 8. Could you find out what hardware isn't supported in relation to this? It would be better to state what didn't work rather than 'this won't work at all anywhere'.

    9. It's to do with support in relation to those distributions, in the same way should Debian respond to help requests from Ubuntu users?

    Also, numerous spelling and grammatical errors, probably written by a 13 year old or someone with a poor grasp of the English language and a confusingly similar username to another user on this website.
    Definitely another BSDshitdistrosucks account, trolling is weaker than ever before.
    2/10, better luck next time.

    Comment


    • #12
      Originally posted by CthuIhux View Post
      Seriously, I don't know what the hell is wrong with you and Vim_User who things that I had was I a previous account holder who's opinions you don't like cause it speaks the truth about BSD.
      Anyone with at least a few functioning brain cells (so obviously you are not part of that group) can see that your behavior and posting style totally resembles that of the infamous troll known under several different names that involve sexual content or are slight modifications of other users names.
      Is there a valid reason you used an already existing username, slightly modified in a way to resemble the look of the username? Other than just give bad credit to that user from unsuspecting or unalert members?
      I doubt so, your only contribution to this site is trolling and in that you aren't even good. Try to come up with some actual facts (not made up stuff, real facts) to support your claims instead of just insults and you may get some credibility. I doubt that you are able to do that, but we will see.

      Comment


      • #13
        Originally posted by CthuIhux View Post
        Bad analogy, you use Arch cause you have more control or you want lighter weight. You use Debian cause it's lighter and aptitude satisfy your needs. You use Linux Distro A or B cause A suits you better and has advantages that you need.

        Not so PCBSD, Linux is better alternatives for everything PCBSD has to offer ie (ZFS vs BTRFS). So theres no sane reason to use PCBSD over linux.
        So you try and disprove me by proving my original point? And in exactly to the example that you have provided, as ZFS is stable and has functioning software RAID solutions, as opposed to btrfs (which I hope will be finished in a year or two) which is in heavy development and offers no software RAID functionality.

        Yes I agree. And those how choose PCBSD are mentally insane or love self harming and should be put in a mental institute.
        Well, I'd love to see some cited evidence of that claim, because it just sounded like an unfounded biased remark there for a second.

        Right under your nose, Phoronix benckmarks Linux vs BSD
        Which ones?

        Yes PBI is a step back from linux package managment. For linux you type a command and the package is installed, for PBIs you have to go to the website, download the pbi file ones it click next 100 times and wait a long time and the program may or may not be installed.

        Also it takes lots of resources cause Kris Moor(on) the insane PCBSD project leader decided to have self contained depedencies. What a dick.
        You mean the website that has been depreciated and replaced by Appcafe? Or the text commands that are outlined here? http://wiki.pcbsd.org/index.php/PBI_...pbi_add.281.29
        Or even the reasons why I outlined why self contained dependencies might be beneficial?

        BSD has always bullshitted about thier reliability over linux and now they say they are switching to rolling release. Rolling release packages break easily thus less reliability so BSD can forget about claiming stability and relability.
        Oh, you mean that they're offering a rolling release option on top of their stable option, which is what I said before. Glad we cleared that up.

        Typical words from a BSD zealot. My solution, create an NDIS wrapper driver and load it up and see what happens.
        So you oppose the use of FOSS wireless drivers and would rather use the binary Windows ones? Good to know.

        Also, that information on distrowatch is old. All the BSDs struggle on fairly new hardware and for PCBSD and FreeBSD in particular, they may not even boot on a modern piece of hardware even though it's x86 which is what FreeBSD claim to focus on. What a bunch of crap.
        You mean that January 2013 is old? This one? http://distrowatch.com/weekly.php?is...130107#feature
        I suggest you read the review, you might want to write to Distrowatch and call out the reviewer as a BSD Zealot for his positive review
        That article also rounds up the next few points that you've made.

        Ubuntu is modified from Debian top to bottom. But PCBSD is iterally an unmodifyied FreeBSD with KDE and loads of bloated crap wrapped around it. So they have no excuse.
        You mean unmodified except the new package manager, not being synced to FreeBSD releases, including different core software among other things?

        I reviewed the post and only found two or three errors. You just have a lack of valid arguments and so to boost your credibility, claim I make lots for spelling and grammatical errors. Come back what you can debate properly.
        I have done, now it's your turn. Also, their, unmodified, management, dependencies and reliability. Next time try and remember the correct spelling for those words

        Seriously, I don't know what the hell is wrong with you and Vim_User who things that I had was I a previous account holder who's opinions you don't like cause it speaks the truth about BSD.
        Yes, of course, just the same poor grasp on the English language and inane comments, I'm sure you're different people.

        Comment


        • #14
          Originally posted by CthuIhux View Post
          All the BSDs struggle on fairly new hardware and for PCBSD and FreeBSD in particular, they may not even boot on a modern piece of hardware even though it's x86 which is what FreeBSD claim to focus on.
          Same applies to a couple of Linux distributions. So what do you use then? Windows? Or does Windows already overburden you? Hmm, OS X then? Oh, no, it's based on BSD...

          Comment


          • #15
            Originally posted by Cthulhux View Post
            Why not PC-BSD?
            Because with BSDs you can expect...
            - No GPU drivers or ancient/defective ones. Literally, FBSD lacks support for half of GPUs around. On my GPU xorg would just lock up and leave me dumb black screen. Cool, isn't it? OTOH Linux provides full plug-n-play experience.
            - Crappy wireless. Linux usually could use .n with all features. Not something that works well in fbsd.
            - Crappy choice of filesystems. I can select between old, slow and defective UFS and huge and slow enterprise ZFS. So in FBSD I can select between old grandma's bike and AirBus. No other choices provided. But hell, I usually need a car! Ext4 is exactly like this. It can work at decent speeds while not being huge and overomplicated. And for some reason Linux guys could overhaul old disk structures to give them a speed. BSD guys can't afford that. Just as usually. So UFS still uses ancient design invented eons ago. Oh, can you please tell me, what cylinder groups are meant to do on my SSD? It completely lacks notion of cylinders, lol .
            - Package management makes sense only when there are enough of maintainers to package all those thousands of programs. Something that BSD guys can't afford. Just as usually. Package management without packages is pointless.

            Comment


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

              2. You mix up UFS with UFS2.

              Nice try though.

              Comment


              • #17
                Originally posted by Cthulhux View Post
                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.
                Last edited by 0xBADCODE; 13 March 2013, 01:59 AM.

                Comment


                • #18
                  Originally posted by 0xBADCODE View Post
                  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.

                  Comment


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

                    And why should we as users care about the market?

                    Comment


                    • #20
                      Originally posted by intellivision View Post
                      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!
                      Last edited by 0xBADCODE; 13 March 2013, 08:50 AM.

                      Comment

                      Working...
                      X