I wouldn't consider *BSD as rivals to anything, just providing ourselves with a superior replacement for the currently available technology and make it available to the public.
Unlike the Linux/GPL camp who's enemy is everyone trying to make a living by writing software, we're just trying to write the best stuff for our own business and personal use.
We're not rivals with anyone, just sorry you guys are all so lost.:)
FFS is actually the "Fast File System" not "FAT Fast file System", the author should have done more research.:)
UFS provides the naming layer/policy of the filesystem. FFS provides for the block allocation and metadata policies.
The "traditional UNIX filesystem" was called something like "ss5", it was the one with inodes all at one end of the disk and practically no policy for reducing fragmentation. It was terrible, after a short period of heavy disk usage the FS would be as fragmented as badly as MS-DOS FAT and disk bandwidth would be limited to something like 3% of the actual disk speed.
FFS was a rewrite of the block allocation and disk layout to avoid the serious problems with "ss5". FFS tries to make sure that inodes and data are allocated in the same area, this is to reduce seeking. Along with those enhancements IO clustering was added, recently softupdates and snapshots.
Oh, and the dipstick that said "snapshots" were
dangerous needs to get a clue. Snapshots provide for taking a view into the filesystem almost like a freeze frame.
The FreeBSD Project (http://www.FreeBSD.org/) has at least 20 kernel programmers who usually jump at the chance to work with small and large companies to address bugs and scalability issues with FreeBSD.
We've worked with Hotmail, Yahoo and many more.
Since each committer has access and the ability to modify the system, companies that choose to contact a FreeBSD developer can sometimes have thier fix in the base system in a matter of hours.
Most will do it for free, but all probably would appreciate some sort of hardware or beer donation.
The FreeBSD project is always looking for developers, depending on your interest/skill level you can be involved in many things dealing with the project.
You can port applications to FreeBSD, this gives you a chance to collaborate with other open source projects.
You could wind up working on the base system, a niche project (PicoBSD, TrustedBSD, etc) or the kernel.
Or you could write and correct documentation in the system and the website.
Your criteria for OS selection seems to be flawed.
The more support offered the better, I don't have all the time in the world to fix/patch/debug the systems myself.
The expansion of BSDI is a great thing, it'll give me a 'one stop freebsd shop' that I can depend on for my systems. And I'll be a much happier sysadmin, I'm sick and tired of all the do-it-yourself stuff already, I need to get _real work_ done and anyone else wanting to do the same (getting work done) would see this as a good thing .
I really can't understand how one could enjoy the feeling of getting a new server without FreeBSD pre-installed, it's a nightmare of worry (will it work? will it boot? will it be stable?)
It may be a foreign agency, lame script kiddies or talented network engineers that are causing these attacks.
The point is that at least people are finally taking notice of the effects lax filtering is causing on the internet as a whole.
CERT was formed to provide rapid responce to exploits, it's time an agency was formed by the major backbone providers (and NOT any government body) to enforce filtering agaist outgoing spoofing traffic.
The consequence of being the source of a DoS should be simple, fix it within an 30 minutes or your upstream pulls the plug until _you fix it_.
There is just _no excuse_ for tolerating this anymore. This means being the source of spoofed packets _or_ a network that responds to broadcast icmp/udp/whatever with more that X (16?) number of replies (DoS amplifier) should be grounds for removing your clueless hide from the ether until you prove your connectivity is not a hazard to the rest of the net.
Justifying no filtering to maintain speed is bogus, and I think this week has pretty much proven that action needs to be taken quickly and the penalties enforced quickly and severely enough to force accountability.
Linux is not committed to following unix standards, it's "sort-of posix" "sort-of unix" it's really none-of-the-above.
I applaud Linux on having the gall to step up and say "these standards are stupid and holding us back", however in the same breath they are ditching the guarantees that unix promises.
Linux is _not_ unix, don't fool yourself.
Specific examples include write atomicity, and FS stability issues.
They already do, if you haven't seen it, then it's been bought out. There should be "FreeBSD Powerpacks" available at most major software retailers. If they don't have it, then ask.
You may have had the FreeBSD box with the default mount options. The default options force sync file creation and deletes requiring blocking IO for every file created or deleted. While this is slower it is safer than completely async mounts.
Softupdates (introduced a year ago) solve this problem by forcing safe ordering to meta-data operations (directory manipulation) while keeping it mostly async, if it's possible you may want to check out freebsd again and enable the option.
Of course my recomendation is: use what works best for you.
The bzImage+initrd patch (bzImage is an extension to load kernels directly above 1 MB, which allows kernels sizes of up to approximately 2 MB) can be found at ftp://lrcftp.epfl.ch/pub/people/almesber/lilo/bz Image+initrd-1.3.71.patch.gz and ftp://elserv.ffm.fgan.de/pub/linux/loadlin-1.6/b zImage+initrd-1.3.71.patch.gz
> Why? You're blaming an OS for what's obviously your ignorance. That'd be like me saying "FreeBSD sucks 'cause > ipchains doesn't work on it, so I had to format and reinstall Linux."
Ok, I suck as an RedHat admin, can you please detail the proper way to do such an upgrade?
> Admin incompetence is hardly RH's fault, now is it?
It was the first time I'd used RH. I had no docs handy and just got a lot of sarcasm on #redhat and ignored on #linux. I did get the box back up and working totally remotely and I was eventually able to fix the problem entirely...:)
>> These people can directly modify the kernel archives, or must all thier work be filtered >> through Linus and or Alan Cox? > > Some of them are the Linux equivalent of -core, yes. Keep in mind that, technically, even Alan has to filter his work > through Linus--Linus keeps the one tree on his hard drive, and everything goes through him. However, there is an > equivalent of -core from whom he accepts patches w/o question. Dave Miller / Alan Cox for networking, > Ted T'so for ext2, etc. Some of the mentioned people above besides Ted T'so fit that.
Interesting, you are aware that there are over one hundred fifty FreeBSD developers with commit access, there is no Linus like bottleneck.
>>>> Also, could you please explain how you managed to put "SGI" and "great minds" in >>>> the same sentance? >>> >>> Was it last week or two weeks ago that freebsd-hackers was all in a tizzy >>> because XFS is GPLed, making it difficult for you guys to steal the code? Make >>> up your mind here. >> >> It was mostly people unaware of the major new features that will be incorperated into FFS >> that were "in a tizzy". > > Ah. Surely that explains why there's still a XFS on *BSD effort underway.
Sure why not? Improvements are expected.
>> In so far as "stealing code" I don't see where "stealing" comes into the picture unless you >> define Linux as "stealing" it as well. > > Nothing derogatory was meant by "steal." I'd have a lot less respect for *BSD (or Linux, for that matter) > if you refused to use the code and instead tried to implement it from the ground up.
Here's where I take exception to you, Anonymous Coward, that's quite a strong accusation "stealing code", I expected you to back down when I called you on it.
>> Hypocrite, if it bothers you so then go closed source. > > See above. You totally misunderstood me.
What do you mean "see above"? You said "stealing code" you didn't apologize for it, you say I misunderstand you? No, I totally see through you, you are a flame spouting weenie without the courage to put a name behind your weak accusations.
Nothing derogatory meant by "weenie" of course.:)
> As for hypocricy, I'm still not the camp bad-mouthing SGI while > simultaneously lusting after their products and lamenting that the used the evil GPL instead of the righteous BSD > license on them.
I'm not lusting for XFS and niether was I complaining about the GPL, if you choose to throw a "holy tantrum" over licenses when the issue was never on the table I will just note it... and ignore it.:)
>> What's really upsetting is that while replying to this I forgot what the initial Slashdot article >> was about. In effect you win, your lies and misinfomation have clouded whatever joy and >> prestige the artcle brought me, rejoice in yourself "Anonymous Coward", the title fits you well. > > If you worked on your reading comprehension, you wouldn't have gotten all upset.
If you hadn't made such venomous accusations along with delusional observations I wouldn't have become upset, go soak your head Anonymous Coward.
I wonder what you think the benifit of your slander is and I can't understand where you got "FreeBSD failed"
First off, Applixware is in its final testing stages for a native FreeBSD port.
At least two major database companies are planning on native FreeBSD ports, or maybe FreeBSD friendly Linux ports of thier enterprise software.
Xig continues to support FreeBSD's 3.x and 4.x lines with version 5 of their software, it is unfortunate that they got burned on the CDE issue but who really wants CDE?
As long as ISVs are coding for Linux there will be people running those applications via the linux-activator in FreeBSD.
The FreeBSD project is currently in contact with many ISVs with the goal of creating FreeBSD-friendly linux apps. This allows a "code once, compile twice" system where everyone wins.
As far as the shrinking market share is objective, there is a larger market now than ever. One percent of 10,000,000 is larger than two percent of 1,000,000.
Oh, and besideds that, I think you are talking out of your rear-end, but that's just me.:)
It's easy to post under Anonymous Coward, if the shoe fits, wear it.
FUD from yet another Anonymous Wanker: > FreeBSD has lost..... yadda yadda yadda..
I can't speculate too much on FreeBSD growth except to say that a threefold increase in users is probably what has happened in the last year.
A simple indicator, channel logs on #freebsd on efnet available at: http://www.emsphone.com/stats/freebsd.html
The yearly graph shows over a threefold increase in the people coming onto to IRC to talk about and ask questions about FreeBSD.
CDrom sales are up according to friends at WC.
Anonymous Coward, the name fits you too well, for someone who may stating facts I'm suprised you aren't inclined to back it up by revealing your identity.
The future may belong to Linux, but I'm sure you won't be welcome there.
I'm confused about your claim of information hiding, the BSD rc system is quite simple and easy to use.
example:
-- Admin's log, colocation date 02/15/99: Old redhat 5.2 box experiancing synflood problems.
Download new linux kernel sources.
Compile, kernel to big for gzip, fight with bzip for smaller kernel image.
Compile and install.
Fight with Lilo.
Reboot.
Forgot to add routing... oops
Recompile and install.
Reboot.
Routing is enabled but Redhat's init system calls Linuxconf to probe the kernel for features, the call to get routing info has changed, box won't boot as Linuxconf brings up curses interface during boot and hangs until key pressed and then doesn't init the routing table.
Attempt to install new init RPMs, init RPMs require some other subsystems to be upgraded first.
Attempt to upgrade those systems via RPM, they in turn require more RPM.
Box is now down 2+ hours.
Get extremely irritated and manaully hack the init system.
Problem almost solved.
Install FreeBSD next day.
Problem finally solved.
End of admin's log 02/15/99. --
I'm not saying "make world" is the best thing out there, but it sure is more straight forward than the hassle that I endured with that Redhat box.
Draw your own conclusions. If RPMs or.deb of course:) work for you then more power to you. I'm sticking with what works for me.
>> I know of no professor with commit rights to the Linux kernel, could you elaborate please? > > Ted T'so at MIT, a bunch of people overseas (Remy Card, Arjen van de Ven, > Matt Kirkwood, a whole slew of Czechloslovakian profs, etc.)
These people can directly modify the kernel archives, or must all thier work be filtered through Linus and or Alan Cox?
>> Also, could you please explain how you managed to put "SGI" and "great minds" in >> the same sentance? > > Was it last week or two weeks ago that freebsd-hackers was all in a tizzy > because XFS is GPLed, making it difficult for you guys to steal the code? Make > up your mind here.
It was mostly people unaware of the major new features that will be incorperated into FFS that were "in a tizzy".
In so far as "stealing code" I don't see where "stealing" comes into the picture unless you define Linux as "stealing" it as well.
After all it is =open source=, how would incorperating and open source'd code base be considered stealing?
I'm extremely tired of hearing about *BSD "stealing code". The code is GPL'd, it is free according to the license that adorns the top of the file it is contained in. Hypocrite, if it bothers you so then go closed source.
FreeBSD already incorperates at least one GPL'd filesystem, EXT2FS without problems. The project just won't allow FFS to be retired for the extremely fragile and badly licensed XFS that SGI is pushing. It quite possibly will be added as an option as there is nothing stopping its integration.
What's really upsetting is that while replying to this I forgot what the initial Slashdot article was about. In effect you win, your lies and misinfomation have clouded whatever joy and prestige the artcle brought me, rejoice in yourself "Anonymous Coward", the title fits you well.
I know of no professor with commit rights to the Linux kernel, could you elaborate please?
In contrast the FreeBSD project has at least one professor, Alan Cox (at Rice University). No, he's not the Linux kern developer Alan Cox, but a different Alan Cox.
However both camps (FreeBSD and Linux) have people in acadamia in active development, why do you feel the need to mis-inform people?
Also, could you please explain how you managed to put "SGI" and "great minds" in the same sentance?
If you want to follow a faster track I suggest you try out FreeBSD-current. Many more features are available at the expense of the thorough testing the the -stable branch provides.
Here's a link that describes -current: http://www.freebsd.org/handbook/cutting-edge.htm l
Also, it should be noted that "-current" is not for newbies or people that aren't used to helping themselves or even providing fixes to problems that they encounter.
One of the benifits of developing applications for FreeBSD is the long term binary compatibility offered, it is almost unheard of to see a change go into FreeBSD-stable that would break current applications that are programmed correctly.
This gives ISVs the advantage of not having to worry about binary compatibility between minor (and usually major) versions of FreeBSD.
I also don't see why one would _want_ thier OS to change under thier feet almost daily, it sounds more like a punishment than a good thing imo.
-
Smoking from the wrong end of the pipe?
on
FreeBSDCon 99
·
· Score: 1
Please look at the last graph at:
http://www.emsphone.com/stats/freebsd.html
Just something actually tangible. The growth is actually pretty astounding.
I'm not sure if i'm more confused by your definition of 'shrinking' or why _every_ FreeBSD related post on slashdot turns into an OS holy-war.
I just wanted to thank CmdrTaco for the forum to share FreeBSD related news.
Oh, and my company is paying for my FreeBSDCON experiance! w00p!
How to use Vinum for the lazy and hopeless.
on
FreeBSDCon 99
·
· Score: 1
you just need to run "disklabel -e " then make a "clone of the 'c' partition called 'e', make the FStype 'vinum'
Slashdot Mirror
I wouldn't consider *BSD as rivals to anything, just providing ourselves with a superior replacement for the currently available technology and make it available to the public.
:)
Unlike the Linux/GPL camp who's enemy is everyone trying to make a living by writing software, we're just trying to write the best stuff for our own business and personal use.
We're not rivals with anyone, just sorry you guys are all so lost.
FFS is actually the "Fast File System" not "FAT Fast file System", the author should have done more research. :)
UFS provides the naming layer/policy of the filesystem. FFS provides for the block allocation and metadata policies.
The "traditional UNIX filesystem" was called something like "ss5", it was the one with inodes all at one end of the disk and practically no policy for reducing fragmentation. It was terrible, after a short period of heavy disk usage the FS would be as fragmented as badly as MS-DOS FAT and disk bandwidth would be limited to something like 3% of the actual disk speed.
FFS was a rewrite of the block allocation and disk layout to avoid the serious problems with "ss5". FFS tries to make sure that inodes and data are allocated in the same area, this is to reduce seeking. Along with those enhancements IO clustering was added, recently softupdates and snapshots.
Oh, and the dipstick that said "snapshots" were
dangerous needs to get a clue. Snapshots provide for taking a view into the filesystem almost like a freeze frame.
The FreeBSD Project (http://www.FreeBSD.org/) has at least 20 kernel programmers who usually jump at the chance to work with small and large companies to address bugs and scalability issues with FreeBSD.
We've worked with Hotmail, Yahoo and many more. Since each committer has access and the ability to modify the system, companies that choose to contact a FreeBSD developer can sometimes have thier fix in the base system in a matter of hours.
Most will do it for free, but all probably would appreciate some sort of hardware or beer donation.
--
The FreeBSD project is always looking for developers, depending on your interest/skill level you can be involved in many things dealing with the project.
You can port applications to FreeBSD, this gives you a chance to collaborate with other open source projects.
You could wind up working on the base system, a niche project (PicoBSD, TrustedBSD, etc) or the kernel.
Or you could write and correct documentation in the system and the website.
Best of luck,
I've sent an email to the author of the article explaining how the *BSD systems (particularly FreeBSD) are orginized. Waiting for an update. :)
Your criteria for OS selection seems to be flawed.
The more support offered the better, I don't have all the time in the world to fix/patch/debug the systems myself.
The expansion of BSDI is a great thing, it'll give me a 'one stop freebsd shop' that I can depend on for my systems. And I'll be a much happier sysadmin, I'm sick and tired of all the do-it-yourself stuff already, I need to get _real work_ done and anyone else wanting to do the same (getting work done) would see this as a good thing .
I really can't understand how one could enjoy the feeling of getting a new server without FreeBSD pre-installed, it's a nightmare of worry (will it work? will it boot? will it be stable?)
It may be a foreign agency, lame script kiddies or talented network engineers that are causing these attacks.
:)
The point is that at least people are finally taking notice of the effects lax filtering is causing on the internet as a whole.
CERT was formed to provide rapid responce to exploits, it's time an agency was formed by the major backbone providers (and NOT any government body) to enforce filtering agaist outgoing spoofing traffic.
The consequence of being the source of a DoS should be simple, fix it within an 30 minutes or your upstream pulls the plug until _you fix it_.
There is just _no excuse_ for tolerating this anymore. This means being the source of spoofed
packets _or_ a network that responds to broadcast icmp/udp/whatever with more that X (16?) number of replies (DoS amplifier) should be grounds for removing your clueless hide from the ether until you prove your connectivity is not a hazard to the rest of the net.
Justifying no filtering to maintain speed is bogus, and I think this week has pretty much proven that action needs to be taken quickly and the penalties enforced quickly and severely enough to force accountability.
God save us all.
Linux is not committed to following unix standards, it's "sort-of posix" "sort-of unix" it's really none-of-the-above.
I applaud Linux on having the gall to step up and say "these standards are stupid and holding us back", however in the same breath they are ditching the guarantees that unix promises.
Linux is _not_ unix, don't fool yourself.
Specific examples include write atomicity, and FS stability issues.
They already do, if you haven't seen it, then it's been bought out. There should be "FreeBSD Powerpacks" available at most major software retailers. If they don't have it, then ask.
If your original email to Nik was similar to this post you really can't blame him for tossing it in the bit bucket.
You may have had the FreeBSD box with the default mount options. The default options force sync file creation and deletes requiring blocking IO for every file created or deleted. While this is slower it is safer than completely async mounts.
Softupdates (introduced a year ago) solve this problem by forcing safe ordering to meta-data operations (directory manipulation) while keeping it mostly async, if it's possible you may want to check out freebsd again and enable the option.
Of course my recomendation is: use what works best for you.
--
From the file Documentation/initrd.txt:
z Image+initrd-1.3.71.patch.gz b zImage+initrd-1.3.71.patch.gz
The bzImage+initrd patch (bzImage is an extension to load kernels directly
above 1 MB, which allows kernels sizes of up to approximately 2 MB) can be
found at
ftp://lrcftp.epfl.ch/pub/people/almesber/lilo/b
and
ftp://elserv.ffm.fgan.de/pub/linux/loadlin-1.6/
there is or was an option for "make bzImage"
--
> Why? You're blaming an OS for what's obviously your ignorance. That'd be like me saying "FreeBSD sucks 'cause
> ipchains doesn't work on it, so I had to format and reinstall Linux."
Ok, I suck as an RedHat admin, can you please detail the proper way to do such an upgrade?
I'd like to know for future reference.
--
> Admin incompetence is hardly RH's fault, now is it?
:)
It was the first time I'd used RH. I had no docs handy and just got a lot of sarcasm on #redhat and ignored on #linux. I did get the box back up and working totally remotely and I was eventually able to fix the problem entirely...
*shrug*
--
>> These people can directly modify the kernel archives, or must all thier work be filtered
:)
:)
>> through Linus and or Alan Cox?
>
> Some of them are the Linux equivalent of -core, yes. Keep in mind that, technically, even Alan has to filter his work
> through Linus--Linus keeps the one tree on his hard drive, and everything goes through him. However, there is an
> equivalent of -core from whom he accepts patches w/o question. Dave Miller / Alan Cox for networking,
> Ted T'so for ext2, etc. Some of the mentioned people above besides Ted T'so fit that.
Interesting, you are aware that there are over one hundred fifty FreeBSD developers with commit access, there is no Linus like bottleneck.
>>>> Also, could you please explain how you managed to put "SGI" and "great minds" in
>>>> the same sentance?
>>>
>>> Was it last week or two weeks ago that freebsd-hackers was all in a tizzy
>>> because XFS is GPLed, making it difficult for you guys to steal the code? Make
>>> up your mind here.
>>
>> It was mostly people unaware of the major new features that will be incorperated into FFS
>> that were "in a tizzy".
>
> Ah. Surely that explains why there's still a XFS on *BSD effort underway.
Sure why not? Improvements are expected.
>> In so far as "stealing code" I don't see where "stealing" comes into the picture unless you
>> define Linux as "stealing" it as well.
>
> Nothing derogatory was meant by "steal." I'd have a lot less respect for *BSD (or Linux, for that matter)
> if you refused to use the code and instead tried to implement it from the ground up.
Here's where I take exception to you, Anonymous Coward, that's quite a strong accusation "stealing code", I expected you to back down when I called you on it.
>> Hypocrite, if it bothers you so then go closed source.
>
> See above. You totally misunderstood me.
What do you mean "see above"? You said "stealing code" you didn't apologize for it, you say I misunderstand you? No, I totally see through you, you are a flame spouting weenie without the courage to put a name behind your weak accusations.
Nothing derogatory meant by "weenie" of course.
> As for hypocricy, I'm still not the camp bad-mouthing SGI while
> simultaneously lusting after their products and lamenting that the used the evil GPL instead of the righteous BSD
> license on them.
I'm not lusting for XFS and niether was I complaining about the GPL, if you choose to throw a "holy tantrum" over licenses when the issue was never on the table I will just note it... and ignore it.
>> What's really upsetting is that while replying to this I forgot what the initial Slashdot article
>> was about. In effect you win, your lies and misinfomation have clouded whatever joy and
>> prestige the artcle brought me, rejoice in yourself "Anonymous Coward", the title fits you well.
>
> If you worked on your reading comprehension, you wouldn't have gotten all upset.
If you hadn't made such venomous accusations along with delusional observations I wouldn't have become upset, go soak your head Anonymous Coward.
--
> shrinking marketplace... yadda.. yadda..
:)
I wonder what you think the benifit of your slander is and I can't understand where you got "FreeBSD failed"
First off, Applixware is in its final testing stages for a native FreeBSD port.
At least two major database companies are planning on native FreeBSD ports, or maybe FreeBSD friendly Linux ports of thier enterprise software.
Xig continues to support FreeBSD's 3.x and 4.x lines with version 5 of their software, it is unfortunate that they got burned on the CDE issue but who really wants CDE?
As long as ISVs are coding for Linux there will be people running those applications via the linux-activator in FreeBSD.
The FreeBSD project is currently in contact with many ISVs with the goal of creating FreeBSD-friendly linux apps. This allows a "code once, compile twice" system where everyone wins.
As far as the shrinking market share is objective, there is a larger market now than ever. One percent of 10,000,000 is larger than two percent of 1,000,000.
Oh, and besideds that, I think you are talking out of your rear-end, but that's just me.
It's easy to post under Anonymous Coward, if the shoe fits, wear it.
--
Check out: http://www.freebsd.org/ports/
Jordan and a few others slaved to ensure that there were upgrade kits for those wishing to do an upgrade without a reinstall.
There are "kits" for 2.2.x -> 3.x available.
--
FUD from yet another Anonymous Wanker: .. yadda yadda yadda ..
> FreeBSD has lost...
I can't speculate too much on FreeBSD growth except to say that a threefold increase in users is probably what has happened in the last year.
A simple indicator, channel logs on #freebsd on efnet available at:
http://www.emsphone.com/stats/freebsd.html
The yearly graph shows over a threefold increase in the people coming onto to IRC to talk about and ask questions about FreeBSD.
CDrom sales are up according to friends at WC.
Anonymous Coward, the name fits you too well, for someone who may stating facts I'm suprised you aren't inclined to back it up by revealing your identity.
The future may belong to Linux, but I'm sure you won't be welcome there.
--
I'm confused about your claim of information hiding, the BSD rc system is quite simple and easy to use.
.deb of course :) work for you then more power to you. I'm sticking with what works for me.
example:
--
Admin's log, colocation date 02/15/99: Old redhat 5.2 box experiancing synflood problems.
Download new linux kernel sources.
Compile, kernel to big for gzip, fight with bzip for smaller kernel image.
Compile and install.
Fight with Lilo.
Reboot.
Forgot to add routing... oops
Recompile and install.
Reboot.
Routing is enabled but Redhat's init system calls Linuxconf to probe the kernel for features, the call to get routing info has changed, box won't boot as Linuxconf brings up curses interface during boot and hangs until key pressed and then doesn't init the routing table.
Attempt to install new init RPMs, init RPMs require some other subsystems to be upgraded first.
Attempt to upgrade those systems via RPM, they in turn require more RPM.
Box is now down 2+ hours.
Get extremely irritated and manaully hack the init system.
Problem almost solved.
Install FreeBSD next day.
Problem finally solved.
End of admin's log 02/15/99.
--
I'm not saying "make world" is the best thing out there, but it sure is more straight forward than the hassle that I endured with that Redhat box.
Draw your own conclusions. If RPMs or
--
/usr/ports/misc/screen
:)
Basing your choice of OS on cosole support...
Oh let's not even go there.
--
>> I know of no professor with commit rights to the Linux kernel, could you elaborate please?
>
> Ted T'so at MIT, a bunch of people overseas (Remy Card, Arjen van de Ven,
> Matt Kirkwood, a whole slew of Czechloslovakian profs, etc.)
These people can directly modify the kernel archives, or must all thier work be filtered through Linus and or Alan Cox?
>> Also, could you please explain how you managed to put "SGI" and "great minds" in
>> the same sentance?
>
> Was it last week or two weeks ago that freebsd-hackers was all in a tizzy
> because XFS is GPLed, making it difficult for you guys to steal the code? Make
> up your mind here.
It was mostly people unaware of the major new features that will be incorperated into FFS that were "in a tizzy".
In so far as "stealing code" I don't see where "stealing" comes into the picture unless you define Linux as "stealing" it as well.
After all it is =open source=, how would incorperating and open source'd code base be considered stealing?
I'm extremely tired of hearing about *BSD "stealing code". The code is GPL'd, it is free according to the license that adorns the top of the file it is contained in. Hypocrite, if it bothers you so then go closed source.
FreeBSD already incorperates at least one GPL'd filesystem, EXT2FS without problems. The project just won't allow FFS to be retired for the extremely fragile and badly licensed XFS that SGI is pushing. It quite possibly will be added as an option as there is nothing stopping its integration.
What's really upsetting is that while replying to this I forgot what the initial Slashdot article was about. In effect you win, your lies and misinfomation have clouded whatever joy and prestige the artcle brought me, rejoice in yourself "Anonymous Coward", the title fits you well.
--
I know of no professor with commit rights to the Linux kernel, could you elaborate please?
In contrast the FreeBSD project has at least one professor, Alan Cox (at Rice University). No, he's not the Linux kern developer Alan Cox, but a different Alan Cox.
However both camps (FreeBSD and Linux) have people in acadamia in active development, why do you feel the need to mis-inform people?
Also, could you please explain how you managed to put "SGI" and "great minds" in the same sentance?
--
If you want to follow a faster track I suggest you try out FreeBSD-current. Many more features are available at the expense of the thorough testing the the -stable branch provides.
m l
Here's a link that describes -current:
http://www.freebsd.org/handbook/cutting-edge.ht
Also, it should be noted that "-current" is not for newbies or people that aren't used to helping themselves or even providing fixes to problems that they encounter.
One of the benifits of developing applications for FreeBSD is the long term binary compatibility offered, it is almost unheard of to see a change go into FreeBSD-stable that would break current applications that are programmed correctly.
This gives ISVs the advantage of not having to worry about binary compatibility between minor (and usually major) versions of FreeBSD.
I also don't see why one would _want_ thier OS to change under thier feet almost daily, it sounds more like a punishment than a good thing imo.
-
Please look at the last graph at:
http://www.emsphone.com/stats/freebsd.html
Just something actually tangible. The growth is actually pretty astounding.
I'm not sure if i'm more confused by your definition of 'shrinking' or why _every_ FreeBSD related post on slashdot turns into an OS holy-war.
I just wanted to thank CmdrTaco for the forum to share FreeBSD related news.
Oh, and my company is paying for my FreeBSDCON experiance! w00p!
you just need to run "disklabel -e "
then make a "clone of the 'c' partition called 'e', make the FStype 'vinum'
run vinum and simply:
'stripe e e e'
It's really not _that_ bad.