Slashdot Mirror

They have released the open source code in Darwin and kept releasing it with every new release of OS X. They have added their own open source components, to the point where the majority of the traditional userland in OS X, as well as many major new components like launchd, are open source.

Right. That strong commitment to open source no doubt accounts for OpenDarwin's continued existence.

Contrary to popular belief, it is this parasitic nature that actually ends up profoundly improving the operating system and proliferating it. Think of the following hypothetical scenario:

1. CEO sees product XYZ and thinks to himself "Wow, we can compete with that!"
2. CTO responds to CEO with "We need to research viable means to penetrate this [new] vertical-market with a high profit margin." This all means "I'll get back to you with the cheapest possible implementation after I consult our developers."
3. Director of IT says "Hey, we can use FreeBSD as a platform because it's free and has an open license."

This is where the general populous that conforms to your statement stops thinking and fails to realize the rest...

4. Developers are tasked by the director to learn FreeBSD.
5. Support staff is tasked with inundating themselves with FreeBSD to support the product/customers.
6. Quality Assurance is subjected to FreeBSD to test the product.

and in my experience at Yahoo! (in the beginning days when FreeBSD was but a murmur on the lips of the Directors and CTO), the following happens...

7. Developers, Support staff, and Quality Assurance falls deeply in love with FreeBSD.

which leads to...

8. Developers giving back to the FreeBSD community.

You don't have to believe it, but the arguments for the decision to use FreeBSD do exist. The people that choose it are not always vapid management. Sure, it may start out that way, but if you look closely at the Netcraft, you might just find that BSD even found a niche in the web-server world (where your argument of parasitic license globbing does not and cannot apply as the GPL has no grounds in the argument of which OS serves up your content to the World-Wide-Web).

I am not a zealot. I find that every OS has its place. I for one, for a desktop environment would definitely suggest Linux because it has very good device support. I for one don't think that the BSD's will ever corner that [desktop] market.

Even within the BSD world, there is dissention and each flavor (very much alive and kicking) has its purpose. For example, I believe that the greater and more well-known BSD variants can be summed up into a single sentance (see below):

BSDi Commercial BSD Version. Commercial Support.
FreeBSD Optimized for the Pentium Processor.
NetBSD Runs on almost every platform.
OpenBSD Security and Cryptography. Runs on many platforms.
PicoBSD Fits on a single 1.44MB floppy disk.

That was true, being said in an article from 1999 (by Chris Coleman, author of BSD advocacy articles and unbiased BSD editorials on DaemonNews), I would add the following summations to bring it up to present day:

BSDi
Enterprise-level use (close-source product). This BSD variant intends to compete with people such as RedHat Enterprise Linux and other Enterprise UNIX flavors. Runs on Intel only.
FreeBSD
If running Intel, there is no better choice. FreeBSD focuses on security (not as hard-core as OpenBSD though) and stability/performance on the Intel platform. DEC Alpha is supported but stability/performance may be better on NetBSD for Alpha support.
NetBSD
Bleeding edge hardware compatibility. More often than not, this team has support before any other distribution (before Linux even). Hardest distro in the world to[?] (besides Windoze).
OpenBSD
Security security security (derived from NetBSD).
PicoBSD
Minimalism at its best (maintained by the Fre

Contrary to popular belief, it is this parasitic nature that actually ends up profoundly improving the operating system and proliferating it. Think of the following hypothetical scenario:

1. CEO sees product XYZ and thinks to himself "Wow, we can compete with that!"
2. CTO responds to CEO with "We need to research viable means to penetrate this [new] vertical-market with a high profit margin." This all means "I'll get back to you with the cheapest possible implementation after I consult our developers."
3. Director of IT says "Hey, we can use FreeBSD as a platform because it's free and has an open license."

This is where the general populous that conforms to your statement stops thinking and fails to realize the rest...

4. Developers are tasked by the director to learn FreeBSD.
5. Support staff is tasked with inundating themselves with FreeBSD to support the product/customers.
6. Quality Assurance is subjected to FreeBSD to test the product.

and in my experience at Yahoo! (in the beginning days when FreeBSD was but a murmur on the lips of the Directors and CTO), the following happens...

7. Developers, Support staff, and Quality Assurance falls deeply in love with FreeBSD.

which leads to...

8. Developers giving back to the FreeBSD community.

You don't have to believe it, but the arguments for the decision to use FreeBSD do exist. The people that choose it are not always vapid management. Sure, it may start out that way, but if you look closely at the Netcraft, you might just find that BSD even found a niche in the web-server world (where your argument of parasitic license globbing does not and cannot apply as the GPL has no grounds in the argument of which OS serves up your content to the World-Wide-Web).

I am not a zealot. I find that every OS has its place. I for one, for a desktop environment would definitely suggest Linux because it has very good device support. I for one don't think that the BSD's will ever corner that [desktop] market.

Even within the BSD world, there is dissention and each flavor (very much alive and kicking) has its purpose. For example, I believe that the greater and more well-known BSD variants can be summed up into a single sentance (see below):

BSDi Commercial BSD Version. Commercial Support.
FreeBSD Optimized for the Pentium Processor.
NetBSD Runs on almost every platform.
OpenBSD Security and Cryptography. Runs on many platforms.
PicoBSD Fits on a single 1.44MB floppy disk.

That was true, being said in an article from 1999 (by Chris Coleman, author of BSD advocacy articles and unbiased BSD editorials on DaemonNews), I would add the following summations to bring it up to present day:

BSDi
Enterprise-level use (close-source product). This BSD variant intends to compete with people such as RedHat Enterprise Linux and other Enterprise UNIX flavors. Runs on Intel only.
FreeBSD
If running Intel, there is no better choice. FreeBSD focuses on security (not as hard-core as OpenBSD though) and stability/performance on the Intel platform. DEC Alpha is supported but stability/performance may be better on NetBSD for Alpha support.
NetBSD
Bleeding edge hardware compatibility. More often than not, this team has support before any other distribution (before Linux even). Hardest distro in the world to[?] (besides Windoze).
OpenBSD
Security security security (derived from NetBSD).
PicoBSD
Minimalism at its best (maintained by the Fre

Do you know anyone outside of Redmond that actually strips copyright notices from their source code?

The BSD software Microsoft uses (or used, not sure but I think they removed a lot of it progressively with XP and Vista) still carries Berkeley/University of California copyright notices (run strings on it if you don't believe me). Try again.

One automated way is to use Modular Syslog's hashed logging function:

http://ezine.daemonnews.org/200112/log_protection. html
http://www.softpanorama.org/Logs/log_management.sh tml
http://www2.corest.com/files/files/11/PEO.pdf
http://www.linuxsecurity.com/content/view/117280/5 0/

I remember reading about this several years ago. It was an active area of work in the 2001 to 2003 timeframe.

You can read an article about it here:

http://ezine.daemonnews.org/200112/log_protection. html

There is also a draft in the IETF on how to do this in a standard way:

http://www.ietf.org/internet-drafts/draft-ietf-sys log-sign-22.txt

Good stuff.

It's unix

OS X is not UNIX

Yes, it is Unix, every bit as much as any BSD is Unix. If you don't count Darwin/Mac OS X, then all Sun workstations running the BSD-based versions of SunOS are also not "Unix workstations."

Just because Mac OS X includes some proprietary things, and has its own unique problems (as does any Unix variant), doesn't mean that it's not Unix.

Put it this way: you can't compile Unix software on non-Unix systems. You can do this with minimal effort on Mac OS X; ergo, bottom-line, it's a Unix platform.

IIRC, a few years ago, documentation about the X window system had scary warnings about blowing up your monitor if you attempted to use an incorrect video mode. I can't find an authoritative link, but here are some hints:

"Choose a decent depth for modern monitors. In the old days you used to be able to blow up your monitor. Is this still true? Maybe wear googles."

"What this means is, you could actually blow your monitor if you attempt to be too aggressive with the sync rate. Be careful. Most modern multisync monitors can be used safely with the relatively conservative "Non-Interlaced SVGA, 1024x768 @ 60 Hz, 800x600 @ 72 Hz" setting, which is the setting I select."

If you believe Rob Braun (http://ezine.daemonnews.org/200602/apple.html, link posted by an AC a few posts above), you get to see less and less of the source code.
Too bad.
Because Apple uses a few graphics chips with notoriously lousy Open Source support (ATI, NVIDIA). For a short time, I had the idea that looking at their drivers could maybe help Linux development. But now I guess that there is no help to be had from Apple there.

I think you need to read up on the current state of Apple's open source development initiative. I believe the process for submitting a kernel patch goes something like this:

1. Obtain the source by reaching up into the ivory tower and taking it. Notice that you're fetching tarballs over http, not svn or cvs. I'll bet that's current.
2. Beat yourself with a stick trying to build it until you discover darwinbuild.
3. Develop your patch.
4. Submit a bug to the Radar.
5. Announce it in Darwin-kernel.
6. Wait.
7. Wait some more...
8. Read this and give up.
9. Go back to whatever *BSD you came from, fool.

So far Apple has done open source as a publicity stunt, not for open source. If it truly were for open source it would have to be run a lot more like the BSD projects are and not like some corporation trying to keep their secrets all tied up by any means necessary. Even if it means crippling Darwin as an OS. If it were truly for open source, they wouldn't use a proprietary build system, either. I suppose we ought to be happy that we even get tarballs, but it doesn't mean I can't be bitter about it. While this may pass some suit's standard for open source, it is clearly not acceptable nor does it pass for what I consider "open source".

Done't know about this PC-BSD flavor of FreeBSD, but FreeBSD+Oracle has been done at version 5.x and before with Oracle 9i and before; http://ezine.daemonnews.org/200402/oracle.html http://www.scc.nl/~marcel/howto-oracle.html http://www.freebsd.org/cgi/getmsg.cgi?fetch=2143+6 531+/usr/local/www/db/text/2003/freebsd-database/2 0030309.freebsd-database I'd like to hear about Oracle 10g on FreeBSD or PC-BSD, any versions of the OS

Yes, there is. http://ezine.daemonnews.org/200302/fbsdscratch.htm l

First and foremost, read the handbook. This cannot be overstated. http://www1.uk.freebsd.org/doc/en_US.ISO8859-1/boo ks/handbook/

Bear in mind that, for a Linux user, FreeBSD will appear to behave most like Gentoo, particularly when building applications from ports. The actual inheritance was the other way around, but that hardly matters to this discussion.

The kernel config file is flat text, with the various options described in detail in the ${SRC}/sys/conf/NOTES and ${SRC}/sys/${ARCH}/NOTES files. Once you get used to it, nothing ever comes close to the ease of compiling new kernels IMHO. Just watch what depends on what, especially the COMPAT_??? options. Also, try not to use "custom" compiler flags like -ffast-math and -funroll-loops as you can end up with hard to diagnose problems when building from source.

Oh, and for anyone reading this thread who is saying "I only have one dsp device that gets locked and nothing else can use it," there is a sysctl knob which needs setting: hw.snd.pcm?.vchans which I usually set to 4 in /etc/sysctl.conf.

There's a lot of help to be had on the Usenet group comp.unix.bsd.freebsd.misc, too.

My last word on the subject is this: If you have an amd64 machine, for now I would use the i386 port (CPUTYPE=athlon64 in /etc/make.conf which will compile everything with -march=athlon-mp), especially if you use Firefox or you may end up rather frustrated. OpenOffice now works perfectly on amd64, as does JDK15 (albeit without the browser plugin) but native Firefox still has "issues" (startup hangs on a machine with an NFS mounted /home, hard locks, crashes to name but a few problems I have encountered) and plugins are rather flaky. I tend to use the 32bit Linux version on amd64, but the native i386 version has the most plugins available for it (win32codecs, Flash - you need a patch to make Flash7 work with the linuxpluginwrapper and native Firefox, see the message displayed when you install the port - et al). Also, there are no proprietary nVidia drivers for amd64 yet, which is not true for i386. This is being addressed in -CURRENT as nVidia have intimated that a key function they require is not present in the amd64 port and the devs are working on it, so the situation is set to change in the near future.

By the way, ports count at present is ~15500. That's 15.5 thousand services, applications, libraries and utilities available for the cost of typing "make install clean".

Users in demanding fields such as biosciences or meteorology do hack OS kernels to slim them down, alter the balance between throughput and computing, and to open them to the resources of a massive grid.

*Extremely* old news.

Also, "Mac OS X" has ALWAYS been proprietary. It's sensationalistic and shoddy journalism to say that "Mac OS X is now closed". Mac OS X has ALWAYS been closed. It's Darwin that has been open. And "Darwin" is more than a bootable OS: Darwin is Apple's open source strategy AND an OS; but the usefulness has always come from the open source components of the OS, not the usefulness of Darwin as an OS itself. Darwin's usefulness as an OS is, shall we say, "limited" at best, and always has been.

This has been beaten to death on the darwin-dev list, and there is no new information. Apple has taken no new recent action whatsoever, and in fact, the most recent action is that it has opened up more source code in the x86 tree, not less. Indeed, all of the traditional Darwin source with the notable exception of the kernel itself:

The thing that's not open in the x86 tree is xnu (the kernel), and it's not possible to create a fully bootable binary x86 Darwin OS, as it is for PPC. In the Darwin/OpenDarwin community, this has been discussed for months.

In fact, this article by Rob Braun (formerly of Apple, and a member of the OpenDarwin core team) was published in February 2006: http://ezine.daemonnews.org/200602/apple.html. This was then covered on slashdot, to which Rob issued this response: http://www.opendarwin.org/~bbraun/slashdot_respons e.html. These two discussions cover the issues very well.

I predict, however, that this Macworld UK article will be seen as "new news", and will be picked up by the tech outlets, and trumpeted, exactly as the headline hopes, as "Apple closes down OS X", even though the source for pretty much everything (except the kernel and drivers) is still available. In other words, everything that a normal person needs Darwin sources for is available. In 5 years, I can think of ONE instance where I looked to the kernel source for confirmation of something, and that was only for *confirmation*, and only because it was convenient - not because I needed to rebuild the kernel. I know of no other non-developer/programmer Mac OS X adminisrators/system engineers/enterprise users who have ever had any reason to rebuild the kernel or any drivers.

If the kernel and driver source were available, it would, however, be used for one purpose: to churn out hacks to get OS X to run on non-Apple hardware in a much faster and higher-quality way than has been possible to date. Will OS X be hacked anyway to run on non-Apple hardware, and will it continue to be, regardless? Yes. If people are willing to replace enough of the OS with the ugliness they're using to get it to work, absolutely. But it will continue to be ugly. Releasing kernel and driver source for the current iterations of OS X on x86 will only make their jobs infinitely easier, while brining little to no benefit to conventional users, power users, and administrators of OS X.

I'm sure people will find a way to make a huge deal about this, though, even though a huge deal has already been made about it in various forums, including slashdot and other tech news outlets, and on several of Apple's mailing lists.

I'd like to point out that this was my initial reaction: http://listserv.cuny.edu/Scripts/wa.exe?A2=ind0602 &L=macenterprise&T=0&P=58970

Since then, Apple has posted all of the APSL sources, and it was just a legitimate, honest delay. The PPC and x86 trees are at virtual parity with the sole exception of the kernel and drivers. So I'd submit that "Apple closes down OS X" is highly inaccurate for two reasons:

- Most of OS X was never "open" to begin with; if he wants to say "Darwin", great, but I suppose "Apple closes down Darwin" wouldn't be as sensationalistic and guaranteed to get as many page v

Ok, so it's unlikely to happen anyways - but if one were to toy around with the thought that Macs would rise to take a significant portion of the operating systems used, what would that mean? Not much, from my point of view. It would just mean new vendor lock-in, and probably even worse interoperability as the Apple specific formats become more common. While today WMA, DOC, XLS and PPT are enough trouble, we'd add AAC, CWK, SIT and what have you to the list. DRM will be just as common and prevalent (witness Fairplay and iTunes).

I'll readily admit that I don't know much about Macs and the formats that are used, maybe most are or are becoming open - I just know that every so often I get a file I can't open from a Mac user (yesterday, an AppleWorks file was the most recent). It was the same when I used Windows, so apparently little has changed over the years. That I can open MS files is just because the community has been so hard at work deciphering the formats and reimplementing them. If Apple becomes any more common, the community possibly would have to start over.

The way that Apple has handled any open source connections to their OS and other products quite clearly shows that they only want to take advantage of it, not contribute back [1] [2] [3]. While open standards and open source is not the same thing, and standards is IMO more important, they share a lot of common attributes and philosophy behind. I don't think Apple is interested in either.

It's quite possible that Apple makes a great OS, and great hardware, but it is also quite clear that they are just as predatory and monopolistic as ever Microsoft - they just haven't had the numbers to make the same impact. And I couldn't care which vendor tries to lock me hard to their platform and their DRM, it's all bad in either case. Until Apple decides to play fair with the rest of the world I won't be thinking any better of them than I do MS - being the underdog does not excuse bad behaviour, nor does "but they are doing it".

Being pragmatic to me does not only mean "use what works" it also means looking at what "will work" - and what will continue to do so.

(PS, I can't get a new, open format copy of the cwk file I received until the end of April due to vacations - anyone know of anything that can read this format on a Linux system? Thanks. DS)

It'd be handy to have a uniform way to restrict the bandwidth of apps.

You are reading Slashdot on a free day pass. Thanks for the support.
BSD: NetBSD's Real-Time Network Backup
Posted by ScuttleMonkey in The Mysterious Future!
from the old-hardware-power dept.
                        jschauma writes "One of NetBSD's developers, der Mouse, was interviewed by DaemonNews about his real-time network backup system (originally presented at BSDCan 2005), where changes to your local filesystem are automatically propagated to a backup server. In his interview der Mouse tells about his idea, how it works, and of course, how cool it is."

http://ezine.daemonnews.org/200602/apple.html

Thanks Apple! Oh and before you cry Troll about the article do some basic research on the author.

http://ezine.daemonnews.org/200602/apple.html

This "prior art" did not count as it was unpublished. However the point about the mathematics is exactly correct. Shamir is one of the the greatest trinity of conmen to ever plauge the computer industry. If you ever want to know why you still don't have encrypted email, this guy is 33.33333....% of the reason.

Dude, 2000 called. They want their excuse back.

The first copy of PGP was released in 1991 [1]

The RSA patent expired in 2000. If you're in the US. I don't believe it was patented elsewhere. [2]

I seem to remember GNU Privacy Guard working OK around 2000 [3]. Want to think of another reason why no one is encrypting email?

The new rc.d system is equally sysadmin-friendly as the SysV equivalent. FreeBSD adopted it as well.

The BSDs don't have the fragmentation that Linux has.

FreeBSD 4.x
FreeBSD 5.x
NetBSD
DragonFlyBSD
OpenBSD

which one should I choose for SAP ?

http://ezine.daemonnews.org/200007/SAP_meets_BSD.h tml

To avoid giving you the wrong impression, FreeBSD is in no way supported by SAP, and (unfortunately) probably never will be! Installing SAP R/3 for Linux under FreeBSD is highly UNOFFICIAL and a proof of concept only! Even SAP R/3 for Linux is only supported on certain HW-configurations and under RH6.1 EE.

But it works nevertheless :-)

There's still issues with FreeBSD that make it unsuitable for desktop use (I realize that's probably going to be modded a troll, so I'd like to point out the following example: http://support.daemonnews.org/viewtopic.php?p=995
). These need to be addressed before it can even really come out of the server corner, if that's their intention.

(Note: The page might be down at the moment, but try again and it should eventually come up)

FYI, here is a tutorial on how to do that.

Apparently, one week when Fry's had a sale with the K7S5A Pro, the next week, half the return line was carrying that exact box.

http://www.daemonnews.org/200104/bsd_family.html

Good News Everyone!
Mike Smith now works for Apple, whose OS is based on BSD.
Check it out: www.lemis.com/~grog/msmr.html
and at: daemonnews, under "BSD at Apple"
He didn't like the direction that v5 was taking so he quit and starting writing BSD code for Apple, where he is still works today.

Good News Everyone!
Mike Smith now works for Apple, whose OS is based on BSD.
Check it out: www.lemis.com/~grog/msmr.html
and at: daemonnews, under "BSD at Apple"
He didn't like the direction that v5 was taking so he quit and starting writing BSD code for Apple, where he is still works to this day.

Since the introduction of the FreeBSD-5 branch, FreeBSD enthusiasts have been eagerly awaiting the day when the new codebase would stabilize. After much development and four previous releases, FreeBSD-5 has finally gone stable with version 5.3. But don't mistake a stable codebase with stable software. While the development team will no longer accept major changes to the base system, FreeBSD 5.3 still has bugs and problems.

FreeBSD is a complete Unix-like operating system entirely developed by a single large team of programmers. This is in stark contrast to GNU/Linux which, as a complete operating system, has no central, cohesive developer base and is packaged in myriad different ways by myriad different distribution projects and companies; and proprietary Unixes, which are closed-source, restrictively licensed, and work on a comparatively small number of usually proprietary hardware architectures. FreeBSD has historically been clean, fast, reliable, and scalable. It's easy to use, learn, set up, and navigate from the command line, has more than 10,000 software programs in the Ports system, runs on a wide variety of hardware, and can easily be used for either a desktop or a server.

The transition to 5.x

Until the release of 5.3, the most recent "production release" was the FreeBSD-4 series, which is presently at version 4.10 and has been deemed the "Legacy" release in the wake of the 5.x branch going to STABLE. FreeBSD-5 was supposed to be a grand introduction of new technology -- a revolutionary improvement to the tried and true 4.x branch -- but soon after it left the gate, it got caught up in developer politics and failed implementations of too-ambitious theories among other questionable design decisions, causing some developers to fork the FreeBSD-4 project into a separate and more focused operating system.

The ULE (which is not an acronym; its full name is SCHED_ULE as opposed to the older SCHED_4BSD) scheduler continues to have stability and performance problems and was totally disabled instead of being made the default process scheduler in 5.3 as planned. The mix of threading subsystems still yields problems with efficiency and stability. Also, the networking subsystem may now be multithreaded and therefore faster on SMP systems, but users with some implementations of the 3Com (SysKonnect/Yukon) gigabit LAN chip are now unable to access their network at all because of new bugs that have popped up in the driver; other SysKonnect/Yukon users have problems under heavy network traffic, along with those using Intel Pro/1000 chips. Unfortunately all of our test systems use these network chips for onboard LAN; coincidentally they are two of the most popular gigabit LAN chipsets used on modern motherboards from major manufacturers. We also experienced lockups during boot if a custom-compiled kernel did not have SMP enabled on a Hyper-Threaded computer. A list of these and other errata can be found right here.

Considering the long list of significant problems in FreeBSD 5.3-RELEASE, it would seem irrational to recommend that anyone switch a production server from 4.x or any previous known-working 5.x release to 5.3. Just the same, the FreeBSD project maintains a migration guide for this purpose.

A lost lead

Since the introduction of the FreeBSD-5 branch, FreeBSD enthusiasts have been eagerly awaiting the day when the new codebase would stabilize. After much development and four previous releases, FreeBSD-5 has finally gone stable with version 5.3. But don't mistake a stable codebase with stable software. While the development team will no longer accept major changes to the base system, FreeBSD 5.3 still has bugs and problems.

FreeBSD is a complete Unix-like operating system entirely developed by a single large team of programmers. This is in stark contrast to GNU/Linux which, as a complete operating system, has no central, cohesive developer base and is packaged in myriad different ways by myriad different distribution projects and companies; and proprietary Unixes, which are closed-source, restrictively licensed, and work on a comparatively small number of usually proprietary hardware architectures. FreeBSD has historically been clean, fast, reliable, and scalable. It's easy to use, learn, set up, and navigate from the command line, has more than 10,000 software programs in the Ports system, runs on a wide variety of hardware, and can easily be used for either a desktop or a server.

The transition to 5.x

Until the release of 5.3, the most recent "production release" was the FreeBSD-4 series, which is presently at version 4.10 and has been deemed the "Legacy" release in the wake of the 5.x branch going to STABLE. FreeBSD-5 was supposed to be a grand introduction of new technology -- a revolutionary improvement to the tried and true 4.x branch -- but soon after it left the gate, it got caught up in developer politics and failed implementations of too-ambitious theories among other questionable design decisions, causing some developers to fork the FreeBSD-4 project into a separate and more focused operating system.

The ULE (which is not an acronym; its full name is SCHED_ULE as opposed to the older SCHED_4BSD) scheduler continues to have stability and performance problems and was totally disabled instead of being made the default process scheduler in 5.3 as planned. The mix of threading subsystems still yields problems with efficiency and stability. Also, the networking subsystem may now be multithreaded and therefore faster on SMP systems, but users with some implementations of the 3Com (SysKonnect/Yukon) gigabit LAN chip are now unable to access their network at all because of new bugs that have popped up in the driver; other SysKonnect/Yukon users have problems under heavy network traffic, along with those using Intel Pro/1000 chips. Unfortunately all of our test systems use these network chips for onboard LAN; coincidentally they are two of the most popular gigabit LAN chipsets used on modern motherboards from major manufacturers. We also experienced lockups during boot if a custom-compiled kernel did not have SMP enabled on a Hyper-Threaded computer. A list of these and other errata can be found right here.

Considering the long list of significant problems in FreeBSD 5.3-RELEASE, it would seem irrational to recommend that anyone switch a production server from 4.x or any previous known-working 5.x release to 5.3. Just the same, the FreeBSD project maintains a migration guide for this purpose.

Since the introduction of the FreeBSD-5 branch, FreeBSD enthusiasts have been eagerly awaiting the day when the new codebase would stabilize. After much development and four previous releases, FreeBSD-5 has finally gone stable with version 5.3. But don't mistake a stable codebase with stable software. While the development team will no longer accept major changes to the base system, FreeBSD 5.3 still has bugs and problems.

FreeBSD is a complete Unix-like operating system entirely developed by a single large team of programmers. This is in stark contrast to GNU/Linux which, as a complete operating system, has no central, cohesive developer base and is packaged in myriad different ways by myriad different distribution projects and companies; and proprietary Unixes, which are closed-source, restrictively licensed, and work on a comparatively small number of usually proprietary hardware architectures. FreeBSD has historically been clean, fast, reliable, and scalable. It's easy to use, learn, set up, and navigate from the command line, has more than 10,000 software programs in the Ports system, runs on a wide variety of hardware, and can easily be used for either a desktop or a server.

The transition to 5.x

Until the release of 5.3, the most recent "production release" was the FreeBSD-4 series, which is presently at version 4.10 and has been deemed the "Legacy" release in the wake of the 5.x branch going to STABLE. FreeBSD-5 was supposed to be a grand introduction of new technology -- a revolutionary improvement to the tried and true 4.x branch -- but soon after it left the gate, it got caught up in developer politics and failed implementations of too-ambitious theories among other questionable design decisions, causing some developers to fork the FreeBSD-4 project into a separate and more focused operating system.

The ULE (which is not an acronym; its full name is SCHED_ULE as opposed to the older SCHED_4BSD) scheduler continues to have stability and performance problems and was totally disabled instead of being made the default process scheduler in 5.3 as planned. The mix of threading subsystems still yields problems with efficiency and stability. Also, the networking subsystem may now be multithreaded and therefore faster on SMP systems, but users with some implementations of the 3Com (SysKonnect/Yukon) gigabit LAN chip are now unable to access their network at all because of new bugs that have popped up in the driver; other SysKonnect/Yukon users have problems under heavy network traffic, along with those using Intel Pro/1000 chips. Unfortunately all of our test systems use these network chips for onboard LAN; coincidentally they are two of the most popular gigabit LAN chipsets used on modern motherboards from major manufacturers. We also experienced lockups during boot if a custom-compiled kernel did not have SMP enabled on a Hyper-Threaded computer. A list of these and other errata can be found right here.

Considering the long list of significant problems in FreeBSD 5.3-RELEASE, it would seem irrational to recommend that anyone switch a production server from 4.x or any previous known-working 5.x release to 5.3. Just the same, the FreeBSD project maintains a migration guide for this purpose.

A l

http://ezine.daemonnews.org/200405/bsdcan_2004/bsd can_2004-Pages/Image5.html or http://ezine.daemonnews.org/200405/bsdcan_2004/bsd can_2004-Pages/Image90.html or maybe http://ezine.daemonnews.org/200405/bsdcan_2004/bsd can_2004-Pages/Image87.html
would be better suited to your needs.

http://ezine.daemonnews.org/200405/bsdcan_2004/bsd can_2004-Pages/Image5.html or http://ezine.daemonnews.org/200405/bsdcan_2004/bsd can_2004-Pages/Image90.html or maybe http://ezine.daemonnews.org/200405/bsdcan_2004/bsd can_2004-Pages/Image87.html
would be better suited to your needs.

http://ezine.daemonnews.org/200405/bsdcan_2004/bsd can_2004-Pages/Image5.html or http://ezine.daemonnews.org/200405/bsdcan_2004/bsd can_2004-Pages/Image90.html or maybe http://ezine.daemonnews.org/200405/bsdcan_2004/bsd can_2004-Pages/Image87.html
would be better suited to your needs.

Yup, FreeBSD is dead and confirmed by Netcraft. Too bad it can't detect my hardware properly. Or maybe the hardware can't detect FreeBSD.

I'm rather amused to see Sun be the first to implement a replacement for the old init and have it done.

FreeBSD is a complete Unix-like operating system entirely developed by a single large team of programmers. This is in stark contrast to GNU/Linux which, as a complete operating system, has no central, cohesive developer base and is packaged in myriad different ways by myriad different distribution projects and companies; and proprietary Unixes, which are closed-source, restrictively licensed, and work on a comparatively small number of usually proprietary hardware architectures. FreeBSD has historically been clean, fast, reliable, and scalable. It's easy to use, learn, set up, and navigate from the command line, has more than 10,000 software programs in the Ports system, runs on a wide variety of hardware, and can easily be used for either a desktop or a server.

The transition to 5.x

Until the release of 5.3, the most recent "production release" was the FreeBSD-4 series, which is presently at version 4.10 and has been deemed the "Legacy" release in the wake of the 5.x branch going to STABLE. FreeBSD-5 was supposed to be a grand introduction of new technology -- a revolutionary improvement to the tried and true 4.x branch -- but soon after it left the gate, it got caught up in developer politics and failed implementations of too-ambitious theories among other questionable design decisions, causing some developers to fork the FreeBSD-4 project into a separate and more focused operating system.

The ULE (which is not an acronym; its full name is SCHED_ULE as opposed to the older SCHED_4BSD) scheduler continues to have stability and performance problems and was totally disabled instead of being made the default process scheduler in 5.3 as planned. The mix of threading subsystems still yields problems with efficiency and stability. Also, the networking subsystem may now be multithreaded and therefore faster on SMP systems, but users with some implementations of the 3Com (SysKonnect/Yukon) gigabit LAN chip are now unable to access their network at all because of new bugs that have popped up in the driver; other SysKonnect/Yukon users have problems under heavy network traffic, along with those using Intel Pro/1000 chips. Unfortunately all of our test systems use these network chips for onboard LAN; coincidentally they are two of the most popular gigabit LAN chipsets used on modern motherboards from major manufacturers. We also experienced lockups during boot if a custom-compiled kernel did not have SMP enabled on a Hyper-Threaded computer. A list of these and other errata can be found here.

Considering the long list of significant problems in FreeBSD 5.3-RELEASE, it would seem irrational to recommend that anyone switch a production server from 4.x or any previous known-working 5.x release to 5.3. Just the same, the FreeBSD project maintains a migration guide for this purpose.

A lost lead

FreeBSD 5.x enjoyed an excellent head start in the fully 64-bit AMD64 operating system arena, but now trails

Thu. 9 Dec. 2004 - Looks like Daemon News's support forum site has been hacked. Anyone know anything about it? No, not about the NetBSD logo change exactly, but it IS a logo change of sorts, no? ;)

The times.allow and times.deny entries consist of a comma-separated list
of time periods during which the users in a class are allowed to be
logged in. These are expressed as one or more day codes followed by a
start and end times expressed in 24 hour format, separated by a hyphen or
dash. For example, MoThSa0200-1300 translates to Monday, Thursday and
Saturday between the hours of 2 am and 1 p.m.. If both of these time
lists are empty, users in the class are allowed access at any time. If
times.allow is specified, then logins are only allowed during the periods
given. If times.deny is specified, then logins are denied during the
periods given, regardless of whether one of the periods specified in
times.allow applies.

You could also use AuthPF and a cron script to write and remove /etc/nologin. from the system at given times.

## ADJUST TO TASTE - they're your kids! ##

0 14 * * * rm /etc/nologin
# go ahead and use computer till 4p. Then we have dinner
# and you kids do homework not needing online time
0 16 * * * touch /etc/nologin
# alright, chat with your friends for a bit or finish up your homeword
0 20 * * * rm /etc/nologin
# no more. Say goodnight to your friends and hit the sack!
30 21 * * * touch /etc/nologin

Remember root can login anytime (can also be overridden on individual accounts through login.conf with ignorenologin. You'll need to periodically check and force logouts (after a winpopup warning) based on the existence of this file.

You could modify the firewall/NAT rules directly via cron or some other method to your choosing (report cards online? Screenscrape the results and allow an extra hour for each grade point above a B-...)

You could block services on an individual basis. Web allowed all the time but chatting only from 2000-2100?? No filesharing untill after dinner?

There may be a PAM module that will restrict login based on time of day, week, etc.

You could use user accounting to record how much time they spend online. A weekly review with them.... You could restrict usage to hours/day, hours/week or whatever. When the time is all used up, access get's locked.

or has BSD been getting a heck of a lot of stories on the main page lately

It's like they haven't been listening to the trolls at all

--

I write stuff, but not that well and not that often...

In a traditional unix environment sudo is nifty, however, with FreeBSD we have had powerful ACLs for quite some time; enabled by default in 5.x, so no need for patches.
With it you have better control, it's more dynamic and powerful. At first it may look complex, but you will develop understanding of them really fast, and it will be well worth it.
Try it out.

Good News Everyone!
Mike Smith now works for Apple, whose OS is based on BSD.
Check it out: www.lemis.com/~grog /msmr.html
and at: daemonnews, un der "BSD at Apple"
He didn't like the direction that v5 was taking so he quit and starting writing BSD code for Apple, where he is still works today (last checked Aug 1, 2004).

Good News Everyone!
Mike Smith now works for Apple, whose OS is based on BSD.
Check it out: www.lemis.com/~grog/msmr.html
and at: daemonnews, under "BSD at Apple"
He didn't like the direction that v5 was taking so he quit and starting writing BSD code for Apple.

Why would anybody "steal" BSD? I don't know, perhaps you should ask microsoft:
http://www.daemonnews.org/200108/dadvocate.html Granted, it doesn't seem like they've done much modification of it, but it has helped the march of their proprietary software.

Not trying to be negative, but is the base system & kernel open sourced from Apple or didn't Apple take somebody else's work and lock it down? In other words I have the understanding that Apple took FreeBSD which is somebodyelses hard work and added their own stuff on top without releasing the stuff on top or how it interacts with the stuff provided by FreeBSD, or any changes they might have made to FreeBSD to make it better.

Apple bought a company called NeXT that had a proprietary BSD386 based OS running on the Mach Micro-Kernal. In the company was an employee who had done a large amount of the original work creating the Mach Micro-kernal. Apple took the NeXTStep / OpenStep operating system as the basis for its Mac OS X operating system. Apple ported it to the PowerPC Chip sets, fused it with knowledge gained from Apple's earlier Unix OSes A/UX and MkLinux and then re-synced the userland with FreeBSD 4.x (now they sync the userland to FreeBSD 5.x).

This might need more explaining. Unlike Linux where all each distribution has the same Linix kernal (sometimes compiled in different ways, but still the same kernal code), BSD branches do NOT have the same kernal. NetBSD, FreeBSD, OpenBSD, DragonflyBSD and Darwin(Mac OS X) are each different kernal code bases. Sometimes they share components / code, but mostly they do not. The different branches are designed to provide the same working userland to users and applications. By "re-synced the userland to FreeBSD" Apple did little more then confirm their OS is compatible with FreeBSD and either updated their own /bin and/usr/bin applications to feature / function compatibility with FreeBSD or ported the FreeBSD apps over, whichever made the most sense. Again all work was done by Apple Engineers.

So what Apple did was not "take somebody else's work and lock it down" but rather take the work Apple Engineers and the Engineers of a second company Apple bought (and retained the employees of) and release the code for no cost onto the internet.

OpenDarwin.org

While this is certainly valid given the license of FreeBSD, strictly speaking that's just being a thief as far as I'm concerned.(Yes I know MS has done this too with it's Unix Services layer).

If someone gives something to you for free, it is not stealing. The only people who are allowed a moral objection to how you use the freely given object are the ones who gave it to you. Far from being upset at it, BSD users "shouted for joy" that Apple choose to base their new OS on BSD. Daemon News: Apple -- What's in it for BSD?

I also understand however, that Apple has given some changes back to the KDE community for the web browser, locking up other changes however behind a proprietary license. In other words it looks to me like Apple is trying to garner some favor while stealing the "open source" community blind.

Every single piece of OpenSource software Apple has used (irrespective of the license it was released under and the requirement, or NOT, to release the code) they have release the code to. The code is available either through the Darwin OS , one of the other Apple Open Source Projects, or by giving the code back to the original developers. In addition to that Apple has also released code that was never before opensource, with projects such as OpenPlay , Darwin Streaming Server and

Good News Everyone!
Mike Smith now works for Apple, whose OS is based on BSD.
Check it out: www.lemis.com/~grog/msmr.html
and at: daemonnews, under "BSD at Apple"
He didn't like the direction that v5 was taking so he quit and starting writing BSD code for Apple.

Good News Everyone!
Mike Smith now works for Apple, whose OS is based on BSD.
Check it out: www.lemis.com/~grog/msmr.html
and at: daemonnews, under "BSD at Apple"
He didn't like the direction that v5 was taking so he quit and starting writing BSD code for Apple.

Yes, "BSD" has a pre-emptive kernel. BSD/OS has a pre-emptive kernel. BSDi was bought by Walnut Creek and they are providing a snapshot of their code to the FreeBSD team who is using some of the BSDi team's work to make their own kernel pre-emptive, as well. Please see "Revamping the BSD multiprocessor code" at http://www.daemonnews.org/200008/dadvocate.html

You can also see a good argument against it, dating back to 2000 from Matt Dillon:
"I would not characterize this as 'biting the bullet'. Having a preemptive kernel is unlikely to improve performance. The only reason there might be preemption at all is to deal wth interrupts. Interrupts currently preempt supervisor code. If interrupts are moved to interrupt threads then interrupt threads would need to be able to preempt supervisor code. In this fashion the supervisor thread would be preempted, but that is very different from having supervisor threads preempt other supervisor threads (something we probably will not do)."
See http://docs.freebsd.org/cgi/getmsg.cgi?fetch=65989 +0+archive/2000/freebsd-arch/20000528.freebsd-arch

Actually, the whole discussion is very interesting and I have learned a lot this morning about SMP and preemption and so on from reading. Thanks for bringing this up. :)

Here's a full article at daemonnews about the history of postgresql.

It would be interesting if someone would benchmark these, noting the similarities and differences between the two now that ingres is open source. Also, maybe the pgsql development team could learn a thing or two by studying what CA did with ingres over the years. Maybe there is still some common code and design paradigms left between the two.

Good News Everyone!
Mike Smith now works for Apple, whose OS is based on BSD.
Check it out: www.lemis.com/~grog/msmr.html
and at: daemonnews, under "BSD at Apple"
He didn't like the direction that v5 was taking so he quit and starting writing BSD code for Apple.