×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

143 comments

Hurrah? (3, Funny)

DavidClarkeHR (2769805) | about 7 months ago | (#44853515)

Year of the BSD desktop.... FINALLY!

Re:Hurrah? (2, Insightful)

geek (5680) | about 7 months ago | (#44853753)

OSX = BSD, so yeah, its been year of BSD on the desktop for about a decade.

Re:Hurrah? (1)

Shavano (2541114) | about 7 months ago | (#44853865)

Not really. OSX contains much of BSD, but it also contains lots and lots of proprietary code.

Re:Hurrah? (1)

Anonymous Coward | about 7 months ago | (#44854073)

Most of the proprietary code is interface. There is plenty proprietry code that isn't interface, but not even much of that is OS material. OS X is layered. Interface layer, application layers... and system layers. Contrary to what most believe, an interface is not an operatng system... its window dressing. As far as the guts of the OS X is concerned, i.e. the operating system itself... it is sooooo BSD that it's what makes OS X UNIX. (I know, "BSD's not UNIX!" , and then, one day it was).

Re:Hurrah? (1)

Osgeld (1900440) | about 7 months ago | (#44854155)

aka all the proprietary stuff is the stuff people give a shit about

Re:Hurrah? (1)

Bengie (1121981) | about 7 months ago | (#44855211)

By "people", you mean "Mac users", not Unix users. Who cares about the fluff. Apple contributes back most of the important stuff.

Re:Hurrah? (1)

marcello_dl (667940) | about 7 months ago | (#44854907)

> Most of the proprietary code is interface.

But that is what makes the desktop. You say that essentially in the rest of your post

Re:Hurrah? (0)

Anonymous Coward | about 7 months ago | (#44855027)

can you go to sourceforge, find some random application's binaries for bsd and install/run them without issue on mac osx?

Re:Hurrah? (1)

MysteriousPreacher (702266) | about 7 months ago | (#44856021)

Are binaries built for any given BSD going to work on any other BSD? e.g. binaries from OpenBSD working in FreeBSD? How about differing processor architectures?

You're generally looking at compiling for target platforms. Where there is binary compatibility (such as OpenBSD providing FreeBSD binary compatibility) you're probably looking to include the expected FreeBSD libraries. Where possible, it's cleaner to compile for the intended target.

Re:Hurrah? (1)

Shavano (2541114) | about 7 months ago | (#44855113)

Are you honestly trying to argue that the application interface is not part of the operating system? Pfbbbt!

Re:Hurrah? (0)

Anonymous Coward | about 7 months ago | (#44855463)

Unless they completely redesigned the operating system since the last time I used it a couple months ago, the OS is Xnu. Which is Mach, with IO Kit and BSD running on top of it for various services. BSD is only a part of the OS in OS X.

Re:Hurrah? (0)

gl4ss (559668) | about 7 months ago | (#44856177)

nobody really gives a shit about if osx is running on bsd kernel, beos kernel or linux kernel though.

"but wankwankuuhuuh it's got unix shell! can do anything" well laadifuckingdaa that itself doesn't have much to do with the kernel either. you could have that pretty much on any even half sane operating system.

for everyone who is using osx for the right reasons that just "window dressing" is what osx is to them. so bsd+apple simultaneous fanboys can just go fuck off instead of trolling every article with the spam about how you can buy a commercially supported freebsd operating system in the form of a mac and how it's fucking military quality bsd under the hood and certified unix(tm)(which is what makes it unix, but who the fuck cares about that, unix certification, when you can nowadays effectively run the same server software in debian, certified unixes, commercially supported or unsupported various other nix like distributions and even on windows).

Re:Hurrah? (1)

kthreadd (1558445) | about 7 months ago | (#44854115)

OSX = BSD, so yeah, its been year of BSD on the desktop for about a decade.

It includes part of the FreeBSD userland. I don't know if I agree that it makes it BSD. The FSF would probably agree though since they insist that Linux + the GNU userland should be called GNU/Linux, so they would probably argue that it should be called BSD/OS X if they were interested.

Re: Hurrah? (0)

Anonymous Coward | about 7 months ago | (#44854267)

bsd/xnu for consistency

Re:Hurrah? (1)

Anonymous Coward | about 7 months ago | (#44854293)

Not just userland. Much of the OS X kernel is derived from FreeBSD and NetBSD, too.

The problem, though, is that Apple has slowly stopped developing the Unix parts. They've literally deprecated fork, because they can't be bothered to make it work reliably with Core Framework. Neither are they tracking POSIX or BSD developments anymore, having stopped several years ago. OS X's POSIX support is a full release behind. They're compliant to the 2001 specification, but the latest is 2008, plus fixes. In a few years, their POSIX support will be about as useful as Windows', in terms of interoperability with modern FOSS.

Instead, their system engineers have been busy reinventing the wheel by replacing core C code with C++ and Objective-C, for no apparent reason.

Re:Hurrah? (5, Informative)

tlambert (566799) | about 7 months ago | (#44854645)

Not just userland. Much of the OS X kernel is derived from FreeBSD and NetBSD, too.

Almost all of the BSD in the kernel is based on BSD 4.4-Lite2 and NetBSD; there are a couple of small sections, which ironically I wrote, that were pulled in from FreeBSD, like the BSD parts of the init code, and parts that generally everyone wrote, like chunks of the networking stack. I really wanted to change some of the VM APIs to be more like FreeBSD, i.e. in band errors in value returns should have been converted to value returned into variables passed by address with out of band error returns, but this would have required work on the part of the Intel guys prior to the Intel code integration.

The problem, though, is that Apple has slowly stopped developing the Unix parts.

This is BS.

They've literally deprecated fork, because they can't be bothered to make it work reliably with Core Framework.

No, that's a combination of several factors, some of them being Apple having poor representation on the UNIX steering committee. Specifically regarding the committee, there's no such thing as a pthread_atexec() and several other APIs which would be necessary in order to make fork() deterministically useful in already multithreaded programs.

The CoreFoundation factor is a combination of GCD, which starts and stops threads behind the programs back (and can't register exec handlers), and directory services, which for non-root processes starts another thread as a means of security partitioning to support everything DNS and network address related. It doesn't actually need to do this, and neither does GCD, but between that and the missing process lifecycle management functions in POSIX for threads, it's not supportable.

Basically, CoreFoundation is a piece of shit. It's now showing its initial lack of threads support in the design, and binary backward compatibility prevents it being redesigned. Catch-22.

The positive side of this is that people effectively have to use posix_spawn[p]() instead, which means they don't have to copy a massive fricking address space from one process to the other, which is expensive as hell in Mach, since they haven't adopted the red/black tree acceleration for ptov[] translations, mostly because there's too much code that relies on address aliases. In CS terms, the p:v has a cardinality of 1:N instead of 1:!, which breaks code relying on ptov(). There wasn't a lot of it, but there was absolutely no hope of getting rid of the aliases without the VM API changes I mentioned previously.

So boo fricking hoo: use LaunchServices like you were supposed to be doing when using CoreFoundation, and quit using fork() directly, and your problems will go away.

Neither are they tracking POSIX or BSD developments anymore, having stopped several years ago.

The only "tracking" of BSD kernel code that happened since 2003 that I'm aware of (but I left Apple in 2011) was in the networking code, and there was precious little of that, since Apple and BSD selected different concurrency models. BSDs is arguably more scalable, if you have unlimited memory to burn, other wise you want XNUs. You probably want XNUs anyway, particularly if you want to take cores on and offline out from under the CPU for power management or thermal budgetary reasons, and the scalability issues can be addressed.

OS X's POSIX support is a full release behind. They're compliant to the 2001 specification, but the latest is 2008, plus fixes. In a few years, their POSIX support will be about as useful as Windows', in terms of interoperability with modern FOSS.

That just asinine.

First off, the next jump to standards conformance, if any, will be unlikely to be 2008, since it's not going to be widely adopted by industry until IBM and Oracle can get their shit together, which takes more than 5 years, since it includes a migration strategy for maintaining binary backward compatibility.

Second, almost every interface you are referencing in the delta between specifications is marked optional in chapter 9, so there are few required changes, other than some header files, some manifest constants, and some sysconf() values. Presto! You are 2008 compliant!

Third, the thing most people complain about are the HPC interfaces -- and not because they want to do HPC, but because threaded web servers are too stupid to deal with relative directory paths to resources and CGI scripts, or shared hosting environments correctly. You can't change the current working directory for the entire process, so you use the big hammer, and get rid of all your relative paths.

Guess what? Like per-thread credentials (I implemented those!), XNU also supports per-thread current working directories (gee, I implemented those too!), so fricking problem solved without use of a big hammer.

Even if what you are concerned about is Linux compliance, rather than POSIX compliance, you need a clue bat. Linux is not compliant; it fails about 5,000 of the nearly 32,000 POSIX.1003-2001 compliance tests when you run the real test suite, and that's after you fix all the promiscuous headers in the the libc implementation that stop the actual tests from being run. I know this, because I ran the tests.

If you really need the HPC libraries, it's possible to implement them entirely in user space using the per thread current working directories; surprised? I'm not; I designed them that way, and even implemented a libhpc which was never checked in because no one actually ever asked for the APIs.

Meanwhile, Linux should probably get its shit together; as a single security related example, it's really easy to escape exclusion groups due to their faulty groups implementation, which is a security hole you could drive a bus through (to be fair, FreeBSD has that same issue, despite the XNU sources being freely available to see what I did there to fix the issue). Passing all the tests would be a nice start. Like their initial select() implementation, which decremented the remaining time in the timeval structure to account for elapsed time, having an API is not the same thing as having a conformant API.

Instead, their system engineers have been busy reinventing the wheel by replacing core C code with C++ and Objective-C, for no apparent reason.

I haven't really looked that closely at the 10.8 sources; I doubt you are referring to kernel code, since there is no ObjC runtime in the kernel, and there hasn't been since the NeXTStep days.

This kind of sounds like "legacy code sour grapes", like when Apple got rid of the object ID creator mapping API that was used to link files to specific apps and look them up by ID from the resource fork data, instead of using a path, that went out when 64 bit support when in. People were told to get the hell off those APIs 8 years in advance, and didn't listen, so they got bit when it turned out you couldn't stick a 64 bit value into a 32 bit field and maintain binary backward compatibility, and even if you were extremely clever about making it supported, everything broke at once as soon as you has 2^32 + 1 FS objects lying around. I have to wonder how long ago the specific API that you're complaining about here was deprecated and developers were told to get the hell off it?

Cheers!

Re:Hurrah? (2, Informative)

Anonymous Coward | about 7 months ago | (#44854789)

The UNIX side of OS X has been just fine in the recent releases. The problems with OS X are:

1. It doesn't have a real package management system.
2. Long turnaround time for security patches. They should stop this insane "we have to wait until 10.x.y until we ship this patch even though it's ready." A proper package management system would certainly help there.

Re:Hurrah? (3, Interesting)

tlambert (566799) | about 7 months ago | (#44855005)

The UNIX side of OS X has been just fine in the recent releases. The problems with OS X are:

1. It doesn't have a real package management system.

It's called "drag and drop"; properly written applications are self-contained in directories represented by the application icon. If you follow the Mac model, and don't try to install your files all over from hell to breakfast, there's no issue. This is why a lot of demo machines in stores now have epoxy in their USB ports (e.g. the ones at Fry's), since people were stealing already activated copies of Microsoft Office by plugging in their iPod shuffle or other thumb-drive and just dragging it over.

If you want to install all over from hell to breakfast, there's always http://www.macports.org/ [macports.org] or you can make a 5 line change to the FreeBSD ports management system to use "${MAKE}" instead of "make", and deal with two "echo" compatibility issues which are fixed by using "printf" instead, and almost all of the FreeBSD ports system "just works". I gave those patches back to FreeBSD (via Jordan Hubbard); not sure if they made them in.

Note that another benefit of the Mac model is that you can have different applications requiring different versions of libraries, and nobody cares except people already short on disk space. Duplicate block coalescing can fix that, but only works for ZFS, which is an add-on.

2. Long turnaround time for security patches. They should stop this insane "we have to wait until 10.x.y until we ship this patch even though it's ready." A proper package management system would certainly help there.

This is an issue for security problems in the kernel; otherwise, Apple ships regular security patches for all user space components; leave Software Update turned on, and it's automatic, and will pop up and bug you to install updates, since they usually mean an application or system restart (depending on what layer the installs happen).

For the kernel, this is really a management/resources/security-guys-do-not-push-hard-enough problem; the current development model for the Mac OS X kernel is "Scrum", which is good if you want to keep an organ bank of coders around to throw at the next iPhone/iPod Touch/iPad problem, and less good if you actually want to make substantive changes or progress in kernel technology, so it's mostly on managements back. I agree this is a problem.

Re:Hurrah? (1)

Anonymous Coward | about 7 months ago | (#44855227)

It's called "drag and drop"; properly written applications are self-contained in directories represented by the application icon.

That's all fine-and-dandy until you need to keep track of the different version of library packages and make sure they're all up-to-date and not conflicting. Do you want your system handling patches and updates or do you want to manually go through an infinite number of directories and waste your time?

Re:Hurrah? (1)

kthreadd (1558445) | about 7 months ago | (#44855519)

I think the idea is that you don't do that. Each application is supposed to use the system software as far as possible, and if an application vendor ships a third party library as part of their application bundle then that vendor is supposed to maintain it when needed. Won't be perfect from a storage efficiency point-of-view but each application will be more or less independent.

Re:Hurrah? (2)

tlambert (566799) | about 7 months ago | (#44855523)

It's called "drag and drop"; properly written applications are self-contained in directories represented by the application icon.

That's all fine-and-dandy until you need to keep track of the different version of library packages and make sure they're all up-to-date and not conflicting.

You don't need to worry about different versions because there is only one version of the library associated with the app: the one in the app bundle.

The way to make sure your app is up to date is to ensure it's up to date by dragging a new version, or having the app insert itself into the Software Update process, or to have it maintain its own update checks and cycle. The method to do this is documented.

By definition, since all libraries are private to the app, they are non-conflicting. That's the reason they are private to the app.

Do you want your system handling patches and updates or do you want to manually go through an infinite number of directories and waste your time?

I would prefer updates happen in binary form, and that the application handle itself, either by having code to do it on startup, or by installing its own handler into the Software Update process so that it gets checked when the system automatically checks for Apple supplied updates.

Basically, this boils down to you having two non-existant problems, and one self-caused problem (or vendor caused, if they don't support internal updates.

Re: Hurrah? (0)

Anonymous Coward | about 7 months ago | (#44856967)

And you've just indirectly hit on the core problem with desktop linux: dependency hell. Apple solved it the right way, apps are self contained.

No, Package managers are NOT a solution to this, because they virtually never work right over time, and god help you if you install something that isn't from the distro's repo. Linux is designed for web servers, which are built up by pros who install all the software at the same time and then carefully plan updates, or just re-kickstart them. Desktops get random apps installed at random times over a period of years by naive users. Package management doesn't work for that, beacause the distro versions keep moving. You need application independence. I believe this is the primary reason windows still exists.

Re: Hurrah? (1)

kthreadd (1558445) | about 7 months ago | (#44857343)

Self-contained applications is a nice idea, but it makes sense primarily with non-free binary only applications which the user or the OS distribution can't build from source code. If you use a system like Debian stable then you will rarely have any problems with the package manager, and as long as you're using software which is distributed as part of Debian you can be assured that a maintainer has looked at it, that it is licensed under a DFSG compatible license and will most likely not harm you.

You don't have the same thing on OS X and especially if you're running non-free programs downloaded from the net. That's why Apple is pushing so hard for sandboxing applications, since the user is ultimately unable to trust many of the applications.

Re:Hurrah? (1)

epine (68316) | about 7 months ago | (#44855103)

Dude! 1998 called. They want your guru stick back.

Someone mod that up to +15, just for old times' sake. Thanks for the voyage. You made my day.

Re:Hurrah? (1)

Sponge Bath (413667) | about 7 months ago | (#44855421)

It is a refreshing change from people posting pop culture references just for a laugh. I doubt it will last. All those moments will be lost in time, tike tears in rain.

Werll said sir ! now... (1)

johnjones (14274) | about 7 months ago | (#44855255)

it drives me insane when I get linux zealots (the uninformed type...) banging on about Mach...

however I have 1 question...

why is the most deployed Mach version unable to implement IPv6 ?
(the most deployed linux versions being part of the android stack vs Mach being most deployed in Apple iOS)

having a TCP stack and then hobbling it seems weird and to me very annoying !

regards

John Jones

Re:Hurrah? (2)

BitZtream (692029) | about 7 months ago | (#44855287)

Just for reference to those who aren't aware of who the post above is from

tlambert is:

http://people.freebsd.org/~terry/ [freebsd.org]
http://www.linkedin.com/pub/terry-lambert/2/70a/770 [linkedin.com]

I.E. He knows his shit and has the references to back it up. His resume is pretty much a list of industry leading companies for the last 25 years.

Re:Hurrah? (-1)

Anonymous Coward | about 7 months ago | (#44855505)

OK so he worked at Apple and helped enslaving tons of people with their digital handcuffs. Sounds like a great guy.

Re:Hurrah? (1)

Anonymous Coward | about 7 months ago | (#44855571)

Sorry about that. After thinking about it for five seconds I realized how totally inappropriate that was to say. I'm sure he is a great guy, much greater than what I just was. I should have directed my criticism of Apple to Apple, not to him or anyone else just because they have worked for the company.

Re:Hurrah? (2)

TheRaven64 (641858) | about 7 months ago | (#44855061)

They've literally deprecated fork, because they can't be bothered to make it work reliably with Core Framework

fork() deserves to be deprecated. The API originates with old machines that could have a single process in-core at a time. When you wanted to switch processes, you wrote the current process out and read the new one in. In this context, fork was the cheapest possible way of creating a new process, because you just wrote out the current process, tweaked the process control block, and continued executing. On a modern machine, it requires lots of TLB churn as you mark the entire process as copy-on-write (including TLB shootdowns which require IPIs on a multithreaded program using multiple cores). And then, in most cases, it's followed by exec() and so the process that you've just created is replaced by another one and you need to go through the whole sequence again to stop its memory being CoW.

Not only is fork() a ludicrously inefficient way of creating a process on a modern machine, it's also incredibly difficult to use correctly. When you fork(), all of your threads and all of your process descriptors are copied. You need to make sure that every thread that you create uses pthread_atfork() to ensure that it doesn't do any I/O after the fork() and before the exec(). You also need to ensure that you close any file descriptors that you don't want to be propagated to the child, which is nontrivial if you have other threads opening and closing files in the background (O_CLOEXEC helps here, but do you remember to use it everywhere?).

Oh, and posix_spawn() isn't much better. It's designed to be possible to implement on top of existing APIs and so ends up being largely useless without non-standard additions. It doesn't, for example, provide a mechanism to say 'close all file descriptors in the child, except for these ones'.

Re:Hurrah? (2)

evilviper (135110) | about 7 months ago | (#44855445)

Year of the BSD desktop.... FINALLY!

Meh. My preferred slogan is:

"FreeBSD. Still dying after all these years..."

Netcraft confirms it, in the library, with the lead pipe.

Netcraft confirms it (-1)

Anonymous Coward | about 7 months ago | (#44853517)

Netcraft confirms it...BSD is dying

yea (2)

celle (906675) | about 7 months ago | (#44853521)

Woman screams and waves arms.

FreeBSD!!

Oh, geek screams and waves arms.

Re:yea (1)

rrohbeck (944847) | about 7 months ago | (#44854631)

Why do we need to free BSD and why did (s)he get incarcerated?

Re:yea (0)

Anonymous Coward | about 7 months ago | (#44855479)

Why do we need to free BSD and why did (s)he get incarcerated?

1) We don't.

2) She was actually turning tricks.

Re:yea (0)

Anonymous Coward | about 7 months ago | (#44856933)

NetBSD advocates support the right to bar arms.

TCP congestion control research in FreeBSD (5, Interesting)

bcreane (667034) | about 7 months ago | (#44853529)

FreeBSD hosts interesting work with respect to TCP congestion control. An earlier version (I think FreeBSD 8.0) introduced modular congestion control algorithms, and this version introduces CAIA Delay-Gradient (CDG) congestion control algorithm. The check in is here: http://svnweb.freebsd.org/base?view=revision&revision=252504 [freebsd.org] , and an interesting (if slightly esoteric) slide deck is here: http://www.ietf.org/proceedings/84/slides/slides-84-iccrg-2.pdf [ietf.org] .

Competition is always good (1)

Anonymous Coward | about 7 months ago | (#44853535)

Entrenched market share leaders get comfortable and a bit arrogant, particularly in technology. Things are done a certain way because that's the way they've always been done, and anyone who thinks differently is a clueless moron.

I don't think Linux kernel and GCC are exceptions to this rule, which has been proved over and over and over again.

Re:Competition is always good (1)

Anonymous Coward | about 7 months ago | (#44853849)

Yes we know that.

However BSD isn't really competition.

Re:Competition is always good (4, Informative)

dbIII (701233) | about 7 months ago | (#44853955)

It is with things like ZFS - the linux implementation (which I'm also using) is currently miles behind the freebsd version.

The real problem with BSD (-1, Flamebait)

hessian (467078) | about 7 months ago | (#44853573)

...is the attitude of the developers, the people on the mailing lists, and anyone else who interacts with new users.

You're outright hostile and condescending. There's no call for that, no matter how elite you are. Many of the people you're being condescending to are far more elite than you, but in other fields.

I used to lobby hard for BSD. Now, after getting completely embarrassed by the hostile and sociopathic response of the developers when people I've sent over have needed legitimate help, I'm simply recommending Linux or Windows.

Re:The real problem with BSD (1)

ThorGod (456163) | about 7 months ago | (#44853611)

Was this FreeBSD or one of the others?

I tell you what grinds me...the installers. The best one for "just get it done" is PC-BSD - but even it can be flaky.

Re:The real problem with BSD (1)

geek (5680) | about 7 months ago | (#44853675)

Was this FreeBSD or one of the others?

I tell you what grinds me...the installers. The best one for "just get it done" is PC-BSD - but even it can be flaky.

The FreeBSDinstaller is fine if you arent trying to do anything fancy, otherwise you're dropping to a terminal and doing a little manual work. The plus side is FreeBSD has what I consider to be the best documentation of any UNIX out there with the possible exception of Arch.

PCBSD is an unmitigated disaster though. I'd stay far away from that pile of shit. The installer is flakey, the distro is bloated as fuck and the community is fucking worthless. Being based on FreeBSD you would think the documentation would be decent but its total crap. The whole PBI concept is the workmanship of retards too.

Re:The real problem with BSD (1)

ThorGod (456163) | about 7 months ago | (#44853701)

Exactly. It just seems like, by now, the installers shouldn't feel completely bare bones or completely "well, who knows what we'll get out of this".

The problem with PC-BSD (1)

unixisc (2429386) | about 7 months ago | (#44857399)

Why, what exactly is wrong w/ the PC-BSD installer, or for that matter, PBI? Does it not work as it's supposed to, as per theory?

Re: The real problem with BSD (1)

Anonymous Coward | about 7 months ago | (#44854491)

Still, with PCBSD you can install a FreeBSD with ZFS in 5minutes and 10 clicks. In 1 minute you can make a pure FreeBSD jail or even an linux one and still can watch YouTube and play Games on that box.

Re:The real problem with BSD (-1)

Anonymous Coward | about 7 months ago | (#44854601)

Actually the documentation of FreeBSD is nowhere near as good as even the Debian or ($deity forbid) the Redhat documentation. Particularly, the documentation on

1- installing
2- maintaining
3- upgrading

freeBSD is horrid. It is false and misleading and in places several versions out of date. If you want to find out how to do even basic stuff, you need to ask on forums and hope for the best.

The man pages are OK though.

Re:The real problem with BSD (0)

Anonymous Coward | about 7 months ago | (#44853693)

Who needs an installer when you can partition your disk yourself then untar the entire os and reboot?

Re:The real problem with BSD (1)

vomitology (2780489) | about 7 months ago | (#44853613)

I can (unfortunately) second this. When I tried to install on my netbook and asked for help, I got many variations of RTFM... which if I could find one that was written in some semblance of English I would. Most of the BSD documentation I've seen is... somewhat less than user friendly.

Re:The real problem with BSD (3, Informative)

Anonymous Coward | about 7 months ago | (#44853637)

Apparently you missed http://www.freebsd.org/handbook

In well written english, with screenshots and everything.

Re:The real problem with BSD (2)

icebike (68054) | about 7 months ago | (#44853875)

Apparently you missed http://www.freebsd.org/handbook [freebsd.org]

In well written english, with screenshots and everything.

Exactly. The handbook is awesome. (I didn't even need to use it to get up and running because bsdinstall (the installer) is pretty self explanitory to anyone
who has been around any nix systems for a while.) You will want a copy of the manual somewhere handy

I haven't touched FreeBSD in years, but recently wanted to play with it again. It was awesomely well documented, both with a manual and several guides, not to mention a zillion Google Hits. I didn't need to bug anyone about any thing, because all the answers were at my finger tips. It was actually a very easy install.
I added XFCE4 just to see how well that worked, and it was quite nice.

If someone gets turfed from the mailing list, its because they joined the WRONG mailing list. Start asking for beginner help on the Linux Kernel Mailing List list and see how warmly you are received.

But installing version 9 was very easy. There is no reason to avoid FreeBSD if you like messing around with different OSs. Learning is not detrimental to your health.

Re:The real problem with BSD (1)

santax (1541065) | about 7 months ago | (#44853889)

Hehe, you didn't try to install 9 with full disk encryption did you? ;) Just saying.

Re:The real problem with BSD (3, Insightful)

Osgeld (1900440) | about 7 months ago | (#44854165)

and instead of politely pointing it out, you had to make yourself sound like a snotty condescending ass about it

grats for proving the op's point

Re:The real problem with BSD (0)

Anonymous Coward | about 7 months ago | (#44854605)

Yes, this version is OK but when FreeBSD 9.0 came out (the stable version, not the alpha or beta) it was unusable. FreeBSD 9.x have a totally different way of installing than earlier versions, and when it came out it was undocumented. How nice.

Re:The real problem with BSD (1)

TheRaven64 (641858) | about 7 months ago | (#44855077)

There are several things that make your post look like a troll:
  • Which BSD are you referring to? There's some overlap between the BSD communities, but only about as much as there is between the communities of various Linux distributions.
  • Where did you ask? Was it one of the places that FreeBSD recommends (mailing lists, IRC channels, or forums), or did you just pick a random place somewhere on the Internet?
  • Did you actually read the FreeBSD Handbook, which contains fairly detailed instructions on installation, or is that one of the documents that wasn't 'written in some semblance of English'.

Re:The real problem with BSD (3, Insightful)

Dahamma (304068) | about 7 months ago | (#44853745)

Everything you say is true. But are the Linux developers really all that different? There have been some epic flamewars on LKML and plenty of RTFM...

The fact is OS developers are generally extremely smart, "self-confident" (I'll try not to say "egotistical" or "arrogant"), and possibly somewhat socially awkward/blunt. The only reason you don't get that from Windows and OSX is that MS and Apple hide their kernel developers away from public debate :)

Re:The real problem with BSD (1)

icebike (68054) | about 7 months ago | (#44853883)

Everything you say is true.

These people should not be answering questions from rank newbies. They have day jobs, and spend a hell of a lot of
time maintaining the software. They just don't have enough hours in the day to handle questions from every passing neophyte.

There are other mailing lists for this.

Re:The real problem with BSD (3, Insightful)

Dahamma (304068) | about 7 months ago | (#44853963)

These people should not be answering questions from rank newbies.

Yes, and there are ways of saying that to someone that are not condescending, rude, or just plain assholish.

Though you know, some people in fact DO like helping others, even newbies (sometimes we call those "teachers", and sometimes they are just good people). But even if someone doesn't want to help, "please use XXX list for this question" is really not any harder to type than than "stupid question, stop posting here and RTFM".

Re:The real problem with BSD (2)

BitZtream (692029) | about 7 months ago | (#44855241)

Really, what way is that? Answering 30 ignorant questions a day by people asking for stuff that is so clearly WAY above their heads they shouldn't be asking, yet they do.

As a developer, this is why I avoid working on projects where random people can interact with the devs. You get mailing list questions like

I'm trying to make this plugin that can totally change the way the software works, but I get an error:

main must return a value

Can you help me fix?!!@?$!@?^#$^!@?!?

What is the response I'm supposed to give to all those morons who are so ignorant of what they are doing that they don't have any idea how ignorant they are. Thats not something I can fix, its not my problem, its theirs. Its one thing to not understand how something works, its entirely different to not know anything about the subject matter at all, and then ask someone how to do something that's never been done before.

Do you think race car drivers and mechanics should sit around and answer the 'I want fast car, how me go fast?!?!?!@?! What is drivers license?!?!@?@!?@$ What is engine?!?!?!?! tires?!?!?!?!' crap as well?

When you so clearly don't know what you're doing, and you so clearly haven't tried to figure out anything at all, and then you go ask high-end devs how to do something that shows you know ABSOLUTELY NOTHING ABOUT THE OS OR DEVELOPMENT FOR IT ... you deserve to get a kick in the teeth.

Its fucking rude to waste my time with your ignorance when your ignorance can be solved by spending the time you took to write to the kernel list on Google with far better results. Lazy fucks.

Re:The real problem with BSD (1)

DNS-and-BIND (461968) | about 7 months ago | (#44855693)

So, the point you're making is that your hostility is completely justified, and these people deserve the abuse. Yay, I guess?

Re:The real problem with BSD (2)

sumdumass (711423) | about 7 months ago | (#44854023)

I think one of the problems might also be that they are seeing the same damn questions asked over and over but slightly different and the user isn't able to connect the slightly different question to the published answer already given somewhere.

I used to do some support on IRC with a Linux group catering to a specific distro and I saw this all the time. I eventually created macros to ask the questions just to get to the point of the problem because of the 10,000 different ways someone states it. Often the skill levels of the users were so different that you would either talk over someone's head or upset them for talking down to them. It got extremely aggravating when talking over someone's skill level and they don't tell you they don't understand something until you are 20 steps into it. It is even more aggravating when you talk down to someone and they get upset and cuss you out crying they aren't a newbie or something. Most of the problems were incompatible or unsupported devices that were already listed as incompatible and unsupported on the distro's website but people refused to believe it until they saw it first hand.

I eventually bailed on the entire thing after the distro merged with another and dropped all the things I like in order to promote all the things I didn't like about it. Some of the others who helped found it easier to just ssh into the user's box and fix it than to pull the real question out and explain the answer well enough to be used. I can see why some groups get short and say RTFM all the time (not that I agree it is proper to do so). I've about given up on linux- it seems as soon as there is something I like, they go and change it and make it extremely difficult to put it back in.

Re:The real problem with BSD (0)

Anonymous Coward | about 7 months ago | (#44854217)

sounds typical of linux

its the users fault cause they didnt know some made up buzzword specific to some random distro, and when you talked to them like they were stupid they got mad

nevermind its the ass clown os and its unqualified support staff, its too much for you to deal with

fuck off

Re:The real problem with BSD (3, Insightful)

epyT-R (613989) | about 7 months ago | (#44854315)

computers are complex tools. The more operating systems try to hide that, the more dumb the users get.. it's a race to the bottom.

This antipathy towards learning curves is a big part of today's society (the idiocracy). Not only do people abhor learning, their superiors refuse to give them the time necessary to do it... Thus we end up with desktop operating systems that work like tablets. Everyone now thinks all computers should work like smartphones, no matter what they need the machine for. Complex procedures do not work like they do in star trek. Deal with it.

There are users like this with every os, not just linux.

you fuck off.

Re:The real problem with BSD (1)

mcgrew (92797) | about 7 months ago | (#44855165)

This antipathy towards learning curves is a big part of today's society (the idiocracy).

I've always loved to learn, but one thing I hate is having to relearn. If a new tool has obvious advantages over an old tool I'm happy to learn the new tool: I'm lazy. I don't live to work, I work to live. I didn't mind learning Windows because it had obvious advantages over DOS. I didn't mind learning Linux because Windows was a PITA.

One reason it was such a pain was change for the sake of change, which Windows is even worse about now. Back in the '90s my employer was transitioning from Corel Office to Microsoft Office, so I took an Excel class. Two weeks after I took the class they upgraded to a newer version of Excel; that class was a complete waste of time because the New Excel was nothing like the old Excel (it was more like Quattro than the old Excel).

What's worse is when a change introduces complexity rather than simplicity, like that stupid Microsoft Ribbon. Rename editing functions from Edit to Home, WHY??? Changing the File menu to a colored button with no mouseover was just retarded. At least they fixed that little stupidity. Introducing the Microsoft car, with the throttle on the left and the brake on the right.

That's what I like about Linux; changes are almost always improvements (and when they aren't the community usually screams bloody murder). Microsoft's changes are usually just for the sake of introducing an unnecessary learning curve.

There's way too much useful, interesting stuff for any one person to learn, don't waste my time relearning an interface when I could be spending my time learning something useful.

Complex procedures do not work like they do in star trek.

I would have agreed with you before I got an Android phone. That thing is straight out of Star Trek. Microsoft's problem with W8 is they thought "people already know how to use a tablet so we'll make the desktop like a tablet." The trouble is, that's like designing your hammer to be more like a saw. They're different tools with different purposes. A car is not a bicycle, I don't want handlebars in my car.

Re:The real problem with BSD (1)

jones_supa (887896) | about 7 months ago | (#44854567)

Everything you say is true.

These people should not be answering questions from rank newbies. They have day jobs, and spend a hell of a lot of
time maintaining the software. They just don't have enough hours in the day to handle questions from every passing neophyte.

There are other mailing lists for this.

I understand that, but still... There are some cases in which I there is not a person that has the deep technological understanding of some component, when I post in the forums of some distro. And on the other hand, as you say, the professional developers don't have time to answer all the peasant questions. Ah well.

Re:The real problem with BSD (2)

Falkentyne (760418) | about 7 months ago | (#44853787)

Yes, I ran into that problem in the past as well but then I realized I was emailing the FreeBDSM mailing list. Needless to say, I've since switched to Linux and I'm being fulfilled in ways you can't imagine.



... and it's actually a website wtf

Re:The real problem with BSD (1)

Anonymous Coward | about 7 months ago | (#44854103)

BSD developers or Linux developers? Sometimes it's hard to tell. Linus Torvolds is one mean guy.

Personally I don't care, nearly all developers, doesn't matter what operating system they favor are Not-invented-here's, and assume anyone who has a problem with their software suffers from PEBKAC. Interact with developers as little as possible.If you can't replicate the problem twice by yourself, then the problem isn't reproducible.

As far as why I'll pick FreeBSD over Linux. Out of the box, I can't cripple freebsd with default-settings, but I can with Linux, which says much about the terrible state of Linux if you can have something like apachebench pushed against it and have it segfault in seconds, or be so unresponsive you can't rescue the machine. That is out-of-the-box Linux... unreliable. FreeBSD and OSX don't do this. The only thing that does it worse is Windows.

Re:The real problem with BSD (0)

epyT-R (613989) | about 7 months ago | (#44854331)

Get a goddamned clue. You can fuck up any OS if you try hard enough.

Re:The real problem with BSD (1)

Anonymous Coward | about 7 months ago | (#44854525)

Get a goddamned clue. You can fuck up any OS if you try hard enough.

Butthurt Linux Zealots! This is why I come to Slashdot.

Re:The real problem with BSD (0)

Anonymous Coward | about 7 months ago | (#44854587)

Get a goddamned clue. You can fuck up any OS if you try hard enough.

That's a clue to move to Windows or Mac.

Re:The real problem with BSD (0)

Anonymous Coward | about 7 months ago | (#44854137)

Have you tried ArchBSD [archbsd.net] ?

Re:The real problem with BSD (1)

epyT-R (613989) | about 7 months ago | (#44854289)

..or maybe you were just 'wrong' and you took offense rather than chock it up as a learning experience.

Re:The real problem with BSD (0)

Anonymous Coward | about 7 months ago | (#44854365)

[...] chock it up [...]

"chalk it up" is the correct wording.

Re:The real problem with BSD (1)

wjcofkc (964165) | about 7 months ago | (#44855607)

after getting completely embarrassed

Perhaps you deserved it because I for one have no idea what you are talking about. I am new to FreeBSD as of the last few weeks and personally have found their community to be quite helpful, especially the forums on FreeBSD.org. I recently asked a very stupid question over something obvious I had overlooked and no one flamed me at all - in fact they were helpful and didn't call me out on it. Granted when it comes to their official forums there are rather extensive rules of etiquette to follow, but they are there for a reason and they make sense.

Perhaps there has been a rift in the space-time continuum and you are posting from the evil universe.

Re:The real problem with BSD (1)

Lawrence_Bird (67278) | about 7 months ago | (#44855921)

I hate to respond to trolls but in this case I think the record needs to be set straight. I have used FreeBSD for about 6 or 7 years now, having come off about 12 years of Slackware. In that time, I have had multiple need to ask for help or clarification both on the mailing list as well as the IRC channel. And I can honestly say I did not get one fliippant or rude remark and some people actually did try to help, unlike some other open source software (non-OS) where questions were met with crickets.

Lastly - FreeBSD is probably the single most/best documented open source operating system ever.

ASLR anyone ? (0)

Anonymous Coward | about 7 months ago | (#44853607)

You could just put a big red on/off switch if entropy matters so much to some users :-(

So, the real question is... (1)

dbraden (214956) | about 7 months ago | (#44853651)

...does it run Docker? *ducks*

Re:So, the real question is... (1)

gmuslera (3436) | about 7 months ago | (#44853739)

Docker is based in LXC [sourceforge.net] (linux containers), so not available in freebsd. But can be done a port or a similar project based on FreeBSD Jails [freebsd.org] . It also uses aufs and cgrups, but i think freebsd have similar tools too.

Re:So, the real question is... (0)

Anonymous Coward | about 7 months ago | (#44854235)

whoosh

security (2, Insightful)

santax (1541065) | about 7 months ago | (#44853707)

As much as I love freebsd I have stopped using it after their servers got 'served' with the use of 'legitimate' ssh keys. http://www.paritynews.com/2012/11/19/487/two-freebsd-project-servers-hacked/ [paritynews.com] Given that Freebsd never released a good audit report after that hack I can only be worried more. Add to that, we now that we know the NSA had access to the certs from diginotar and might had done or paid for the diginotar hack I think one might as well use windows. I hate to say it, but the complete codebase from freebsd needs to be checked. Again and again. Preferable with the help from openbsd.

Re:security (0)

Anonymous Coward | about 7 months ago | (#44853937)

Ah yes, OpenBSD is exactly who you want [linuxjournal.com] .

Re:security (1)

santax (1541065) | about 7 months ago | (#44854021)

You are cherry picking. Theo released that mail to the open on day 1. The guy who made the accusations got a bit scared after a reporter did a factcheck and asked him to remove it until he could answer. The reporter did, but we are still waiting for that answer. promised to respond to a question from a reporter never did. The backdoor would have been installed in 2001 and in SSH only. While it could be true... now, 12 years later that backdoor still isn't found. And it had been checked by everyone that matters and has the skills to do so.

Re:security (5, Informative)

Anonymous Coward | about 7 months ago | (#44854329)

As much as I love freebsd I have stopped using it after their servers got 'served' with the use of 'legitimate' ssh keys. http://www.paritynews.com/2012/11/19/487/two-freebsd-project-servers-hacked/ [paritynews.com]

Given that Freebsd never released a good audit report after that hack I can only be worried more.

Add to that, we now that we know the NSA had access to the certs from diginotar and might had done or paid for the diginotar hack I think one might as well use windows. I hate to say it, but the complete codebase from freebsd needs to be checked. Again and again. Preferable with the help from openbsd.

Maybe you should read over the report from freebsd.org: http://www.freebsd.org/news/2012-compromise.html

1) It was a single ssh-key that was leaked.
2) The accompanying user rights allowed access to two build server nodes which they took offline and they compared the data to a known good offline copy.
3) They pulled the 9.1-RELEASE packages they couldnt verify.
4) The compromised user only had access to the build system for binary packages. The BUILD system (and third party at that). NO access to the source repositories (except checking out, like you and me).
5) If you didn't use the 3rd party binary packages you weren't affected at all. (and who uses binary packages with freebsd anyway?)

I don't know how the infrastructure is organized in your company, but usually there is a user management on a server if you hand out ssh-keys and only a few if any are allowed to sudo su. IF there is sudo at all. That isn't a desktop box where every user added gets an entry in sudoers to su.

Re:security (2)

TheRaven64 (641858) | about 7 months ago | (#44855143)

Someone else has already pointed you at the report on the compromise. One of our developers has a VM that turned out not to be as secure as he though, and which had his ssh keys (with no passphrase) that gave access to the FreeBSD cluster machines. As soon as the attack was noticed (very quickly, owing to one particularly paranoid developer), the affected machines were taken offline. Bringing things back online took a long time, for several reasons:
  • All of the code that we're running on FreeBSD.org machines was audited
  • Some of it turned out to be a little bit scary (e.g. build machines having access to the FTP servers so they could push packages) and so the architecture needed redesigning in places.
  • We rolled out auditdistd on all of the hosted machines, so now they have audit logs that are stored in multiple places, for all machines.
  • We redesigned the network layout at all of our sites to reduce interconnectivity of unrelated services.

As to the codebase needing auditing, we had both svn and git mirrors that allowed the entire history to be checked. We also had copies of checksums of releases and so all of these things were verified. Bringing CVS back online took a bit longer, as CVS easily let us verify the top of the tree, but not the history. I think we ended up regenerating the entire CVS history from svn, and took the opportunity to officially remove support for CVS.

Are there still vulnerabilities? Almost certainly. Any codebase more than a few dozen lines long will contain bugs, and some of them are exploitable if you're sufficiently clever. That's why a lot of the focus in 10.0 has been on mitigation techniques. The auditdistd framework lets you easily deploy auditing for an entire site. Capsicum makes it relatively easy to compartmentalise applications and a system daemons use capsicum out of the box. So do some of the normal filter utilities, for example even if you run uniq as a root user, once it's finished parsing the command line arguments it won't be able to access to any files in your system except the ones you told it to read.

Re:security (1)

BitZtream (692029) | about 7 months ago | (#44855259)

Given that Freebsd never released a good audit report after that hack I can only be worried more.

http://www.freebsd.org/news/2012-compromise.html [freebsd.org]

Get a clue troll. Why are you referencing some random website written 2 days after the incident was noticed rather than the vendor, who did a full write up on what happened?

Add to that, we now that we know the NSA had access to the certs from diginotar and might had done or paid for the diginotar hack I think one might as well use windows

What the fuck does that have to do with FreeBSD or Windows? You want to use Windows because it has Diginotar/Comodo certs included by default? You know FreeBSD itself doesn't trust ANYONE's certs by default, right?

And if you read the page you're linking to ... it was clear, even on that shitty page, that it effected pre-built ports. Specifically stating the OS itself had absolutely no risk of intrusion, since the keys in question had no access to write anything other than 3rd party packages.

You're just a ignorant troll, a shitty one at that.

Advantages / disadvantages vis-a-vis Linux? (0)

Anonymous Coward | about 7 months ago | (#44854827)

Genuine question, though I know I run the risk of starting a flame war.

What advantages or disadvantages would I find if I installed FreeBSD when compared to my current Debian Linux system?

Re:Advantages / disadvantages vis-a-vis Linux? (3, Informative)

kthreadd (1558445) | about 7 months ago | (#44855059)

Advantages:

* The OS and the applications are separate. This means that you can have up to date versions of your desktop and all applications on a stable core OS. On Debian you would either have to build things yourself or upgrade your entire system to testing or sid.
* A mature ZFS implementation. You can use ZFS-on-Linux or Btrfs for similar functionality on Debian, but it's often not considered to be as production ready as ZFS on FreeBSD. Also for license compatiblity issues ZFS-on-Linux will never ship as part of a GNU/Linux distribution and will have to be installed separately.

Disadvantages:

* Not as good hardware support. Usually works well on desktops and servers, but it can take some tweaking to get it to work well on modern laptops.
* Some software does not run on FreeBSD. Very uncommon for open source, but can be a problem if you're running non-free software. You can mitigate this by installing the Linux compatibility layer on FreeBSD.

Re:Advantages / disadvantages vis-a-vis Linux? (0)

Anonymous Coward | about 7 months ago | (#44855883)

An informative and reasonably neutral comment.
Kill it with fire!

Still contains proprietary firmware? (0)

Anonymous Coward | about 7 months ago | (#44855095)

Re:Still contains proprietary firmware? (1)

kthreadd (1558445) | about 7 months ago | (#44855147)

The general stance is that it's not optimal bus also not a critical problem since it's not part of the OS and only used to enable certain hardware. There's no plan to remove them as far as I know, although there is work going on in tweaking the build system so that you can build a FreeBSD distribution where they are omitted.

VPS? (1)

allo (1728082) | about 7 months ago | (#44855105)

What's the problem with jails?

Re:VPS? (0)

Anonymous Coward | about 7 months ago | (#44857073)

Jails can't have their resources (CPU, Memory, etc) without applying a patch (which, AFAIK, isn't maintained any longer) and recompiling. VPS instances seem like jails on steroids.

See http://7he.at/freebsd/vps/docs/man/vps.conf.5.html for a list of configurable resource limitations.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...