I know how to keep it from happening - I was jsut suprised at how effectively it was able to shackle my machine.
I didn't try to ssh into it from another machine - that probably would have worked.
All I know is, there was nothing I could do at the machine to stop it. I think an OS should allways be able to accept input at the local console - no matter what the DFO does.
Ahile back, I was recently playing around with the various forkbomb scripts that exist out there. To my dismay, even my beloved FreeBSD 5.4 machine was rendered usless by it.
Let me know when an OS exists that is immune to crashes. I've yet to find one.
(From this document.) "Mach's development followed an evolutionary path from BSD UNIX systems. Mach code was initially developed inside the 4.2 BSD kernel, with BSD kernel components being replaced by Mach components as the Mach componentswere completed. The BSD components were updated to 4.3 BSD when that became available. By 1986, the virtual memory and communication subsystems were running on the DEC VAX computer family, including multiprocessor versions of the VAX. Versions for the IBM RT/PC and for Sun 3 workstations followed shortly; 1987 saw the completion of the EncoreMultimax and Sequent Balance multiprocessor versions, including task and thread support, as well as the first official releases of the system, Release 0 and Release 1. Through Release 2, Mach provides compatibility with the corresponding BSD systems by including much of BSD's code in the kernel. The new features and capabilities of Mach make the kernels in these releases larger than the corresponding BSD kernels. Mach 3 (Figure B.1) moves the BSD code outside of the kernel, leaving a much smaller microkernel. This system implements only basic Mach features in the kernel; all UNIX-specific code has been evicted to run in user-mode servers. Excluding UNIX-specific code from the kernel allows replacement of BSD with another operating system or the simultaneous execution of multiple operating-system interfaces on top of the microkernel. In addition to BSD, user-mode implementations have been developed for DOS, the Macintosh operating system, and OSF/1. This approach has similarities to the virtual-machine concept, but the virtual machine is defined by software (the Mach kernel interface), rather than by hardware. As of Release 3.0, Mach became available on a wide variety of systems, including single-processor Sun, Intel, IBM, and DEC machines and multiprocessor DEC, Sequent, and Encore systems."
Understandable. I would be cary cautious at moving a 4.x box to 5.x, (as I've seen the big changes) if it were a very important production setup.
I had the same kind of 'WTF?' reaction back when it was announced that 6.x was coming soon, before reading that the difference between 5 and 6 wasn't earth shattering and updating from 5 wouldn't be a huge deal.
"I've been able to patch boxes running or 4.x for quite a while now, but jumping from 4 to 5, or in this case from 5 to 6 requires a complete reinstall."
It's very hard for me to believe that you've been running FreeBSD servers for years, and don't know that version to version upgrades can be done with minimal pain. Upgrades from one version of FreeBSD to another *do not* require complete reinstalls.
Yes, a 4.x to 5.x upgrade has the potential to be tricky, due to the major changes involved, but upgrading from 5.x to 6.x will not be a nearly as hairy.
Take a look at this email from one of the FreeBSD developers, in response to a question just like yours.
I realize that there are unofficial msi installers - in fact I have seen a few different ones, but the fact remains that an official msi package would be much more appealing and much more accessible to the corporate world.
Your average PHB doesn't care if the unofficial package is as good as ab official one would be, they only see the term 'unofficial'.
I've found AD to be the most usefull thing for managing windows users and machines since sliced bread. I have everything grouped in a nice logical order seperated by object type/role, then location. Just about ANYTHING i want to do to any computer or user in my organization, I can do via Active directory. Software on our computers is deployed via active directory. Local machine passwords are changed on a regular basis via active directory. user/computer settings are managed via active dierctory. I've even delegated out rights to HR to be able to change certain identity attributes of users, like department, location, job title, etc, and that data is dumped out to a database and used on our website's employee directory.
It's easy. It's powerfull. It's reliable.
Now, why in the hell would I want to replace that with some half-assed LDAP based implimetation?
From TFA: "Most games bear no relation to military simulators at all. In fact, what games mostly choose to simulate bears no relation to reality at all. Most of these games can't be called a simulation except in the very broadest sense."
But nevertheless, I do agree with you.
Flashpoint was and still is the premier battlefield simulator. There are a few other games which, in some specific areas, compare to Flashpoint, but as a whole, no other games touches Flashpoint.
Ironically, I just reinstalled OFP last night. I'm thinking about writing some more missions for the game.
"My comment is directly based on how often I have to upgrade my Linux box due to security updates verses how often I read about "critical" MS security patches on Slashdot. It is also based on what my friend says about the Linux servers his work run verses the windows servers and desktops they run. I'm fortunate that I got out of Windows desktop / server administration before the Internet became popular, and therefore these problems became common."
My comment is based on my personal experience - with BOTH operating systems. I run a mostly Windows network with ~1000 windows workstations and 25+ servers. Every piece of standard software is deployed via AD group policy, and people's files are stored on a central server. Setting up a new box comprised of unpacking the box, cloning it, joining it too the domain and delivering it to the user. The biggest time is spent undoing the fifty twisty ties, and inventorying it. People don't log into their machines as local admins, therefore they generally do not need to be messed with after delivery. We only ever have to touch a machine if a piece of hardware fails. As for updates, they are deployed to using SUS - soon to be WSUS when I get a moment to install it. Configuration changes, like changing local admin passwords are done via WMI scripts, or active directory group policies. The equivalent of all I descried in Linux is certainly possible, but would require either an expensive distro like redhat with all of it's slick management tools, or a huge custom solution of cron jobs and shell scripts to handle everything.
As for the number of vulnerabilities in Linux, have you seen the number of vulnerabilities in the 2.6 kernel in the past four months!? There's been like 20-30 of them! That's nuts!
"Windows advocates are more likely to make assumptions than Linux advocates. Windows advocates usually haven't used Linux at all, yet they're willing to repeat what other people say about it, without having any personal experience to indicate to them that what they are saying is the truth. It is hard to provide realistic or credible criticisms of something that you don't have any experience with."
You are partially right in your assumptions. I don't use Linux. However, I do use the *BSD and get to chuckle at the Linux users every time a new kernel comes out and half of their drivers break.
"Linux advocates are usually ex- or even current Windows users (sometimes not by choice, due to their work situation), so they're typically speaking with a level of experience."
OS advocates in general are short sighted people who have succumb to herd mentality.
First of all, is the author of ODE complaining about this? If not, then why would you bring it up as a "problem"?
Second of all, Microsoft *bought* a TCP stack from a Spider software when they were writing Win2k. Ironically, that TCP stack was taken from BSD - so you can be mad a spider software for 'stealing' the BSD tcp stack and laugh at Microsoft for paying for it.
It had nothing to do with exposure (usenet/the internet), the ability to run on cheap hardware (accesibility), or advocacy (read: marketing).
In the begining linux was a toy with very limited use..defeinitely unworthy of any serious business use. The license of a product only matters when the product becomes usefull enough to be adopted by the masses.
"It's not politically correct to say this, but "it really is the license, stupid"."
Take out the "politically" from that sentence and it would be accurate.
linux overtook BSD because for a few reasons, but none of them had anything to do with the license. In the beginning linux has the ability to run on crappy hardware, and the BSDs only supported high end machines with SCSI.
BSD developers were resistant to supporting non-server hardware, because after all, BSD wasn't for desktop PC's. This was a big mistake.
More people adopted linux simply because they could afford to. The higher adoption rate led to a more rapid pace of development.
Also, linux advocacy (read: MARKETING) is something that BSD had no equivalent of for a long time.
The last thing is exposure. linux was first posted on the internet on Usenet, where TONS of people instantly has access to it, while BSD's exposure was limited to academe circles, and mailing lists.
FreeBSD (and the other flavors) seem to be recovering though. Today, the BSDs support plenty of "crap hardware", which makes trying it out just as affordable as trying out linux. BSD advocacy, while in it's infancy does at least exist today, and it's exposure (ironically probably thanks to linux) is very wide too.
"You employ other peoples work for your own benefit without having to do any real work yourself. What's not to like? Hell, if there are people out there generous enough and stupid enough to give you a free ride like that, then more power to them I guess.
That's probably what the IBM execs say about GNU/linux when they all converge around the water cooler.
...and switched to a small 'white box' company that pre-stocks us with spare parts for our PC's. If a part dies, we replace it and then call them. A typical phone call to them lasts about 45 seconds, and comprises of us telling them who we are, where we are from, the serial number of the computer in question and the part we replaced. They then say good day, and ship a replacement-replacement part out - no questions, no annoying scripts, no BS.
"Let me know how great FreeBSD as a workstation is when portupgrade fails. (I'm writing this from a FreeBSD workstation running Gnome 2.10.1)"
Ahh yes, ye olde portupgrade.....
If you havn't already, I strongly suggest you give portmanager a try. I use FreeBSD 5.4/KDE 3.4, and after using it for a couple of months now, I dread the thought of having to go back to portupgrade to update my system.
You can find portmanager here:/usr/ports/sysutils/portmanager
Slashdot Mirror
Well, it was my Desktop machine.
I know how to keep it from happening - I was jsut suprised at how effectively it was able to shackle my machine.
I didn't try to ssh into it from another machine - that probably would have worked.
All I know is, there was nothing I could do at the machine to stop it. I think an OS should allways be able to accept input at the local console - no matter what the DFO does.
...but that configuration you have is not a solution to the overall problem. It's hard limit which on many systems would not be feasable at all.
There has to be a better way.
Ahile back, I was recently playing around with the various forkbomb scripts that exist out there. To my dismay, even my beloved FreeBSD 5.4 machine was rendered usless by it.
Let me know when an OS exists that is immune to crashes. I've yet to find one.
And Mach was born out of BSD.
Some history for you...
(From this document.)
"Mach's development followed an evolutionary path from BSD UNIX systems.
Mach code was initially developed inside the 4.2 BSD kernel, with BSD
kernel components being replaced by Mach components as the Mach componentswere
completed. The BSD components were updated to 4.3 BSD when that
became available. By 1986, the virtual memory and communication subsystems
were running on the DEC VAX computer family, including multiprocessor
versions of the VAX. Versions for the IBM RT/PC and for Sun 3 workstations
followed shortly; 1987 saw the completion of the EncoreMultimax and Sequent
Balance multiprocessor versions, including task and thread support, as well as
the first official releases of the system, Release 0 and Release 1.
Through Release 2, Mach provides compatibility with the corresponding
BSD systems by including much of BSD's code in the kernel. The new features
and capabilities of Mach make the kernels in these releases larger than the
corresponding BSD kernels. Mach 3 (Figure B.1) moves the BSD code outside
of the kernel, leaving a much smaller microkernel. This system implements
only basic Mach features in the kernel; all UNIX-specific code has been evicted
to run in user-mode servers. Excluding UNIX-specific code from the kernel
allows replacement of BSD with another operating system or the simultaneous
execution of multiple operating-system interfaces on top of the microkernel.
In addition to BSD, user-mode implementations have been developed for DOS,
the Macintosh operating system, and OSF/1. This approach has similarities to
the virtual-machine concept, but the virtual machine is defined by software
(the Mach kernel interface), rather than by hardware. As of Release 3.0, Mach
became available on a wide variety of systems, including single-processor Sun,
Intel, IBM, and DEC machines and multiprocessor DEC, Sequent, and Encore
systems."
Understandable. I would be cary cautious at moving a 4.x box to 5.x, (as I've seen the big changes) if it were a very important production setup.
I had the same kind of 'WTF?' reaction back when it was announced that 6.x was coming soon, before reading that the difference between 5 and 6 wasn't earth shattering and updating from 5 wouldn't be a huge deal.
...BSD users see cvsup, make *world, and mergemaster.
"I've been able to patch boxes running or 4.x for quite a while now, but jumping from 4 to 5, or in this case from 5 to 6 requires a complete reinstall."
It's very hard for me to believe that you've been running FreeBSD servers for years, and don't know that version to version upgrades can be done with minimal pain. Upgrades from one version of FreeBSD to another *do not* require complete reinstalls.
Yes, a 4.x to 5.x upgrade has the potential to be tricky, due to the major changes involved, but upgrading from 5.x to 6.x will not be a nearly as hairy.
Take a look at this email from one of the FreeBSD developers, in response to a question just like yours.
You left out:
D) All of the above
I realize that there are unofficial msi installers - in fact I have seen a few different ones, but the fact remains that an official msi package would be much more appealing and much more accessible to the corporate world.
Your average PHB doesn't care if the unofficial package is as good as ab official one would be, they only see the term 'unofficial'.
The Firefox team needs to make sure that the upcoming 1.5 release comes packaged as a native msi installer.
Not being in msi form hinders the corporate adoption of firefox greatly.n.
Since when was managing AD difficult?
I've found AD to be the most usefull thing for managing windows users and machines since sliced bread. I have everything grouped in a nice logical order seperated by object type/role, then location. Just about ANYTHING i want to do to any computer or user in my organization, I can do via Active directory. Software on our computers is deployed via active directory. Local machine passwords are changed on a regular basis via active directory. user/computer settings are managed via active dierctory. I've even delegated out rights to HR to be able to change certain identity attributes of users, like department, location, job title, etc, and that data is dumped out to a database and used on our website's employee directory.
It's easy. It's powerfull. It's reliable.
Now, why in the hell would I want to replace that with some half-assed LDAP based implimetation?
I think the author gets that.
From TFA:
"Most games bear no relation to military simulators at all. In fact, what games mostly choose to simulate bears no relation to reality at all. Most of these games can't be called a simulation except in the very broadest sense."
But nevertheless, I do agree with you.
Flashpoint was and still is the premier battlefield simulator. There are a few other games which, in some specific areas, compare to Flashpoint, but as a whole, no other games touches Flashpoint.
Ironically, I just reinstalled OFP last night. I'm thinking about writing some more missions for the game.
"My comment is directly based on how often I have to upgrade my Linux box due to security updates verses how often I read about "critical" MS security patches on Slashdot. It is also based on what my friend says about the Linux servers his work run verses the windows servers and desktops they run. I'm fortunate that I got out of Windows desktop / server administration before the Internet became popular, and therefore these problems became common."
My comment is based on my personal experience - with BOTH operating systems. I run a mostly Windows network with ~1000 windows workstations and 25+ servers. Every piece of standard software is deployed via AD group policy, and people's files are stored on a central server. Setting up a new box comprised of unpacking the box, cloning it, joining it too the domain and delivering it to the user. The biggest time is spent undoing the fifty twisty ties, and inventorying it. People don't log into their machines as local admins, therefore they generally do not need to be messed with after delivery. We only ever have to touch a machine if a piece of hardware fails. As for updates, they are deployed to using SUS - soon to be WSUS when I get a moment to install it. Configuration changes, like changing local admin passwords are done via WMI scripts, or active directory group policies. The equivalent of all I descried in Linux is certainly possible, but would require either an expensive distro like redhat with all of it's slick management tools, or a huge custom solution of cron jobs and shell scripts to handle everything.
As for the number of vulnerabilities in Linux, have you seen the number of vulnerabilities in the 2.6 kernel in the past four months!? There's been like 20-30 of them! That's nuts!
"Windows advocates are more likely to make assumptions than Linux advocates. Windows advocates usually haven't used Linux at all, yet they're willing to repeat what other people say about it, without having any personal experience to indicate to them that what they are saying is the truth. It is hard to provide realistic or credible criticisms of something that you don't have any experience with."
You are partially right in your assumptions. I don't use Linux. However, I do use the *BSD and get to chuckle at the Linux users every time a new kernel comes out and half of their drivers break.
"Linux advocates are usually ex- or even current Windows users (sometimes not by choice, due to their work situation), so they're typically speaking with a level of experience."
OS advocates in general are short sighted people who have succumb to herd mentality.
The assumtion that Windows is inherantly more time consuming to admin than linux is not neccesarily correct.
That's a good point. Why *would* the author complain. He *chose* the BSD license, probably because he wanted people/companies to adopt it.
If he had chosen the GPL license for his little engine, it's adoption rate would not be nearly as high.
First of all, is the author of ODE complaining about this? If not, then why would you bring it up as a "problem"?
Second of all, Microsoft *bought* a TCP stack from a Spider software when they were writing Win2k. Ironically, that TCP stack was taken from BSD - so you can be mad a spider software for 'stealing' the BSD tcp stack and laugh at Microsoft for paying for it.
...and in four years (we were a very early adopter), the only problems we have had were the fault of Cisco's software, not Microsoft's OS.
Don't even get me started on *Unity*.
Oh sure, it was the GPL.
It had nothing to do with exposure (usenet/the internet), the ability to run on cheap hardware (accesibility), or advocacy (read: marketing).
In the begining linux was a toy with very limited use..defeinitely unworthy of any serious business use. The license of a product only matters when the product becomes usefull enough to be adopted by the masses.
"It's not politically correct to say this, but "it really is the license, stupid"."
Take out the "politically" from that sentence and it would be accurate.
linux overtook BSD because for a few reasons, but none of them had anything to do with the license. In the beginning linux has the ability to run on crappy hardware, and the BSDs only supported high end machines with SCSI.
BSD developers were resistant to supporting non-server hardware, because after all, BSD wasn't for desktop PC's. This was a big mistake.
More people adopted linux simply because they could afford to. The higher adoption rate led to a more rapid pace of development.
Also, linux advocacy (read: MARKETING) is something that BSD had no equivalent of for a long time.
The last thing is exposure. linux was first posted on the internet on Usenet, where TONS of people instantly has access to it, while BSD's exposure was limited to academe circles, and mailing lists.
FreeBSD (and the other flavors) seem to be recovering though. Today, the BSDs support plenty of "crap hardware", which makes trying it out just as affordable as trying out linux. BSD advocacy, while in it's infancy does at least exist today, and it's exposure (ironically probably thanks to linux) is very wide too.
Here is a good mythTV on FreeBSD howto:
http://mythtv.son.org/tiki-index.php
Personally, I use xdtv for watching/recording tv on my FreeBSD machine.
There is really no need for a firewall with Win2k and above.
With Win2k, turn off the services that you don't need and use the built in IPSEC to regulate what traffic can flow where.
With Win2k3, you can go the IPSEC route, or you can use the firewall that's built in.
"You employ other peoples work for your own benefit without having to do any real work yourself. What's not to like? Hell, if there are people out there generous enough and stupid enough to give you a free ride like that, then more power to them I guess.
That's probably what the IBM execs say about GNU/linux when they all converge around the water cooler.
...and switched to a small 'white box' company that pre-stocks us with spare parts for our PC's. If a part dies, we replace it and then call them. A typical phone call to them lasts about 45 seconds, and comprises of us telling them who we are, where we are from, the serial number of the computer in question and the part we replaced. They then say good day, and ship a replacement-replacement part out - no questions, no annoying scripts, no BS.
"Let me know how great FreeBSD as a workstation is when portupgrade fails. (I'm writing this from a FreeBSD workstation running Gnome 2.10.1)"
/usr/ports/sysutils/portmanager
Ahh yes, ye olde portupgrade.....
If you havn't already, I strongly suggest you give portmanager a try. I use FreeBSD 5.4/KDE 3.4, and after using it for a couple of months now, I dread the thought of having to go back to portupgrade to update my system.
You can find portmanager here: