I very seriously doubt the deskstar caused IBM to give up. It was one version of a single product in a long line of products they produced.
Think about it. Prices are $1.4/GB, and people still complain about the price. At what point do you say "we're making...$.50 per drive we sell. Let's give up." ?
Re:Have you tried the Dewey Decimal System?
on
Internet Book Database?
·
· Score: 3, Informative
I'm in the process of doing the same thing, but I hit on something nice: the computer's great at putting things in order. So I scan or type in the ISBN, a perl script grabs the books information from the LOC(via z3950), and when I'm done, the system spits out a list of books in LOC order with the Title/Author next to it. As I go down the list of books, it naturally gets put in the right order on the shelf.
At least that's the theory. I'm over 200 books so far, and I've just finished about 1/3 of the books.
I know FAX happens. There's a standard for it. But PPP just doesn't make sense at all, unless you're talking about being a carrier and making VoIP invisible to the end user.
Phone calls in almost all cases are digital almost as soon as they leave your local handset. SONET (fiber connectivity) is built for DS3s, which are digital. They really have no idea about data or voice, just DS3(or OC3) frames.
There is no way to run PPP over VoIP. The problem is that you've already got IP connectivity. Why bother?
However, in this case, it looks like they're using G.711, which is essentially the same encoding as standard phone lines. In that case, you can get relatively decent modem speeds, but you can't really hold them for very long, as there IS a not-humanly-detectable delay in encoding(as much as 40ms). You won't notice it, but the modems will, especially at high speed.
What would be more impressive is if they offered G.729 compressed down to 14k. THEN you could use it while online with a dialup, and everybody'd be really happy.
The drafthouse has first-run movies as well as indie flicks. There are actually two drafthouses. The one in northwest Austin is pretty much exclusively first-runs.
The law specifically says that a site has to be kiddie porn, as defined by their statutes. So: Today it is kiddie porn, tomorrow...kiddie porn, then...kiddie porn!
Not only that, but a judge has to sign off on EACH AND EVERY SITE to EACH AND EVERY ISP. That's a pretty safe system.
T1 delivered over HDSL is not fraud. The telco only needs to present you with a T1. It's up to them to get it to you. Odds are pretty good that at somepoint past the CO, they don't even use copper at all. Deal with it, and save the telco bashing for things that really matter.
This is incorrect. I just measured across the HDSL circuit here. -126VDC, no repeaters that I know of (3km circuit). Circuits in parallel (essentially what we have here) have equal voltage across them. Having to engineer the voltage for every circuit would be a royal pain in the ass. Actually for fun, take your HDSL CPE end, and take a good autotransformer and diode bridge. Connect the diode bridge + and - to T and R (polarity doesn't matter) -- now slowly bring up the autotransformer. The CPE end won't even light up until around 85V or so.
That's odd. Perhaps HDSL runs differently, but the references say that a T1 should run at 2.7-3.3v, from AT&T publication 43801.
Consider that most COs run on -48v. To get 130v, they need to multiply voltage 2.7083 times. To get -3v(avg of 2.6-3.3), divide -48v by 16.
... You can get fancy with something called Non-Facillity Associated Signalling which lets you cluster up to 8 DS1s' worth of D channels into a single B channel;
There's actually no(real) limit on how many DS1s are attached to a signalling channel short of logical size. I think it's a byte-wide field.
(I don't think it's called a D channel anymore but I'm not sure on this.)
At that point it's called an H channel, but I've never met someone that called it that.
I briefly mentioned DS2s and DS3s. A DS2 is just an aggregation of 4 DS1s. The data bandwidth is not exactly 4*1.536mbps (frame is stripped out)
A DS2 has it's own framing, although you'd be lucky to find someone in telco that knows how it works.
because there are some slop bits set aside because the individual T1s coming in will not be synchronized and the slop bits take care fo that.
I'm not really sure what you mean by this. Clock is regenerated by the remote end points of a DS3. There is no clock information carried through the circuit at the DS1 level.
It's the same with DS3s, which are made up of 7 DS2s. Not really exciting, because all the work was done at the DS0/DS1 level.:-)
No, a DS3 is a completely different beast, with its own framing,coding, and timing rules.
Electrically, a DS1 is usually sent as an HDSL circuit these days; there really aren't any T1s to speak of anymore. DS = Data Specification (IIRC), where a T1 is just a DS1 with the electrical spec glued to it.
To clarify: T1 is the spec for transmitting a DS1 over copper in the US. HDSL is commonly use to emulate T1.
Normally you have -130VDC on the line (supplied by the CO end)
Um, no. Voltage supplied at the CO is completely determined by how many repeaters are on the line. You should end up with something like 12 volts at the CPE. -130VDc at the CPE would burn up just about anything you put on it, and would definately screw up a sinsitive test set.
So, there's almost everything you need to know about T1s. No need to buy a book that goes into the same detail.:-)
Close. Here's what you _really_ need to know: The guy at the telco almost certainly does NOT know how this stuff _really_ works. I've had to explain alarm codes to more than one "senior engineer". DON'T let him get off the phone. If he doesn't have a test set, hold on the phone until he does. Escalation is your friend.
Why people have trouble with T1
on
T1: A Survival Guide
·
· Score: 3, Informative
The reason so little time is spent on the details of T1 framing and coding is because it's really simple. T1 is hard for many people to understand because they try and make it hard. Coding is really simple. Framing is simple as well. It never changes. Moreimportantly, the guy on the other end of the line troubleshooting the circuit probably won't know how to fix it. Once you know what RED, YELLOW/AIS/BLUE alarms are and what they really mean is going on you can solve T1 problems very quickly.
As for test equipment, what test equipment do you want information for? There are several test boxes just in the T-bird family, and each one has a different setup. It would make the book rediculously large to cover them all, and then people would bitch because it didn't cover digital lightwave test equipment, etc.
Actually, the entire process will not be swapped out. The in-kernel descriptor table will remain in memory. Otherwise you couldn't deal with locking issues, etc.
Have you mentioned your problems to freebsd-config? I'm sure they'd love to know about your problems, since they're responsible for writing and maintaining the installation system.
A file descriptor is a per-process entity. Yes, there's a big table of file descriptors that exists for the entire sstem, but file descriptor 5 for process a is not file descriptor 5 for process b. Not even if they point to the same file/pipe. A case in point is FD 0, aka stdin. Every process starts out with a stdin on FD 0.
More important is how do you tell the kernel what file descriptor 5 pointed to? What if the file/pipe doesn't exist any more?
I'm using a diskless setup on FreeBSD with an Intel NIC. Boots in about 15 seconds, and the only noise is the power supply and CPU fan. I can probably get rid of the CPU fan. I might even try cutting the PS fan, since the load on the PS is next to nothing.
PPP sends the username/password in plain text. If the password is encrypted, how are you supposed to send it plaintext? I suppose you could use a symmetric cipher, but then you'd have to have the key hardcoded someplace. That doesn't seem secure either, does it?
The other option is to require the remote end to authenticate to you. Unfortunately, I doubt there's an ISP out there that would do that.
In other words, the developers are entirely correct.
Here in Austin we have this lovely pay-per-view service that lets you rent a movie for 2-3 days and watch it as much as you'd like. Rewind, pause, Fast Forward, it's all there. Unfortunately, I'd be willing to bet it infringes on either TiVo's patents or Sonic Blue's. At any rate, I imagine TW'll be taking them up on it quick enough. Their end goal is to allow you to have a TiVo at the headend rather than in your house, thus making them money for storage and service.
2.5 carved out something like 5G of space for these commercials. They're taped at 2am off of TLC or something.
If you're TiVo is so small that you'd have to worry about it, it won't tape them. As far as I could tell, the Lexus thing happened only when you booted the TiVo. Mine's always on, so I didn't even notice it until nfs crashed the box.
And as always, remember that the Live TV button is your friend. It'll abort just about any nasty item the TiVo decides to do, other than smake and spray sparks.
Pardon me, I should have been a little more verbose.
"...probably just a random occurance, but worth mentioning"
is my point of concern. It's worth mentioning, but there doesn't seem to be a sense of concern. No link to a coredump, no mention of a stack trace, no information whatsoever to try and resolve the bug. This is one of the major "weak" points of Linux(and *BSD). People say "it crashed" but don't give any information to try and resolve the problem. A user should not just accept a crash/bug as a random occurance. They need to give as much information as possible to help track down what is causing the bug.
Slashdot Mirror
I very seriously doubt the deskstar caused IBM to give up. It was one version of a single product in a long line of products they produced.
Think about it. Prices are $1.4/GB, and people still complain about the price. At what point do you say "we're making...$.50 per drive we sell. Let's give up." ?
I'm in the process of doing the same thing, but I hit on something nice: the computer's great at putting things in order. So I scan or type in the ISBN, a perl script grabs the books information from the LOC(via z3950), and when I'm done, the system spits out a list of books in LOC order with the Title/Author next to it. As I go down the list of books, it naturally gets put in the right order on the shelf.
At least that's the theory. I'm over 200 books so far, and I've just finished about 1/3 of the books.
This is gonna take some time.
I know FAX happens. There's a standard for it. But PPP just doesn't make sense at all, unless you're talking about being a carrier and making VoIP invisible to the end user.
Phone calls in almost all cases are digital almost as soon as they leave your local handset. SONET (fiber connectivity) is built for DS3s, which are digital. They really have no idea about data or voice, just DS3(or OC3) frames.
There is no way to run PPP over VoIP. The problem is that you've already got IP connectivity. Why bother?
However, in this case, it looks like they're using G.711, which is essentially the same encoding as standard phone lines. In that case, you can get relatively decent modem speeds, but you can't really hold them for very long, as there IS a not-humanly-detectable delay in encoding(as much as 40ms). You won't notice it, but the modems will, especially at high speed.
What would be more impressive is if they offered G.729 compressed down to 14k. THEN you could use it while online with a dialup, and everybody'd be really happy.
No, one-time pad is mathematically proven as unbreakable. It's the _ONLY_ proven unbreakable envryption method.
Things ARE random. The noise made by compressed gas escaping from it's container is an example. So is stellar background radiation.
The drafthouse has first-run movies as well as indie flicks.
There are actually two drafthouses. The one in northwest Austin is pretty much exclusively first-runs.
The law specifically says that a site has to be kiddie porn, as defined by their statutes. So:
Today it is kiddie porn, tomorrow...kiddie porn, then...kiddie porn!
Not only that, but a judge has to sign off on EACH AND EVERY SITE to EACH AND EVERY ISP. That's a pretty safe system.
That's exactly what HDSL is. The only difference is that it's 2 wire rather than 4 wire, wich lets them give you a backup circuit in the same cable.
T1 delivered over HDSL is not fraud. The telco only needs to present you with a T1. It's up to them to get it to you. Odds are pretty good that at somepoint past the CO, they don't even use copper at all.
Deal with it, and save the telco bashing for things that really matter.
This is incorrect. I just measured across the HDSL circuit here. -126VDC, no repeaters that I know of (3km circuit). Circuits in parallel (essentially what we have here) have equal voltage across them. Having to engineer the voltage for every circuit would be a royal pain in the ass. Actually for fun, take your HDSL CPE end, and take a good autotransformer and diode bridge. Connect the diode bridge + and - to T and R (polarity doesn't matter) -- now slowly bring up the autotransformer. The CPE end won't even light up until around 85V or so.
That's odd. Perhaps HDSL runs differently, but the references say that a T1 should run at 2.7-3.3v, from AT&T publication 43801.
Consider that most COs run on -48v. To get 130v, they need to multiply voltage 2.7083 times. To get -3v(avg of 2.6-3.3), divide -48v by 16.
... You can get fancy with something called Non-Facillity Associated Signalling which lets you cluster up to 8 DS1s' worth of D channels into a single B channel;
:-)
:-)
There's actually no(real) limit on how many DS1s are attached to a signalling channel short of logical size. I think it's a byte-wide field.
(I don't think it's called a D channel anymore but I'm not sure on this.)
At that point it's called an H channel, but I've never met someone that called it that.
I briefly mentioned DS2s and DS3s. A DS2 is just an aggregation of 4 DS1s. The data bandwidth is not exactly 4*1.536mbps (frame is stripped out)
A DS2 has it's own framing, although you'd be lucky to find someone in telco that knows how it works.
because there are some slop bits set aside because the individual T1s coming in will not be synchronized and the slop bits take care fo that.
I'm not really sure what you mean by this. Clock is regenerated by the remote end points of a DS3. There is no clock information carried through the circuit at the DS1 level.
It's the same with DS3s, which are made up of 7 DS2s. Not really exciting, because all the work was done at the DS0/DS1 level.
No, a DS3 is a completely different beast, with its own framing,coding, and timing rules.
Electrically, a DS1 is usually sent as an HDSL circuit these days; there really aren't any T1s to speak of anymore. DS = Data Specification (IIRC), where a T1 is just a DS1 with the electrical spec glued to it.
To clarify: T1 is the spec for transmitting a DS1 over copper in the US. HDSL is commonly use to emulate T1.
Normally you have -130VDC on the line (supplied by the CO end)
Um, no. Voltage supplied at the CO is completely determined by how many repeaters are on the line. You should end up with something like 12 volts at the CPE. -130VDc at the CPE would burn up just about anything you put on it, and would definately screw up a sinsitive test set.
So, there's almost everything you need to know about T1s. No need to buy a book that goes into the same detail.
Close. Here's what you _really_ need to know: The guy at the telco almost certainly does NOT know how this stuff _really_ works. I've had to explain alarm codes to more than one "senior engineer". DON'T let him get off the phone. If he doesn't have a test set, hold on the phone until he does. Escalation is your friend.
The reason so little time is spent on the details of T1 framing and coding is because it's really simple. T1 is hard for many people to understand because they try and make it hard. Coding is really simple. Framing is simple as well. It never changes. Moreimportantly, the guy on the other end of the line troubleshooting the circuit probably won't know how to fix it. Once you know what RED, YELLOW/AIS/BLUE alarms are and what they really mean is going on you can solve T1 problems very quickly.
As for test equipment, what test equipment do you want information for? There are several test boxes just in the T-bird family, and each one has a different setup. It would make the book rediculously large to cover them all, and then people would bitch because it didn't cover digital lightwave test equipment, etc.
Apparently you didn't actually click through to the link. The advisory mentioned is not available at freebsd yet.
In other words, if you haven't kept up to date with ucd/net-snmp, you've got a problem.
Looking at the net-snmp code, it appears it was fixed last year sometime, actually.
What we need is that transparent aluminum! Why's it taking so long?
Actually, the entire process will not be swapped out. The in-kernel descriptor table will remain in memory. Otherwise you couldn't deal with locking issues, etc.
Have you mentioned your problems to freebsd-config? I'm sure they'd love to know about your problems, since they're responsible for writing and maintaining the installation system.
A file descriptor is a per-process entity. Yes, there's a big table of file descriptors that exists for the entire sstem, but file descriptor 5 for process a is not file descriptor 5 for process b. Not even if they point to the same file/pipe. A case in point is FD 0, aka stdin. Every process starts out with a stdin on FD 0.
More important is how do you tell the kernel what file descriptor 5 pointed to? What if the file/pipe doesn't exist any more?
I'm using a diskless setup on FreeBSD with an Intel NIC. Boots in about 15 seconds, and the only noise is the power supply and CPU fan. I can probably get rid of the CPU fan. I might even try cutting the PS fan, since the load on the PS is next to nothing.
PPP sends the username/password in plain text. If the password is encrypted, how are you supposed to send it plaintext? I suppose you could use a symmetric cipher, but then you'd have to have the key hardcoded someplace. That doesn't seem secure either, does it?
The other option is to require the remote end to authenticate to you. Unfortunately, I doubt there's an ISP out there that would do that.
In other words, the developers are entirely correct.
More accurately, Quantum encryption is OTP. The quantum part comes in when you generated the pad.
More accurately, Quantum encryption IS OTP. The quantum part comes in when you generated the pad.
Here in Austin we have this lovely pay-per-view service that lets you rent a movie for 2-3 days and watch it as much as you'd like. Rewind, pause, Fast Forward, it's all there. Unfortunately, I'd be willing to bet it infringes on either TiVo's patents or Sonic Blue's. At any rate, I imagine TW'll be taking them up on it quick enough. Their end goal is to allow you to have a TiVo at the headend rather than in your house, thus making them money for storage and service.
2.5 carved out something like 5G of space for these commercials. They're taped at 2am off of TLC or something.
If you're TiVo is so small that you'd have to worry about it, it won't tape them. As far as I could tell, the Lexus thing happened only when you booted the TiVo. Mine's always on, so I didn't even notice it until nfs crashed the box.
And as always, remember that the Live TV button is your friend. It'll abort just about any nasty item the TiVo decides to do, other than smake and spray sparks.
Pardon me, I should have been a little more verbose.
"...probably just a random occurance, but worth mentioning"
is my point of concern. It's worth mentioning, but there doesn't seem to be a sense of concern. No link to a coredump, no mention of a stack trace, no information whatsoever to try and resolve the bug. This is one of the major "weak" points of Linux(and *BSD). People say "it crashed" but don't give any information to try and resolve the problem. A user should not just accept a crash/bug as a random occurance. They need to give as much information as possible to help track down what is causing the bug.