Wrong. This thing is certainly not "persistent storage". It certainly isn't when one is talking about a database. The contents will be lost a few hours after it loses power. This thing has a persistence measured in hours where hard drives have persistence measured in DECADES. And it's orders of magnitude slower than main memory -- 100-150MB/s vs. >1.8GB/s.
(In Linux at least, a chunk of main memory can be set aside for a RAM disk that's persistent across reboots -- as long as your BIOS doesn't re-zero the RAM.)
This is not true. However, so long as the line is connected to a phone switch, yes, they are required to process 911 calls on it. Bellsouth will also allow you to call their service center (780-2355?) where you can signup for service.
(There are a few "poor people" loopholes -- all that Universal Service bull...)
I've found IPS (formerly ip audit) in Cisco's IOS, while programmed by monkeys who don't pay much attention to what they're typing, does a pretty good job of cutting off a host of attacks at the router. Of course, it'll only look at what it's configured to watch and only knows about a select number of things -- the more it's told to watch for, the more memory and time it takes.
I have it watching web traffic and it's knocking down just about every script kiddie's IIS probe. (I don't run ISS, btw.)
...you *cannot* store your entire home directory over AFS...
This is 100% bullshit. I don't know how screwed up your network is, but it certainly is possible to place user homes inside AFS. Many an institution has done just this -- and for nearly 2 decades, even. (NCSU has been doing this since about 1986.)
What needs to be accessed in a user's home directory prior to authentication? The only thing that comes to mind is ssh keys (~/.ssh/authorized_keys), and they only need to be readable by the host and/or sshd which can be easily handled. (and technically, they don't have to be in the user's home.)
Yes. Redhat did it first. And redhat started out, in the early/mid 90's, more as a community than a business. I remember when redhat was a half dozen people -- a half dozen college kids -- designing a better packaging system, not a linux distribution. The follow-on's have been for-profit enterprises from day one. There are distributions older than redhat that have never become "money hungry", commercial enterprises. [Technically, SLS tried it first, but they were already half dead.]
The point of the GPL is certainly not to allow one to profit from the work of others; it's to ensure the openness of software. The only closed source software that comes to mind is the Netscape/Sun ONE/iPlanet directory server, which was a dead-end product when they bought it. (it's been bundled with solaris for years, so it's not been a fully commercial product for over half a decade.)
There are thousands of companies (and individuals) funding the development of various OSS projects. The primary motivation is a tax break, not altruism, or guilt. And the bottom line... redhat "gives back" far less than they collect.
A new Cisco anything is f'ing expensive. ALL their shit is overpriced, however neat and all. Go look at their financial reports... they made (profit, not revenue) Four. Billion. Dollars. last year. And that's after accounting for R&D, staff, etc.
It's called "privacy director"... if there's no name and number to send to you, the caller is required to identify themselves to an automated attendant that gets played back to you when (if) you answer, at which point you can choose to block the call (or just not answer anything that shows as coming from privacy director.)
Having worked for/with telcos, just because nothing was sent to your phone via caller-id does not mean there isn't a call detail record for it. In fact, there's a CDR generated for every call origination and termination. And they're archived for a VERY long time.
(If your story is 100% accurate, they've broken so many laws, there should be lawyers lining up to represent you.... well, except for that last part:-))
For 802.11B, the channels overlap... 1,6, and 10 can be used at the same time without stepping on each other (and various combinations of one low and one high channel.) Apartments, condo's, and often, townhouses are packed too closely for many resident's deploying an AP. If I turn on an AP, I'll flood between 10 and 14 apartments with the RF -- at standard power levels... at full "legal" power, half the complex can see it.
wtf are you talking about? You can get those things for 25$ on eBay. I have a stack of them that I paid 24$ each for them about 2 years ago -- before zynx stopped making them.
They're pretty good -- damn good for 25$. But they are certianly not "top of the line".
As the end user, maybe, but as the admin, it's pretty easy to see the effectiveness of RBLs (daily reports.) In my experience as an admin, RBLs work very well. Yes, they will kick out some legit emails from time to time, but that's easy to deal with. And yes, they'll miss a fair amount of spam, too -- it takes time to add sites to the list(s).
Over ~1.5 years, the mail server for my previous employer kicked out exactly three (3) legit emails. The sender calls the person they were emailing; they tell me about the problem, and I add an exception to the rules. So, one innocent email killed every six months vs. letting in hundreds of spams per day is a fair trade in my book.
And thus is your own answer... If the ISP moves a known spammer to a different IP once they've been "found out", it's clear the ISP has no intention of properly dealing with spammers (i.e. kicking them out.) At that point, it would be marginally acceptable to blacklist entire subnets or the entire ISP -- but that's still a strongarm tactic.
Blacklisting more than one IP when only one has briefly been a problem is stupid. Listing an ISP's/16 because one customer -- with a/29 -- did something wrong is going way to far (like swating house flies with nukes.)
IMO, SMF is the single reason why I will not even jokingly advocate the use of Solaris 10. The claim that it does away with init.d scripts is simply a lie... it just puts the shell scripts somewhere else. And the most damning thing about SMF is that f'ing binary settings file that screams "windows registry" (that it duplicates ("archives") at every boot) -- this vs. the now well utilized/etc/defaults directory for application settings (which almost always shows many or all of the available settings and their defaults with descriptions as comments.)
You're confusing fields and frames... NTSC has 60 interlaced fields per second generating 30 frames per second. The reason you generally cannot see that flickering is due to the retentative properties of your eyes and the phosphor pixels in the TV. PAL is the same at 50 fields / 25 frames.
apt-get -u dist-upgrade and look at the packages it's going to remove, upgrade, and add. I stopped right there with the very first package... apache. I'm not in the mood to convert my apache1 to apache2 right now. (I also have to make sure it doesn't touch bugzilla at all. It's been highly customized.)
Btw:
[cramer:ttyp0]dominion:~/[12:17am]:uname -a Linux dominion 2.3.42-SMP #11 SMP Sun Feb 6 20:06:02 EST 2000 i686 [cramer:ttyp0]dominion:~/[12:17am]:cat/etc/redhat-release release 4.1 (Vanderbilt)
I have a slackware 2.1 machine (1.2.8) around here, too.
This is not 100% true. You don't have to upgrade portage to continue merging (or building) packages. Having had gentoo fubar portage one too many times, I kept it locked so it's not even a canidate for upgrading. (I don't mess with gentoo's much anymore.)
Yeah. I was looking for the source of his "30%", too. He also doesn't list any exact problems he had upgrading or anything about his proceedures.
The largest problem here is that the debian installer puts "stable" in the source list instead of an exact release. So, anyone unaware of the new release will not know they have to do anything more than usual -- apt-get update; apt-get upgrade. And dist-upgrade isn't as smart as it needs to be... it'll remove apache without even offering to install apache2.
... and the fact that SCSI drives are actually tested. I have never once, in 20 years, had a bad SCSI drive right out of the box. I've had numerous IDE drives bad straight from the factory -- one hadn't even been programmed.
SCSI does bet everything else out there on all but one point: price. And that's really the only thing many people ever look at. If you care about the data you're putting on the drive, you don't entrust it to cheap hardware.
If they are, in fact, the same servo hardware, why is it that the SCSI drives last for decades without fault but the IDE drives rarely last beyond 2 years? I have SCSI drives that are now slightly over 20 years old and they still work as well today as they did in '85 (altho' hideously slow by comparison.) The oldest, still functional, IDE drive I have is 4-5 years old. Most don't last beyond 2 years. (it varies from manufacturer to manufacturer, but very few last much longer than the warranty period.)
You might think that -- and that's the BS answer Azurues devs give too. However, such an attitude is pure blind ignorance. How many private trackers are their in the world? How many torrents are on each of those sites? How many users are part of those communities? Applying the azureus specific hack only to new torrents does nothing to protect all the existing torrents. Regenerating every torrent does nothing to protect the existing torrents -- it stops them from being accepted by the tracker, which actually makes it worse as the fallback is DHT.
Requiring, nay, demanding sites regenerate all their torrents is a lame answer and a dangerous precedent -- do you want to go through this again every 3 months when some other idiots do something stupid like this? It's also impossible. You're talking about recoding millions of torrents, forcing every single user to re-download each torrent (not just the az users, every f'ing user), and deal with the information leakage and "lost stats" for users who don't grab the new torrents before DHT hands out their personal and unique torrent. The Azureus developers really failed to give this shit any thought at all (which is all too common with them.) [where's the support for specifying peer sources per torrent, for example?]
I wouldn't touch that with a 50ft pole. My money says that swarm is being monitored for the next round of John Doe lawsuits. (esp. with the recently inacted laws.)
(all you have to do is join the swarm and sit back and log all the IPs reported by the tracker and from all the inbound connections.)
If he's doing things exactly like Azureus, then a torrent file can be retrieved from anyone known via DHT to be part of that swarm... it's called a magnet url.
This is the reason why DHT, as the monkeys released it, is a Bad Thing(tm). They should've err'd on the side of caution and assumed torrents were "private" unless explicitly marked otherwise. Because they added the "private" flag to the info dictionary, sites cannot retroactively privatize their torrents -- it changes the info_hash, which is the exact reason why the monkeys put it there (where it technically doesn't belong.)
Slashdot Mirror
Cisco is never upfront about the seriousness of any bugs... It hurts their stock price -- which is the ONLY thing Cisco cares about.
Wrong. This thing is certainly not "persistent storage". It certainly isn't when one is talking about a database. The contents will be lost a few hours after it loses power. This thing has a persistence measured in hours where hard drives have persistence measured in DECADES. And it's orders of magnitude slower than main memory -- 100-150MB/s vs. >1.8GB/s.
(In Linux at least, a chunk of main memory can be set aside for a RAM disk that's persistent across reboots -- as long as your BIOS doesn't re-zero the RAM.)
This is not true. However, so long as the line is connected to a phone switch, yes, they are required to process 911 calls on it. Bellsouth will also allow you to call their service center (780-2355?) where you can signup for service.
(There are a few "poor people" loopholes -- all that Universal Service bull...)
A) So apache doesn't have to process them. And B) so apache doesn't waste drive space logging the requests and resultant errors.
(And C) I'm too lazy to go through the 10,000 signatures and disable/delete the ones that don't apply to me.)
I've found IPS (formerly ip audit) in Cisco's IOS, while programmed by monkeys who don't pay much attention to what they're typing, does a pretty good job of cutting off a host of attacks at the router. Of course, it'll only look at what it's configured to watch and only knows about a select number of things -- the more it's told to watch for, the more memory and time it takes.
I have it watching web traffic and it's knocking down just about every script kiddie's IIS probe. (I don't run ISS, btw.)
...you *cannot* store your entire home directory over AFS...
This is 100% bullshit. I don't know how screwed up your network is, but it certainly is possible to place user homes inside AFS. Many an institution has done just this -- and for nearly 2 decades, even. (NCSU has been doing this since about 1986.)
What needs to be accessed in a user's home directory prior to authentication? The only thing that comes to mind is ssh keys (~/.ssh/authorized_keys), and they only need to be readable by the host and/or sshd which can be easily handled. (and technically, they don't have to be in the user's home.)
Yes. Redhat did it first. And redhat started out, in the early/mid 90's, more as a community than a business. I remember when redhat was a half dozen people -- a half dozen college kids -- designing a better packaging system, not a linux distribution. The follow-on's have been for-profit enterprises from day one. There are distributions older than redhat that have never become "money hungry", commercial enterprises. [Technically, SLS tried it first, but they were already half dead.]
The point of the GPL is certainly not to allow one to profit from the work of others; it's to ensure the openness of software. The only closed source software that comes to mind is the Netscape/Sun ONE/iPlanet directory server, which was a dead-end product when they bought it. (it's been bundled with solaris for years, so it's not been a fully commercial product for over half a decade.)
There are thousands of companies (and individuals) funding the development of various OSS projects. The primary motivation is a tax break, not altruism, or guilt. And the bottom line... redhat "gives back" far less than they collect.
...and take those contributations and make money...
...he wanted the money...
It worked for Redhat...
And for $5mil, I wouldn't give a shit about "community" either. And, in fact, I've "sold out" for far less before.
A new Cisco anything is f'ing expensive. ALL their shit is overpriced, however neat and all. Go look at their financial reports... they made (profit, not revenue) Four. Billion. Dollars. last year. And that's after accounting for R&D, staff, etc.
It's called "privacy director"... if there's no name and number to send to you, the caller is required to identify themselves to an automated attendant that gets played back to you when (if) you answer, at which point you can choose to block the call (or just not answer anything that shows as coming from privacy director.)
... well, except for that last part :-))
Having worked for/with telcos, just because nothing was sent to your phone via caller-id does not mean there isn't a call detail record for it. In fact, there's a CDR generated for every call origination and termination. And they're archived for a VERY long time.
(If your story is 100% accurate, they've broken so many laws, there should be lawyers lining up to represent you.
For 802.11B, the channels overlap... 1,6, and 10 can be used at the same time without stepping on each other (and various combinations of one low and one high channel.) Apartments, condo's, and often, townhouses are packed too closely for many resident's deploying an AP. If I turn on an AP, I'll flood between 10 and 14 apartments with the RF -- at standard power levels... at full "legal" power, half the complex can see it.
wtf are you talking about? You can get those things for 25$ on eBay. I have a stack of them that I paid 24$ each for them about 2 years ago -- before zynx stopped making them.
They're pretty good -- damn good for 25$. But they are certianly not "top of the line".
As the end user, maybe, but as the admin, it's pretty easy to see the effectiveness of RBLs (daily reports.) In my experience as an admin, RBLs work very well. Yes, they will kick out some legit emails from time to time, but that's easy to deal with. And yes, they'll miss a fair amount of spam, too -- it takes time to add sites to the list(s).
Over ~1.5 years, the mail server for my previous employer kicked out exactly three (3) legit emails. The sender calls the person they were emailing; they tell me about the problem, and I add an exception to the rules. So, one innocent email killed every six months vs. letting in hundreds of spams per day is a fair trade in my book.
And thus is your own answer... If the ISP moves a known spammer to a different IP once they've been "found out", it's clear the ISP has no intention of properly dealing with spammers (i.e. kicking them out.) At that point, it would be marginally acceptable to blacklist entire subnets or the entire ISP -- but that's still a strongarm tactic.
/16 because one customer -- with a /29 -- did something wrong is going way to far (like swating house flies with nukes.)
Blacklisting more than one IP when only one has briefly been a problem is stupid. Listing an ISP's
IMO, SMF is the single reason why I will not even jokingly advocate the use of Solaris 10. The claim that it does away with init.d scripts is simply a lie... it just puts the shell scripts somewhere else. And the most damning thing about SMF is that f'ing binary settings file that screams "windows registry" (that it duplicates ("archives") at every boot) -- this vs. the now well utilized /etc/defaults directory for application settings (which almost always shows many or all of the available settings and their defaults with descriptions as comments.)
You're confusing fields and frames... NTSC has 60 interlaced fields per second generating 30 frames per second. The reason you generally cannot see that flickering is due to the retentative properties of your eyes and the phosphor pixels in the TV. PAL is the same at 50 fields / 25 frames.
Btw:I have a slackware 2.1 machine (1.2.8) around here, too.
(it's the "portage" package, btw)
This is not 100% true. You don't have to upgrade portage to continue merging (or building) packages. Having had gentoo fubar portage one too many times, I kept it locked so it's not even a canidate for upgrading. (I don't mess with gentoo's much anymore.)
Yeah. I was looking for the source of his "30%", too. He also doesn't list any exact problems he had upgrading or anything about his proceedures.
The largest problem here is that the debian installer puts "stable" in the source list instead of an exact release. So, anyone unaware of the new release will not know they have to do anything more than usual -- apt-get update; apt-get upgrade. And dist-upgrade isn't as smart as it needs to be... it'll remove apache without even offering to install apache2.
Except, one cannot direct boot to an LVM volume. It takes some userland toolage to discover and activate all the volumes.
The only way around this is with an initrd, which I think is an ugly, hard-to-manage, hack. The other option is to not use LVM for the rootfs.
LVM is a handy thing. But it's NOT RAID; don't treat it like it is. And it's infinitely more complicated than RAID, managed by mdadm.
... and the fact that SCSI drives are actually tested. I have never once, in 20 years, had a bad SCSI drive right out of the box. I've had numerous IDE drives bad straight from the factory -- one hadn't even been programmed.
SCSI does bet everything else out there on all but one point: price. And that's really the only thing many people ever look at. If you care about the data you're putting on the drive, you don't entrust it to cheap hardware.
If they are, in fact, the same servo hardware, why is it that the SCSI drives last for decades without fault but the IDE drives rarely last beyond 2 years? I have SCSI drives that are now slightly over 20 years old and they still work as well today as they did in '85 (altho' hideously slow by comparison.) The oldest, still functional, IDE drive I have is 4-5 years old. Most don't last beyond 2 years. (it varies from manufacturer to manufacturer, but very few last much longer than the warranty period.)
You might think that -- and that's the BS answer Azurues devs give too. However, such an attitude is pure blind ignorance. How many private trackers are their in the world? How many torrents are on each of those sites? How many users are part of those communities? Applying the azureus specific hack only to new torrents does nothing to protect all the existing torrents. Regenerating every torrent does nothing to protect the existing torrents -- it stops them from being accepted by the tracker, which actually makes it worse as the fallback is DHT.
Requiring, nay, demanding sites regenerate all their torrents is a lame answer and a dangerous precedent -- do you want to go through this again every 3 months when some other idiots do something stupid like this? It's also impossible. You're talking about recoding millions of torrents, forcing every single user to re-download each torrent (not just the az users, every f'ing user), and deal with the information leakage and "lost stats" for users who don't grab the new torrents before DHT hands out their personal and unique torrent. The Azureus developers really failed to give this shit any thought at all (which is all too common with them.) [where's the support for specifying peer sources per torrent, for example?]
I wouldn't touch that with a 50ft pole. My money says that swarm is being monitored for the next round of John Doe lawsuits. (esp. with the recently inacted laws.)
(all you have to do is join the swarm and sit back and log all the IPs reported by the tracker and from all the inbound connections.)
If he's doing things exactly like Azureus, then a torrent file can be retrieved from anyone known via DHT to be part of that swarm... it's called a magnet url.
This is the reason why DHT, as the monkeys released it, is a Bad Thing(tm). They should've err'd on the side of caution and assumed torrents were "private" unless explicitly marked otherwise. Because they added the "private" flag to the info dictionary, sites cannot retroactively privatize their torrents -- it changes the info_hash, which is the exact reason why the monkeys put it there (where it technically doesn't belong.)