Seriously, nocat is a great piece of work. I had the opportunity to test nocat with some SMC WAPs recently and I was impressed. The setup was a little difficult (had trouble getting the latest stable to work, nightly opporated fine however), but once it was up and running I had no trouble accomplishing exactly what I wanted.
The company I was working for was trying to install wifi access in downtown Macon GA. We got beat to the punch by Cox Communications (who has a many time inferiour setup, but I won't go into that). NoCat basically lets you firewall off all ip traffic until a user opens their web browser. Upon doing that, their session is captured by nocat and redirected to an https page where they have the option of signing in, or using the system anonymously.
The benefits of this are incredible. Coffee shops can use it to broadcast out a TOS that one must agree to before using their wifi, large scale networks can offer web page advertising that everyone must go through sooner or later, and universites can require students to sign in to use the free service. It's a great way to offer 'contractual' service to users without having to distribute wifi keys everywhere.
If this Comes To Pass, all someone will have to do is fire-up snort on you network...Instant, internally-generated DOS!
You don't really think that the firewall will be configured to accept alerts from any old IDS now do you? Likely if some one were to set this up, it would communicate between the IDS and the firewall (if they aren't the same machine) with encrypted TCP/IP packets using pre-shared keys. Unless you could crack the traffic and thus get the key, what shot do you realistically have to just fire up any ole IDS on any machine and get it to work?
I would agree, but only on a few stipulations. E-mail as we know it will almost certainly die sooner or later, to be replaced with something else that better fits our future needs. Like gopher and http, smtp, pop, and imap will all sooner or later be replaced by another set of protocols. Perhaps they will require something like SPF to reduce spoofed "From" headers. Perhaps they will support or even require encryption? Face it. Sooner or later, e-mail as we know it will die, but only when something else is able to take its place.
only a very few files had to be removed, and they were very easily replaced
I can't comment on how easy they were to replace (I obviously didn't work on them), but it does seem true that the stir and contraversy over BSD allowed the growth of another free operating system without a lot of open source competition, namely linux. I don't think anyone would argue that *BSD's install base would be much larger had the law suit never taken place and created so much FUD. The various BSD's would likely hold the same niche that many linux boxen now hold.
If I understand you correctly, you are talking about feeding cattle in pastures, at what, a few animals to the acre? Your density is a small fraction of what you find in a feedlot, where the animals are fed mostly grain rather than hay.
You do misunderstand, albeit just a bit. Everyone around here grazes their beef cattle, but they give them hay and feed right out in the pasture. It's much easier to feed them in the pasture in large groups with many different troughs setup (maybe half a dozen cows to a trough) in places that's easy to drive by and dump buckets of feed into.
And thank you for the spelling correction. I make no gaurantee that I'll get it right in the future, however.:^)
Linux Weekly News had an article about this several days ago, and it's been talked about on Groklaw. Basically Caldera claims that there was an unwritten, oral contract between Novell and Canopy that said they would sue MS on behalf of Novell, and not reveal Novell's hand in it.
Of course Novell responds in the negative. Canopy is using a rather interesting attack here though. Many of the people working with Canopy now worked for Novell back when this suppossed oral contract took place. They claim no one at Novell knows about it because all those people who once worked for Novell have moved on. This of course puts them in the spot of saying "We know everything because we were there and you people running Novell now have no idea what you're talking about. Our guys worked for Novell back then, and they know what was said."
Novell's defense is simple. Show me a written contract.
I was under the impression that feedlots where beef cattle are fattened tend to generate a lot of manure in a small space also.
Other people in other parts of the world may do things somewhat differently, but here we just don't consistently feed our cattle in the same place day after day. We typically have a few spots where we feed some, other spots where we feed others, a few round bails of hay scattered about, you get the picture. Given that all these locations are out in a field somewhere, it just wouldn't be practical to go after all that dung.
This ought to help the unemployment rate, as there will be a new employment opportunities in the poop-picking-up field.
I know you're just trying to be funny, but I thought I'd point out there's a reason why this is being done for dairy cows instead of beef cattle. Dairy cows tend to shit in a barn while they're being milked. This creates a lot of waste in a small area, that we typically just hoss out the back. Of course, there's no reason you couldn't hoss it into a container, and then dump that somewhere else where it could be better used.
that would mean that whatever we have today, evolved from >20% / >5% of those species that survived?
No, it simply means that 80% of all terrestrial creatures died, and 95% of all aquatic creatures died. This doesn't mean that 80% or 95% of all those *species* died.
While a statistical improbability, it is still possible that every species that existed at that time survived, just that the number of creatures in that species suddenly dropped.
Yeah but that fantasy is built upon the assumption that SCO owns Unix.
While SCO may very well not own unix, they do own the distribution rights to System V unix as I understand it. Whoever buys SCO would seem to hold those distribution rights. Depending on the wording of their contract with Novell, it is possible that whoever has distribution rights could distribute it under the GPL. I don't think that's likely though. More likely the contract says they cannot release the source code.
Given that many pieces of System V unix have in the past been published in books or in other places under a BSDish license, I would think it more likely to be released under just that license.
This is a big one to me. I absolutely hate patched up kernels that are really just jacked up kernels.
2) Helpfulness of the installer.
A minor point to me since you so rarely install a system, and if you isntall one regularly (say a server or something) you typically have some tool that allows you to do a mostly hand free install. Of course, lacking such an option is a turn off.
3) Advantages of the particular packaging system used.
No argument here.
4) Default security levels.
You really shouldn't leave anything at default security levels, but this is a good place to start I agree.
5) Detailed review of the hardware detection capabilities.
Why should this differ from distro to distro? Hardware detection is done by the kernel, and they are run pretty much the same kernel, unless it's one of those uber-patched piles of dung.
6) Is the graphical desktop logically arranged? Do the menus make sense, and do they make your life easier?
IME I haven't seen one that really wasn't, except for RedHat's bluecurve. For the most part the window managers and DEs get the menus right. A distro that doesn't screw around here gets it right too.
7) An important one: how easy is it to reliably upgrade to the distro from an earlier version?
This is of prime importance for some distros, and not so prime for others. Case in point. Administering a RedHat 7.2 machine today is a big pain in the ass. It's even worse for the 6.2 machine I have to mess with. Adminstering a Slackware 8.0 machine or 7.1 though, is pretty damn easy, including rolling your own security updates from source code. It's just not that big an issue.
Second, the graduation certificate given to a child who received significant accommodations is different from the graduation certificate given to a child that met all standard without significant accommodations.
I think Roosevelt has managed to invent a whole new direction to move in. The man has pissed away an obscene surplus projection, put rocket boosters on the deficit, instituted a recovery plan that would make a first year economist trainee weep, started a war, failed to justify it, shoved laws through a pants-pissing Congress....
All this and he managed to stonewall an investigation into one of the biggest intelligence disasters in history, roll back a dozen years of progress on diplomacy, environmental issues, and civil rights, AND he took more vacation time his first year in office than any healthy president in history.
Yes... I think FDR has redefined the political spectrum.... in a very bad way. I have never cared about politics before, but I am now a registered voter and I've looked deeper into the issues in the last few months than I had in all my previous years on this planet combined. Way to go Roosevelt....
I gather this sort of deal comes with a time limit
Not neccessarily a time limit, but it does come with interest. You essentially borrow the stock from guy 1, then sell it to guy 2 at the price you bought it for. Now you have a lot of money in your pocket, but you owe guy 1 all that stock (currently the value of your money). He charges you interest on that, If you wait too long and the price doesn't drop enough, even if it does drop, you could loose money to interest.
Let's just think about Apache as an example. Say a bug comes out in Apache 1.3.26, theres a fix in 1.3.29. Now let's say that you also bought an apache mod ala Chilisoft to handle ASP, but it only works with 1.3.26. Would you feel good about RH updating to 1.3.29, instead of moving over those 2 or 3 lines that fix some buffer overflow in some.c file on an older version?
First of all, we're not talking about previously back-ported security fixes. Distributions don't tend to ship an older version of an application with back-ported security fixes from a later release; they release the latest "stable" with back-ported "features" from the development release.
Second of all, in your Apache example, I'm sure that the vast majority of apache users haven't done this. I have no numbers to back-up my position at this time, but I'd say that far and away the most (maybe 90%) of people aren't running any other software taht will only interface with an older stable version. Most of the time you can just upgrade it and the plugin is none the wiser. Of course, if that's not the case, you have no choice but to backport. Still, I would rather be the one making that call, not the distribution. I am no great C programmer, but I can read it well enough and move the few lines that are changed in something.c and recompile. In short, if it's going to be backported I want to be the one doing the backporting.
The easy answer is to assume the fix hasn't been backported unless the vendor explicitly says it has. Even then, I personally would upgrade to the "latest" version and eliminate all doubt
I typically do just that, but it isn't always as easy as it should be. RPM based distributions (of which RedHat by definition is) tend to have obscure, hard to trace dependencies in their packages. Compiling from known good source downloaded from the software project's FTP site isn't always the best solution, particularly if you've let other system updates lapse.
Case in point. I came across a RedHat machine running a vulnerable version of OpenSSH. It was no longer being supported by RedHat, so I downloaded the latest release of OpenSSH Portable. The configure script complained that zlib was old and possibly insecure. This means I had to go in an compile a new zlib, and then make sure everything worked properly when linked with the new zlib. But now, my entire RPM tree is completely hosed. I might as well not even have RPM, since nearly every damn thing relies on zlib.
In checking RedHat's FTP sites, they had apparently also back-ported security fixes to the older version of zlib (IIRC), which of course meant OpenSSH would have still complained when I re-compiled, but I could be modestly sure it wouldn't be vulnerable, or could I?
Of course practicies like that enventually force you upgrade your machine to a new version at some point in time, or hose the RPM database by compiling all new updates and their dependencies from source.
Thank God and Patrick for Slackware, where these problems are few and far between, and typically MUCH easier to resolve.
While I don't believe that back-porting security fixes, or even new features is a major danger to forking an open source project (be it the kernel or something else doesn't matter), I do find it a danger as a sysadmin.
Often times I've had to administer an older RedHat linux machine that may be running a version two or more years out of date. A vulnerability comes up in a service that hasn't been patched in God knows when, and I have to fix the hole. The security advisory says version a.b.c is vulnerable and that I should upgrade to a.b.d or a.e.X. So I log onto that machine and check to see what version it's running and I see:
a.b.c-g
So is a.b.c-g vulnerable or not? Did RedHat back-port something from the a.e.X branch that fixes this? Now I have to dig through some RedHat mailing lists which I may not be subscribed to to find out. Now I know for a fact that when I see an a.b.c-h version for download from RedHat's site, that I've need to upgrade.
But what if it's the other way around?
What if I hear about a vulnerability in version a.e.X of that same software, but that the a.b.X version is safe. Did the vendor back-port some vulnerable bit of code from a.e.X into their a.b.c-g binaries? How am I to know?
Back-porting things like this makes it hell on a sysadmin who then has to subscribe to lots of different mailing lists, particularly if you're running different distributions.
Slashdot Mirror
Seriously, nocat is a great piece of work. I had the opportunity to test nocat with some SMC WAPs recently and I was impressed. The setup was a little difficult (had trouble getting the latest stable to work, nightly opporated fine however), but once it was up and running I had no trouble accomplishing exactly what I wanted.
The company I was working for was trying to install wifi access in downtown Macon GA. We got beat to the punch by Cox Communications (who has a many time inferiour setup, but I won't go into that). NoCat basically lets you firewall off all ip traffic until a user opens their web browser. Upon doing that, their session is captured by nocat and redirected to an https page where they have the option of signing in, or using the system anonymously.
The benefits of this are incredible. Coffee shops can use it to broadcast out a TOS that one must agree to before using their wifi, large scale networks can offer web page advertising that everyone must go through sooner or later, and universites can require students to sign in to use the free service. It's a great way to offer 'contractual' service to users without having to distribute wifi keys everywhere.
You don't really think that the firewall will be configured to accept alerts from any old IDS now do you? Likely if some one were to set this up, it would communicate between the IDS and the firewall (if they aren't the same machine) with encrypted TCP/IP packets using pre-shared keys. Unless you could crack the traffic and thus get the key, what shot do you realistically have to just fire up any ole IDS on any machine and get it to work?
I would agree, but only on a few stipulations. E-mail as we know it will almost certainly die sooner or later, to be replaced with something else that better fits our future needs. Like gopher and http, smtp, pop, and imap will all sooner or later be replaced by another set of protocols. Perhaps they will require something like SPF to reduce spoofed "From" headers. Perhaps they will support or even require encryption? Face it. Sooner or later, e-mail as we know it will die, but only when something else is able to take its place.
No he is innocent until proven guilty.
Just to split hairs here, he is presumed innocent until proven guilty.
But no matter how many times he checks it he's still in the naughty column.
I can't comment on how easy they were to replace (I obviously didn't work on them), but it does seem true that the stir and contraversy over BSD allowed the growth of another free operating system without a lot of open source competition, namely linux. I don't think anyone would argue that *BSD's install base would be much larger had the law suit never taken place and created so much FUD. The various BSD's would likely hold the same niche that many linux boxen now hold.
You do misunderstand, albeit just a bit. Everyone around here grazes their beef cattle, but they give them hay and feed right out in the pasture. It's much easier to feed them in the pasture in large groups with many different troughs setup (maybe half a dozen cows to a trough) in places that's easy to drive by and dump buckets of feed into.
And thank you for the spelling correction. I make no gaurantee that I'll get it right in the future, however. :^)
Linux Weekly News had an article about this several days ago, and it's been talked about on Groklaw. Basically Caldera claims that there was an unwritten, oral contract between Novell and Canopy that said they would sue MS on behalf of Novell, and not reveal Novell's hand in it.
Of course Novell responds in the negative. Canopy is using a rather interesting attack here though. Many of the people working with Canopy now worked for Novell back when this suppossed oral contract took place. They claim no one at Novell knows about it because all those people who once worked for Novell have moved on. This of course puts them in the spot of saying "We know everything because we were there and you people running Novell now have no idea what you're talking about. Our guys worked for Novell back then, and they know what was said."
Novell's defense is simple. Show me a written contract.
Other people in other parts of the world may do things somewhat differently, but here we just don't consistently feed our cattle in the same place day after day. We typically have a few spots where we feed some, other spots where we feed others, a few round bails of hay scattered about, you get the picture. Given that all these locations are out in a field somewhere, it just wouldn't be practical to go after all that dung.
I know you're just trying to be funny, but I thought I'd point out there's a reason why this is being done for dairy cows instead of beef cattle. Dairy cows tend to shit in a barn while they're being milked. This creates a lot of waste in a small area, that we typically just hoss out the back. Of course, there's no reason you couldn't hoss it into a container, and then dump that somewhere else where it could be better used.
that would mean that whatever we have today, evolved from >20% / >5% of those species that survived?
No, it simply means that 80% of all terrestrial creatures died, and 95% of all aquatic creatures died. This doesn't mean that 80% or 95% of all those *species* died.
While a statistical improbability, it is still possible that every species that existed at that time survived, just that the number of creatures in that species suddenly dropped.
George Boole anyone?
Where's RMS on this list? I would think he would deserve as much credit as Linus Torvalds.
I hope you don't expect your child to use Reader Rabbit when he's over 12.
While SCO may very well not own unix, they do own the distribution rights to System V unix as I understand it. Whoever buys SCO would seem to hold those distribution rights. Depending on the wording of their contract with Novell, it is possible that whoever has distribution rights could distribute it under the GPL. I don't think that's likely though. More likely the contract says they cannot release the source code.
Given that many pieces of System V unix have in the past been published in books or in other places under a BSDish license, I would think it more likely to be released under just that license.
Whoa! Some one needs to learn HTML. Those things you're missing are
.
1) Feature bloat in the default kernel.
This is a big one to me. I absolutely hate patched up kernels that are really just jacked up kernels.
2) Helpfulness of the installer.
A minor point to me since you so rarely install a system, and if you isntall one regularly (say a server or something) you typically have some tool that allows you to do a mostly hand free install. Of course, lacking such an option is a turn off.
3) Advantages of the particular packaging system used.
No argument here.
4) Default security levels.
You really shouldn't leave anything at default security levels, but this is a good place to start I agree.
5) Detailed review of the hardware detection capabilities.
Why should this differ from distro to distro? Hardware detection is done by the kernel, and they are run pretty much the same kernel, unless it's one of those uber-patched piles of dung.
6) Is the graphical desktop logically arranged? Do the menus make sense, and do they make your life easier?
IME I haven't seen one that really wasn't, except for RedHat's bluecurve. For the most part the window managers and DEs get the menus right. A distro that doesn't screw around here gets it right too.
7) An important one: how easy is it to reliably upgrade to the distro from an earlier version?
This is of prime importance for some distros, and not so prime for others. Case in point. Administering a RedHat 7.2 machine today is a big pain in the ass. It's even worse for the 6.2 machine I have to mess with. Adminstering a Slackware 8.0 machine or 7.1 though, is pretty damn easy, including rolling your own security updates from source code. It's just not that big an issue.
What do you mean when he was a kid?
I think Roosevelt has managed to invent a whole new direction to move in. The man has pissed away an obscene surplus projection, put rocket boosters on the deficit, instituted a recovery plan that would make a first year economist trainee weep, started a war, failed to justify it, shoved laws through a pants-pissing Congress....
All this and he managed to stonewall an investigation into one of the biggest intelligence disasters in history, roll back a dozen years of progress on diplomacy, environmental issues, and civil rights, AND he took more vacation time his first year in office than any healthy president in history.
Yes... I think FDR has redefined the political spectrum.... in a very bad way. I have never cared about politics before, but I am now a registered voter and I've looked deeper into the issues in the last few months than I had in all my previous years on this planet combined. Way to go Roosevelt....
Not neccessarily a time limit, but it does come with interest. You essentially borrow the stock from guy 1, then sell it to guy 2 at the price you bought it for. Now you have a lot of money in your pocket, but you owe guy 1 all that stock (currently the value of your money). He charges you interest on that, If you wait too long and the price doesn't drop enough, even if it does drop, you could loose money to interest.
First of all, we're not talking about previously back-ported security fixes. Distributions don't tend to ship an older version of an application with back-ported security fixes from a later release; they release the latest "stable" with back-ported "features" from the development release.
Second of all, in your Apache example, I'm sure that the vast majority of apache users haven't done this. I have no numbers to back-up my position at this time, but I'd say that far and away the most (maybe 90%) of people aren't running any other software taht will only interface with an older stable version. Most of the time you can just upgrade it and the plugin is none the wiser. Of course, if that's not the case, you have no choice but to backport. Still, I would rather be the one making that call, not the distribution. I am no great C programmer, but I can read it well enough and move the few lines that are changed in something.c and recompile. In short, if it's going to be backported I want to be the one doing the backporting.
I typically do just that, but it isn't always as easy as it should be. RPM based distributions (of which RedHat by definition is) tend to have obscure, hard to trace dependencies in their packages. Compiling from known good source downloaded from the software project's FTP site isn't always the best solution, particularly if you've let other system updates lapse.
Case in point. I came across a RedHat machine running a vulnerable version of OpenSSH. It was no longer being supported by RedHat, so I downloaded the latest release of OpenSSH Portable. The configure script complained that zlib was old and possibly insecure. This means I had to go in an compile a new zlib, and then make sure everything worked properly when linked with the new zlib. But now, my entire RPM tree is completely hosed. I might as well not even have RPM, since nearly every damn thing relies on zlib.
In checking RedHat's FTP sites, they had apparently also back-ported security fixes to the older version of zlib (IIRC), which of course meant OpenSSH would have still complained when I re-compiled, but I could be modestly sure it wouldn't be vulnerable, or could I?
Of course practicies like that enventually force you upgrade your machine to a new version at some point in time, or hose the RPM database by compiling all new updates and their dependencies from source.
Thank God and Patrick for Slackware, where these problems are few and far between, and typically MUCH easier to resolve.
While I don't believe that back-porting security fixes, or even new features is a major danger to forking an open source project (be it the kernel or something else doesn't matter), I do find it a danger as a sysadmin.
Often times I've had to administer an older RedHat linux machine that may be running a version two or more years out of date. A vulnerability comes up in a service that hasn't been patched in God knows when, and I have to fix the hole. The security advisory says version a.b.c is vulnerable and that I should upgrade to a.b.d or a.e.X. So I log onto that machine and check to see what version it's running and I see:
a.b.c-g
So is a.b.c-g vulnerable or not? Did RedHat back-port something from the a.e.X branch that fixes this? Now I have to dig through some RedHat mailing lists which I may not be subscribed to to find out. Now I know for a fact that when I see an a.b.c-h version for download from RedHat's site, that I've need to upgrade.
But what if it's the other way around?
What if I hear about a vulnerability in version a.e.X of that same software, but that the a.b.X version is safe. Did the vendor back-port some vulnerable bit of code from a.e.X into their a.b.c-g binaries? How am I to know?
Back-porting things like this makes it hell on a sysadmin who then has to subscribe to lots of different mailing lists, particularly if you're running different distributions.
Ever run a proprietary application you or another company wrote to interface with an MS SQL Server?