LICQ works fine for me. Maybe a firewall is in the way. My school firewall started blocking it (for some reason they decided to block all UDP), but I complained and after a few days it worked again.
It's not a firewall issue; if you cannot connect to the recipient directly, it will go through the ICQ server. I've been using ICQ for many years now and know its little bugs quite well. ICQ's servers seem to be dropping approximately 40% of packets not coming from v7 clients. Currently the only v7 clients are Mirabilis' own clients. This isn't a new thing, they've dropped packets for some time but they are getting more aggressive.
You can also use GAIM (or any AIM client) to access the ICQ network, using the AIM protocol over a TCP connection. Enter your ICQ number as your screen name, and use your ICQ password.
That works well in theory but libfaim does not support offline messages, nor does it support client modes (away, NA, etc.). I'm using the AIM Transport via jabber right now to keep in contact with my ICQ contacts but it's a temporary measure.
Hmm... that is strange, I log into ICQ daily with Licq (v1.03) . Only problem I've seen recently, is that it doesn't erase messages that got sent to you while you are offline... so you keep receiving them until you log in with an official client
Heh, I've never had that problem. LICQ works fine so long as you're sending direct; if you have to send through the server LICQ has about a 40-60% chance of getting the message across. I've spoken to several people using LICQ (v1.03 yes) and that is the general consensus.
So, I've jumped off the proprietary IM bandwagon. Fuck 'em. I actually helped Sefi and Ari with some early early ICQ problems but ever since joining up with AOL it's been a downhill slide.
I was forced out of ICQ since their servers now drop packets not coming from v7 clients and LICQ is definately not v7; hell I don't even think it's being developed anymore.
AOL is blocking non-proprietary clients and the others out there are too small to worry about... I've switched to Jabber (using the Psi client).
Why Jabber? Interoperability. I can connect to a dozen other IMs as necessary. Right now I'm "cheating" ICQ by using the AIM transport which seems to work alright. But the biggest reason I like Jabber is that I also have the server source, and have my own Jabber server for my company.
Sure there are only 2 people on it right now but that's the point -- It's totally decentralized. I can get a hold of any other jabber client by searching THEIR server. You don't need to be on the same server to communicate. Very cool.
Jabber has a few interesting transports too like IRC and email. If it doesn't have what you want, write it, as the spec is open and will stay that way.
I was avoiding Jabber for a long time for several reasons: the clients were all GTK or Java or BUTT UGLY, they were big big big, and petty much all the clients popped up new messages. That's a royal pain in the ass when you actually use your computer. Psi has the option to just raise the window but it took focus too. I helped hack Psi so that its "Raise window" didn't take focus which is exactly what the old ICQ and LICQ did. Perfect. I can type away at 100WPM and if a message comes in I don't end up spilling half the paragraph into the IM window. I can shrink it small like ICQ/LICQ. The Psi developer promises to try and add in global-key support so I can map alt-backspace to pull up the next message. That's all I need in an IM.
That's my solution for closed-source proprietary bullshit IM protocols: route around them. Jabber is a great way to do so becuase it's decentralized and totally open.
Why, I'm paying about 10x what you are, specifically FOR top priority service over consumer-class. There's nothing ethically wrong about it, as you pay for the service you expect.
This isn't really true. When you do a voice T1, this is true, but when doing data, you'll normally only lose 8kbit/sec to overhead (using ESF/B8ZS)... So rather than 1.544Mbit/s, you get 1.536Mbit/s.
Close, but not quite right.
A DS1 (T1 without the electrical specification) is 193 bits sent 8000 times per second. One of these bits is reserved for framing; i.e. you can't touch it. That leaves 192 bits sent 8000 times per second. Calculate that out and you get your "raw" speed of 1.536Mbps.
B8ZS came from AMI. AMI is used on voice circuits only -- it has no provision for excaping long strings of zeroes and in the voice-only days it didn't matter. It was statistically next to impossible to keep an 8-bit PCM coded line at 00000000 for any length of time. However when data circuits started popping up they needed a way to keep clock sync for long strings of zeroes.
B8ZS is a method to encode long strings of zeroes (8 to be exact) -- Like AMI, 1's are sent as an alternating stream of +1 and -1 to keep the net DC voltage of the link at 0V. Every '1' bit allows the clock recovery circuitry to sync up to keep the bit detection centered in the middle of every bit. '0's, however, are the absence of a pulse. Long strings of 0's cause the clock recovery circuitry to start falling out of sync. B8ZS sends eight zeros as a specially coded binary string: for example +1 +1 0 0 -1 -1 0 0 +1 +1. I made that up; I don't believe that is the actual pattern but what is important to note is that instead of the 1's being alternating in polarity, they are the same polarity. This is known as a BiPolar Violation (BPV). Normally the recovery circuitry sees this as an error but if it sees a particular pattern, it instead spits out eight 0's. Because it's a BPV, there is no need to use any kind of escape code so that you can tell the difference between eight 0's and whatever code they use to represent it.
That leaves framing. Remember that 1 frame bit at the end of each 192 bit sequence? In olden times that frame bit was always a '1' and was used to help keep the endpoints in sync. Since newer equipment is very good at keeping frame sync, that bit is used as an 8kHz channel between the two DS1 endpoints and can send out of band (OOB) singal information between them. Things like putting remote ends into loopback, status information, etc.
The telco grouped 12 frames together and called them a Super Frame (SF, and yes I do think of wrestling every time I go over this). Later on they decided to group 24 frames together and call them an Extended Super Frame (ESF). Why the grouping? Robbed Bits.
Robbed Bit Signalling is a way for the telco to indicate the line status. On hook, off hook, busy, ring(back). Your telephone conversation is sampled at 8bit/8kHz and then trunked into a DS0 on the DS1. There are 24 DS0s in a DS1. 8*24 is 192, plus the frame bit is 193. Now to indicate line status over the trunk, the telco created SF and uses that group of 12 frames to steal the LSB of every DS0 on the 0th and 6th frames of the SF to give them A and B signalling bits. Two bits gives you 4 line states. Later on, they wanted room for expansion, so ESF came along and the DS0 LSBs are stolen on the 0th, 6th, 12th and 18th frames of the ESF. Traditionally those C and D bits are just a copy of the A and B bits, but this isn't guaranteed.
ISDN doesn't use robbed bit signalling; they take 23 DS0s for data (as 23 8-bit channels) and then take the 24th DS0 for signal information. Since a DS0 is 64kbps, there's a lot of waste if you just use a D channel for a B channel (or even for 23 B channels) -- that's where NFAS (Non-Facility Associated Signalling IIRC) comes into play: You can gang up to 8 PRIs to share one D channel. So you lose 1 BRI on the DS1 with the D channel, but the other PRIs have 24 D channels. We use that to max out the number of dialup lines we can provide per NAS. Of course, the problem with doing NFAS is that if you lose your D channel, you lose up to 7*24+23 voice/data circuits as well. Most NFAS installations have a backup D channel as well.
So, after that long-winded explanation: You lose no data due to the overhead of ESF/B8ZS. You lose your frame bit which drops you to 1.536Mbps instead of 1.544Mbps, which is the raw speed of a DS1. You don't even lose out if you use a channelized T1 over a nonchannelized one. You *do* lose out on the full capacity of a DS1 if you have it provisioned for PRI instead of DEA (DEA is a Canadian term, I forget what the U.S. term is), since you lose a DS0 to signalling (and with NFAS that problem becomes smaller, but you still lose out on your "theoretical maximum"). And if you're a voice user (this includes analog modems), you lose a bit every 6 frames but since you don't know when the telco is going to steal that LSB, you essentialy have a 56k line. v.90/v.92 modems actually do try and determine when the telco robs the bits when they trainup but that still doesn't push you closer to 64k.
It gets a bit messier when you bring DS1s together into DS2s and DS3s, because there are "slop" bits which are used to overcome the problem with all these DS1s coming in out of sync from each other.
So, if you're upgrading, you really ought to reinstall no matter what OS you're running.
What are you smoking? Even cheap crack won't give you that kind of buzz...
When you first boot up, you're right -- you won't get all the nifty new features. However you do not need to <cough> reinstall -- just recompile the kernel and any key apps you run. You will not see a performance increase on your P4 by recompiling everything. Hell 99% of the time the compiler is generating i386 or i486-optimized code!
Not even on Windows do you get much added benefit by reinstalling -- the drivers are i386, the applications are i386, everything is compiled for the lowest common denominator. The higher-end drivers will be optimized for P5 or P6, but that's about it unless you have some really specialized hardware or tweaked drivers for multimedia codecs.
Windows blows chunks for doing major hardware upgrades because the OS becomes confused when you change "too much" at once. It blows chunks because most of the configuration is stored in a proprietary binary format. It blows chunks because its only partially able to come down to a textmode level so you can clean up. NT is better at this than Win95/98/ME, but it's still not close to the flexibility you have with Linux/FreeBSD. One of my most favourite things is how you can pull a HDD out of pretty much any i386 platform and snap it into another one and boot up. If you compile in a ton of network drivers as modules, you can damn near get net access on any computer with that same drive. Try that with Windows.
That's an okay hint, but why not try this? I've been doing it since the early 2.2 kernels:
Put all your patches (.gz or.bz2) in/usr/src (or wherever your linux source is)
from/usr/src, type linux/scripts/patch-kernel
... The script will churn away, patching up to whatever latest patch you have...
now enter the linux/ directory and run make oldconfig
that will run through the current.config and prompt you for any new config items
now the standard make dep clean bzImage modules modules_install is in order.
From there, I copy arch/i386/boot/bzImage/bzImage.[kernelver] and update lilo.
I find this is the cleanest and fastest way to patch a kernel. The patch-kernel script will stop if it runs into trouble and you can try to fix it. Be sure to remove any.rej and.orig files before rerunning the patch-kernel script or it will think there's still trouble.
the reason I can't reference a program right now is that I burned some of this noise onto a CD years ago and have been using it as needed ever since.
I, and I'm sure others here, would love more information on this. Perhaps even a link to the.wav of this magical CD for others to mirror... I'm assuming that mp3'ing it would just destroy the charasteristics.
I've never heard of this before but hell, I'm willing to give it a shot.:-)
It would be interesting to see some stats about how many/.er's have the toolbar on after 'x' days
I intend on keeping it there... not that I have ever gone to anything OSDN other than slashdot and k5 (which is not technically OSDN but....) Seriously though, that bar bugs you that much? Jesus, you must be one anal mofo.
You run an extremely powerful fancy GUI on a Pentium 4 1ghz on an IDE slow harddrive?!?!?!?!?!
If the damned program chews up enough memory that it has to eat into swap on any of my systems, it's out the window.
In fact, on the laptop I'm typing this on right now, I have turned off the swap drive. My desktop needs should never need more than 256M of memory, ever.
Yes I understand disk access can be slow but that's what the linux cache is all about. I don't have any trouble with Konqueror, Opera or even that pig of an OS...er...browser, Mozilla. If Nautilus hits the drive more than Moz, it's broken, and no amount of you bitching about my IDE drive is going to speed it up.
We recently had a new house built. During the construction locks were install that have a pin that enables the builder to use a common key for all the locks in all the houses he was working on.
I knew there were such things as skeleton keys and so on, but I did not know that they were so prevalent! Thanks for this little tidbit of info, we're planning on having a house built soon.
I would relate M$ to the builder, and the locksmith to the security boards.
As would I. I don't moderate but your post deserves a +5. Very informative and insightful. Thanks!
Come on, if you're going to flame me, at least make sense. I replied to a post about PHP, gave some PHP code examples as to why PHP is bad, and you've come back with that Perl users' mainstay: use strict;
I did read your post; I noticed that you had one reference to PHP in there, and I also took into account the subject line and came to the conclusion that you were knocking both Perl and PHP, as Perl has some of the same problems (creating variables out of thin air and silent conversion between incompatible types mainly) as PHP. It was a thought-out flame. Honest.
My personal favorite bit is the way you can suddenly create a new instance variable on a whim, just by assigning a value to
$this->varName, halfway down a random function.
This, and I would think to say that all your piss-poor examples of why Perl is bad are cured with one statement:
use strict;
Stop spreading FUD. I've seen and worked with many large, OO and non-OO Perl scripts which are a joy to maintain. You can get bad code in any language. Perl lets you shoot yourself in the foot if you want to. My personal preference is not to hire these types of programmers instead of complaining that the language is too flexible.
"If someone breaks into your house because you had a lock that could be bypassed with a special lockpick, it's not the lockmaker's fault, but the fault of whoever it was that gave you the special lockpick"
I disagree.
When I buy a lock, I expect it to be secure, and I expect that the manufacturer has tested the lock against most common circumvention methods. I would be damned pissed off if my lock were openable by using any old key blank.
Similarly, when I buy server software, I expect it to hold up against point-blank buffer overflows and backdoors/side effects so large you could drive a truck through. I mean jesus, I can get free software where the authors have spent more time making sure that stupid shit doesn't get through. Some code monkey getting paid $x/hr should at least have a monetary incentive to check over the code, shouldn't they??
Or let's take a look from a different angle. I pay money for software. If it costs me money and time when it falls down, I expect to be able to get money out of the manufacturer or at least get timely fixes or decent technical support. What am I paying them for anyway?
nfortunately, it doesn't look like they have much on the 5250/5251 series (which appears to only be able to support a VCI/VPI of 0/38 which won't work with a lot of telcos anyway).
I'm not trying to use it with a telco; strictly back-to-back. They're SDSL bridges and, barring anything dumb in the firmware, should be able to work this way if I can get one of them to provide clocking.:-) I know there are other modems on the market but these seem to be damn cheap and plentiful, moreso than the 5800s and so on.
(BTW: I figured out how to change the ATM configuration so even that's not an issue anymore.)
All the ones I've mentioned above, when set to factory defaults, can be telnetted to if you set your computer to 192.168.254.1 (/24) and telnet to 192.168.254.254.
Do any of those mentioned have weird-ass configuration utilities or do they ask that the configurations be done via the telnet interface?
I tried a few variations of this but I have not been able to obtain a response from the modem, nor have I seen any documentation on using the telnet interface from any of my searches. I do, however see tons of info on the telnet interface for the other dsl modems you mention. I am fairly (95%) certain that this is not supported on the 5250 but will see what I can find.
Do you know of any other IP pairings commonly used by Efficient Network's products?
On the Efficient 5800 series units I've worked with you can connect a 9pin serial->RJ45 cord from the serial connection on your computer to the blank port on the back of the unit (it's the management port, it just isn't labelled) and then connect with minicom/hyperterm.
That's the first thing I tried too.:-) Unfortunately there are no serial ports, RS232 nor TTL level. (I spent an hour or so with a scope on every suspicious looking land pattern, constantly resetting the modem and looking for a datastream that smelled like async serial. No luck so far.:-(
Not sure if it will help - you may have already seen it (watch, it will be your site):
Not my site, but I already did find this in my previous searches. Same with snurgle.org; that guy hasn't found it either. I'm hoping I'll succeed since I've at least attempted to invoke the Slashdot Effect.:-)
I appreciate the try though, this app has got to be somewhere.
The beauty of open-source is that anyone can create advanced configuration tools like the one you describe without the technical and moral restrictions of proprietary and closed software!
While your post sounds about as sarcastic as one can muster without sounding like a total ass, that is exactly what I'm working on; however I can't rewrite the utility until I can get the packet format down, and that's what I need the Win32 utility for!
here is an excerpt from my notes so far. I have documented the flashing process about as well as I can manage, but I don't know if the format is much different for the configuration utility or not.
Most of the SpeedStream models can be configured with a telnet-based interface.
The 5250/1 don't have this. They don't have an IP, as they are bridges, not firewalls or routers.
I have the flash upgrade utility and, after cracking open my TCP/IP refrence and combing through 802.3 SNAP frame bitmaps, the flash utility (and I am guessing the configuration utility as well) use specific ethernet frames toc ommunicate with the processor on the SpeedStream 5250.
Here is some more info from my notes:
Okay I'm looking at 802.3 SNAP frames:
The PC with the flashing program sends out a raw frame:
0000: ff ff ff ff ff ff 00 50 04 66 a4 02 00 46
broadcast from 00:50:04:66:a4:02, len 0x0046
000e: aa aa 03
0011: 00 20 ea 00 01
I know it's a SNAP frame because 0xaa 0xaa 0x03 is the signature for the SNAP header.
Now the OUI is normally 0x000000 but here it is 0x0020ea. That is the first half of the MAC for both of these SDSL bridges, and I am willing to bet that all 5250s have this as the start of their MAC address.
The last part of the SNAP header is the type: 0x0001.
The length of 0x0046 takes the data from 0x0e through to 0x53.
The flashing computer keeps sending this until it gets a response.
Anyway as you can see I've been buggering around with this for a while. I've documented the flashing procedure as best I can but it's obvious that this isn't as simple as telnetting to an IP. These devices use special ethernet frames to communicate and pass everything else, just like a good little bridge should
I find the people here slamming MySQL are often doing so based on their theoretical, rather than practical knowledge. But perhaps you are different. I'd like to see you back up your claim.
Here is a recent (MySQL 3.23.26beta and PGSQL 7.1 CVS pre-beta) benchmark. Now I know that benchmarks are the devil's tools, but he really seemed to try and make it a balanced, true-type of benchmark. It is interesting to look at his 1999 benchmark between the two too, where MySQL appeared faster on simple selects and non -concurrent writes to tables. I forget (and don't see it mentioned) if Tim Purdue actually turned off the fsync action that Postgres leaves on by default. If not, it could have explained some of the slowness of Postgres at that time.
My personal experience with older MySQL is that it is unstable and buggy. We used it for our RADIUS backend for about 3 years and it fell over regularly without much effort. About 18 months ago I replaced it with GNU-RADIUSd and Postgres and -- with four times the load -- it has yet to fail. This wasn't super-high-end stuff either. We're talking about 300 dialup lines with a couple RADIUS daemons making SQL calls to update user logins and time spent when logged out. With MySQL it was 48 lines and a single daemon and I was restarting MySQL so much I wrote a script to do it for me (about five times a week or so).
I am glad to hear that MySQL works for you; chacon son gout, as the French say (when they don't have accents handy). However based on my experience and the experiences of those who at least appear to be doing unbiased benchmarking, and also based on my need for referential integrity, ACID compliance and robustness, MySQL loses. Hell even those using it for pure speed are losing too, since it isn't the fastest, despite what MySQL, Inc. claims.
You're giving/. as an example of a rock-solid stable system? I surely hope you're kidding./. Has fallen up and down more times than I care to remember.
IIRC,/. heavily caches both stories and the front page to avoid load on the MySQL server. Before this was done the crashes were a lot more visible. Now, you just don't see new comments until the cache is refreshed. This is both a good and a bad thing, but it does not show that MySQL works well under load.
/. Also shows its MySQL troubles when you try to log in or change your viewing prefs; if the SQL server is down, you get the threaded (ick) cached page instead of what you want.
here is a phpbuilder test that helps back up my claims.
Which MySQL hasn't got, no matter how you look at it.
Postgres has shown time and time again that it blows the shit out of MySQL for any kind of select statement where your 'where' clause is even just slightly more complicated than 'x = y'. Even for simple selects, Postgres performance scales waaaaay better than MySQL. We're not talking hundreds of clients, either; we're talking dozens. MySQL falls flat on its face under heavy load.
And if your application just requires the simplest of simple selects, a hashed flat file is faster than MySQL because you don't actually have to parse up the SQL statement and return the result in a formatted fashion!
Face it: MySQL is a neat toy but that's about it. All this pandering about what 4.0's got now and how they think it's mission-critical-ready is bullshit, plain and simple. We've got an open-source, free ACID-compliant database already. MySQL has lost, they just don't know it yet.
The problem with this system is that you end up trusting everyone in the city to supply your internet access.
Actually it's not so bad at all. You lease out a part of their basement and build a room (or just use a wire cage or enclosure) and lock the damn thing. Pay a little up ahead and get a separate disconnect and of course run a UPS on the power feed. The idea is to be independent other than the physical quarters.
Slashdot Mirror
LICQ works fine for me. Maybe a firewall is in the way. My school firewall started blocking it (for some reason they decided to block all UDP), but I complained and after a few days it worked again.
It's not a firewall issue; if you cannot connect to the recipient directly, it will go through the ICQ server. I've been using ICQ for many years now and know its little bugs quite well. ICQ's servers seem to be dropping approximately 40% of packets not coming from v7 clients. Currently the only v7 clients are Mirabilis' own clients. This isn't a new thing, they've dropped packets for some time but they are getting more aggressive.
You can also use GAIM (or any AIM client) to access the ICQ network, using the AIM protocol over a TCP connection. Enter your ICQ number as your screen name, and use your ICQ password.
That works well in theory but libfaim does not support offline messages, nor does it support client modes (away, NA, etc.). I'm using the AIM Transport via jabber right now to keep in contact with my ICQ contacts but it's a temporary measure.
Hmm ... that is strange, I log into ICQ daily with Licq (v1.03) . Only problem I've seen recently, is that it doesn't erase messages that got sent to you while you are offline ... so you keep receiving them until you log in with an official client
Heh, I've never had that problem. LICQ works fine so long as you're sending direct; if you have to send through the server LICQ has about a 40-60% chance of getting the message across. I've spoken to several people using LICQ (v1.03 yes) and that is the general consensus.
So, I've jumped off the proprietary IM bandwagon. Fuck 'em. I actually helped Sefi and Ari with some early early ICQ problems but ever since joining up with AOL it's been a downhill slide.
I was forced out of ICQ since their servers now drop packets not coming from v7 clients and LICQ is definately not v7; hell I don't even think it's being developed anymore.
AOL is blocking non-proprietary clients and the others out there are too small to worry about... I've switched to Jabber (using the Psi client).
Why Jabber? Interoperability. I can connect to a dozen other IMs as necessary. Right now I'm "cheating" ICQ by using the AIM transport which seems to work alright. But the biggest reason I like Jabber is that I also have the server source, and have my own Jabber server for my company.
Sure there are only 2 people on it right now but that's the point -- It's totally decentralized. I can get a hold of any other jabber client by searching THEIR server. You don't need to be on the same server to communicate. Very cool.
Jabber has a few interesting transports too like IRC and email. If it doesn't have what you want, write it, as the spec is open and will stay that way.
I was avoiding Jabber for a long time for several reasons: the clients were all GTK or Java or BUTT UGLY, they were big big big, and petty much all the clients popped up new messages. That's a royal pain in the ass when you actually use your computer. Psi has the option to just raise the window but it took focus too. I helped hack Psi so that its "Raise window" didn't take focus which is exactly what the old ICQ and LICQ did. Perfect. I can type away at 100WPM and if a message comes in I don't end up spilling half the paragraph into the IM window. I can shrink it small like ICQ/LICQ. The Psi developer promises to try and add in global-key support so I can map alt-backspace to pull up the next message. That's all I need in an IM.
That's my solution for closed-source proprietary bullshit IM protocols: route around them. Jabber is a great way to do so becuase it's decentralized and totally open.
I think that's ethically crap, but hey.
Why, I'm paying about 10x what you are, specifically FOR top priority service over consumer-class. There's nothing ethically wrong about it, as you pay for the service you expect.
This isn't really true. When you do a voice T1, this is true, but when doing data, you'll normally only lose 8kbit/sec to overhead (using ESF/B8ZS)... So rather than 1.544Mbit/s, you get 1.536Mbit/s.
Close, but not quite right.
A DS1 (T1 without the electrical specification) is 193 bits sent 8000 times per second. One of these bits is reserved for framing; i.e. you can't touch it. That leaves 192 bits sent 8000 times per second. Calculate that out and you get your "raw" speed of 1.536Mbps.
B8ZS came from AMI. AMI is used on voice circuits only -- it has no provision for excaping long strings of zeroes and in the voice-only days it didn't matter. It was statistically next to impossible to keep an 8-bit PCM coded line at 00000000 for any length of time. However when data circuits started popping up they needed a way to keep clock sync for long strings of zeroes.
B8ZS is a method to encode long strings of zeroes (8 to be exact) -- Like AMI, 1's are sent as an alternating stream of +1 and -1 to keep the net DC voltage of the link at 0V. Every '1' bit allows the clock recovery circuitry to sync up to keep the bit detection centered in the middle of every bit. '0's, however, are the absence of a pulse. Long strings of 0's cause the clock recovery circuitry to start falling out of sync. B8ZS sends eight zeros as a specially coded binary string: for example +1 +1 0 0 -1 -1 0 0 +1 +1. I made that up; I don't believe that is the actual pattern but what is important to note is that instead of the 1's being alternating in polarity, they are the same polarity. This is known as a BiPolar Violation (BPV). Normally the recovery circuitry sees this as an error but if it sees a particular pattern, it instead spits out eight 0's. Because it's a BPV, there is no need to use any kind of escape code so that you can tell the difference between eight 0's and whatever code they use to represent it.
That leaves framing. Remember that 1 frame bit at the end of each 192 bit sequence? In olden times that frame bit was always a '1' and was used to help keep the endpoints in sync. Since newer equipment is very good at keeping frame sync, that bit is used as an 8kHz channel between the two DS1 endpoints and can send out of band (OOB) singal information between them. Things like putting remote ends into loopback, status information, etc.
The telco grouped 12 frames together and called them a Super Frame (SF, and yes I do think of wrestling every time I go over this). Later on they decided to group 24 frames together and call them an Extended Super Frame (ESF). Why the grouping? Robbed Bits.
Robbed Bit Signalling is a way for the telco to indicate the line status. On hook, off hook, busy, ring(back). Your telephone conversation is sampled at 8bit/8kHz and then trunked into a DS0 on the DS1. There are 24 DS0s in a DS1. 8*24 is 192, plus the frame bit is 193. Now to indicate line status over the trunk, the telco created SF and uses that group of 12 frames to steal the LSB of every DS0 on the 0th and 6th frames of the SF to give them A and B signalling bits. Two bits gives you 4 line states. Later on, they wanted room for expansion, so ESF came along and the DS0 LSBs are stolen on the 0th, 6th, 12th and 18th frames of the ESF. Traditionally those C and D bits are just a copy of the A and B bits, but this isn't guaranteed.
ISDN doesn't use robbed bit signalling; they take 23 DS0s for data (as 23 8-bit channels) and then take the 24th DS0 for signal information. Since a DS0 is 64kbps, there's a lot of waste if you just use a D channel for a B channel (or even for 23 B channels) -- that's where NFAS (Non-Facility Associated Signalling IIRC) comes into play: You can gang up to 8 PRIs to share one D channel. So you lose 1 BRI on the DS1 with the D channel, but the other PRIs have 24 D channels. We use that to max out the number of dialup lines we can provide per NAS. Of course, the problem with doing NFAS is that if you lose your D channel, you lose up to 7*24+23 voice/data circuits as well. Most NFAS installations have a backup D channel as well.
So, after that long-winded explanation: You lose no data due to the overhead of ESF/B8ZS. You lose your frame bit which drops you to 1.536Mbps instead of 1.544Mbps, which is the raw speed of a DS1. You don't even lose out if you use a channelized T1 over a nonchannelized one. You *do* lose out on the full capacity of a DS1 if you have it provisioned for PRI instead of DEA (DEA is a Canadian term, I forget what the U.S. term is), since you lose a DS0 to signalling (and with NFAS that problem becomes smaller, but you still lose out on your "theoretical maximum"). And if you're a voice user (this includes analog modems), you lose a bit every 6 frames but since you don't know when the telco is going to steal that LSB, you essentialy have a 56k line. v.90/v.92 modems actually do try and determine when the telco robs the bits when they trainup but that still doesn't push you closer to 64k.
It gets a bit messier when you bring DS1s together into DS2s and DS3s, because there are "slop" bits which are used to overcome the problem with all these DS1s coming in out of sync from each other.
So, if you're upgrading, you really ought to reinstall no matter what OS you're running.
What are you smoking? Even cheap crack won't give you that kind of buzz...
When you first boot up, you're right -- you won't get all the nifty new features. However you do not need to <cough> reinstall -- just recompile the kernel and any key apps you run. You will not see a performance increase on your P4 by recompiling everything. Hell 99% of the time the compiler is generating i386 or i486-optimized code!
Not even on Windows do you get much added benefit by reinstalling -- the drivers are i386, the applications are i386, everything is compiled for the lowest common denominator. The higher-end drivers will be optimized for P5 or P6, but that's about it unless you have some really specialized hardware or tweaked drivers for multimedia codecs.
Windows blows chunks for doing major hardware upgrades because the OS becomes confused when you change "too much" at once. It blows chunks because most of the configuration is stored in a proprietary binary format. It blows chunks because its only partially able to come down to a textmode level so you can clean up. NT is better at this than Win95/98/ME, but it's still not close to the flexibility you have with Linux/FreeBSD. One of my most favourite things is how you can pull a HDD out of pretty much any i386 platform and snap it into another one and boot up. If you compile in a ton of network drivers as modules, you can damn near get net access on any computer with that same drive. Try that with Windows.
Here is a hint to use patches
That's an okay hint, but why not try this? I've been doing it since the early 2.2 kernels:
From there, I copy arch/i386/boot/bzImage
I find this is the cleanest and fastest way to patch a kernel. The patch-kernel script will stop if it runs into trouble and you can try to fix it. Be sure to remove any .rej and .orig files before rerunning the patch-kernel script or it will think there's still trouble.
the reason I can't reference a program right now is that I burned some of this noise onto a CD years ago and have been using it as needed ever since.
I, and I'm sure others here, would love more information on this. Perhaps even a link to the .wav of this magical CD for others to mirror... I'm assuming that mp3'ing it would just destroy the charasteristics.
I've never heard of this before but hell, I'm willing to give it a shot. :-)
It would be interesting to see some stats about how many /.er's have the toolbar on after 'x' days
I intend on keeping it there... not that I have ever gone to anything OSDN other than slashdot and k5 (which is not technically OSDN but....) Seriously though, that bar bugs you that much? Jesus, you must be one anal mofo.
You run an extremely powerful fancy GUI on a Pentium 4 1ghz on an IDE slow harddrive?!?!?!?!?!
If the damned program chews up enough memory that it has to eat into swap on any of my systems, it's out the window.
In fact, on the laptop I'm typing this on right now, I have turned off the swap drive. My desktop needs should never need more than 256M of memory, ever.
Yes I understand disk access can be slow but that's what the linux cache is all about. I don't have any trouble with Konqueror, Opera or even that pig of an OS...er...browser, Mozilla. If Nautilus hits the drive more than Moz, it's broken, and no amount of you bitching about my IDE drive is going to speed it up.
We recently had a new house built. During the construction locks were install that have a pin that enables the builder to use a common key for all the locks in all the houses he was working on.
I knew there were such things as skeleton keys and so on, but I did not know that they were so prevalent! Thanks for this little tidbit of info, we're planning on having a house built soon.
I would relate M$ to the builder, and the locksmith to the security boards.
As would I. I don't moderate but your post deserves a +5. Very informative and insightful. Thanks!
Come on, if you're going to flame me, at least make sense. I replied to a post about PHP, gave some PHP code examples as to why PHP is bad, and you've come back with that Perl users' mainstay: use strict;
I did read your post; I noticed that you had one reference to PHP in there, and I also took into account the subject line and came to the conclusion that you were knocking both Perl and PHP, as Perl has some of the same problems (creating variables out of thin air and silent conversion between incompatible types mainly) as PHP. It was a thought-out flame. Honest.
My personal favorite bit is the way you can suddenly create a new instance variable on a whim, just by assigning a value to $this->varName, halfway down a random function.
This, and I would think to say that all your piss-poor examples of why Perl is bad are cured with one statement:
Stop spreading FUD. I've seen and worked with many large, OO and non-OO Perl scripts which are a joy to maintain. You can get bad code in any language. Perl lets you shoot yourself in the foot if you want to. My personal preference is not to hire these types of programmers instead of complaining that the language is too flexible.
"If someone breaks into your house because you had a lock that could be bypassed with a special lockpick, it's not the lockmaker's fault, but the fault of whoever it was that gave you the special lockpick"
I disagree.
When I buy a lock, I expect it to be secure, and I expect that the manufacturer has tested the lock against most common circumvention methods. I would be damned pissed off if my lock were openable by using any old key blank.
Similarly, when I buy server software, I expect it to hold up against point-blank buffer overflows and backdoors/side effects so large you could drive a truck through. I mean jesus, I can get free software where the authors have spent more time making sure that stupid shit doesn't get through. Some code monkey getting paid $x/hr should at least have a monetary incentive to check over the code, shouldn't they??
Or let's take a look from a different angle. I pay money for software. If it costs me money and time when it falls down, I expect to be able to get money out of the manufacturer or at least get timely fixes or decent technical support. What am I paying them for anyway?
... about three weeks ago.
I believe they said there's a 6-8 week wait, so I am not too worried... yet.
nfortunately, it doesn't look like they have much on the 5250/5251 series (which appears to only be able to support a VCI/VPI of 0/38 which won't work with a lot of telcos anyway).
I'm not trying to use it with a telco; strictly back-to-back. They're SDSL bridges and, barring anything dumb in the firmware, should be able to work this way if I can get one of them to provide clocking. :-) I know there are other modems on the market but these seem to be damn cheap and plentiful, moreso than the 5800s and so on.
(BTW: I figured out how to change the ATM configuration so even that's not an issue anymore.)
All the ones I've mentioned above, when set to factory defaults, can be telnetted to if you set your computer to 192.168.254.1 (/24) and telnet to 192.168.254.254.
Do any of those mentioned have weird-ass configuration utilities or do they ask that the configurations be done via the telnet interface?
I tried a few variations of this but I have not been able to obtain a response from the modem, nor have I seen any documentation on using the telnet interface from any of my searches. I do, however see tons of info on the telnet interface for the other dsl modems you mention. I am fairly (95%) certain that this is not supported on the 5250 but will see what I can find.
Do you know of any other IP pairings commonly used by Efficient Network's products?
On the Efficient 5800 series units I've worked with you can connect a 9pin serial->RJ45 cord from the serial connection on your computer to the blank port on the back of the unit (it's the management port, it just isn't labelled) and then connect with minicom/hyperterm.
That's the first thing I tried too. :-) Unfortunately there are no serial ports, RS232 nor TTL level. (I spent an hour or so with a scope on every suspicious looking land pattern, constantly resetting the modem and looking for a datastream that smelled like async serial. No luck so far. :-(
Not sure if it will help - you may have already seen it (watch, it will be your site):
Not my site, but I already did find this in my previous searches. Same with snurgle.org; that guy hasn't found it either. I'm hoping I'll succeed since I've at least attempted to invoke the Slashdot Effect. :-)
I appreciate the try though, this app has got to be somewhere.
The beauty of open-source is that anyone can create advanced configuration tools like the one you describe without the technical and moral restrictions of proprietary and closed software!
While your post sounds about as sarcastic as one can muster without sounding like a total ass, that is exactly what I'm working on; however I can't rewrite the utility until I can get the packet format down, and that's what I need the Win32 utility for!
here is an excerpt from my notes so far. I have documented the flashing process about as well as I can manage, but I don't know if the format is much different for the configuration utility or not.
Most of the SpeedStream models can be configured with a telnet-based interface.
The 5250/1 don't have this. They don't have an IP, as they are bridges, not firewalls or routers.
I have the flash upgrade utility and, after cracking open my TCP/IP refrence and combing through 802.3 SNAP frame bitmaps, the flash utility (and I am guessing the configuration utility as well) use specific ethernet frames toc ommunicate with the processor on the SpeedStream 5250.
Here is some more info from my notes:
The PC with the flashing program sends out a raw frame:
0000: ff ff ff ff ff ff 00 50 04 66 a4 02 00 46
broadcast from 00:50:04:66:a4:02, len 0x0046
000e: aa aa 03
0011: 00 20 ea 00 01
I know it's a SNAP frame because 0xaa 0xaa 0x03 is the signature for the SNAP header.
Now the OUI is normally 0x000000 but here it is 0x0020ea. That is the first half of the MAC for both of these SDSL bridges, and I am willing to bet that all 5250s have this as the start of their MAC address.
The last part of the SNAP header is the type: 0x0001.
0016: 00 00 41 48 00 02 00 00 00 01
0020: 0e 01 00 01 00 00 00 3c 00 00 00 00 00 00 00 00
0030: 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00
0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0050: 00 00 00 01
The length of 0x0046 takes the data from 0x0e through to 0x53.
The flashing computer keeps sending this until it gets a response.
Anyway as you can see I've been buggering around with this for a while. I've documented the flashing procedure as best I can but it's obvious that this isn't as simple as telnetting to an IP. These devices use special ethernet frames to communicate and pass everything else, just like a good little bridge should
I find the people here slamming MySQL are often doing so based on their theoretical, rather than practical knowledge. But perhaps you are different. I'd like to see you back up your claim.
Here is a recent (MySQL 3.23.26beta and PGSQL 7.1 CVS pre-beta) benchmark. Now I know that benchmarks are the devil's tools, but he really seemed to try and make it a balanced, true-type of benchmark. It is interesting to look at his 1999 benchmark between the two too, where MySQL appeared faster on simple selects and non -concurrent writes to tables. I forget (and don't see it mentioned) if Tim Purdue actually turned off the fsync action that Postgres leaves on by default. If not, it could have explained some of the slowness of Postgres at that time.
My personal experience with older MySQL is that it is unstable and buggy. We used it for our RADIUS backend for about 3 years and it fell over regularly without much effort. About 18 months ago I replaced it with GNU-RADIUSd and Postgres and -- with four times the load -- it has yet to fail. This wasn't super-high-end stuff either. We're talking about 300 dialup lines with a couple RADIUS daemons making SQL calls to update user logins and time spent when logged out. With MySQL it was 48 lines and a single daemon and I was restarting MySQL so much I wrote a script to do it for me (about five times a week or so).
I am glad to hear that MySQL works for you; chacon son gout, as the French say (when they don't have accents handy). However based on my experience and the experiences of those who at least appear to be doing unbiased benchmarking, and also based on my need for referential integrity, ACID compliance and robustness, MySQL loses. Hell even those using it for pure speed are losing too, since it isn't the fastest, despite what MySQL, Inc. claims.
*cough cough* slashdot
You're giving /. as an example of a rock-solid stable system? I surely hope you're kidding. /. Has fallen up and down more times than I care to remember.
IIRC, /. heavily caches both stories and the front page to avoid load on the MySQL server. Before this was done the crashes were a lot more visible. Now, you just don't see new comments until the cache is refreshed. This is both a good and a bad thing, but it does not show that MySQL works well under load.
/. Also shows its MySQL troubles when you try to log in or change your viewing prefs; if the SQL server is down, you get the threaded (ick) cached page instead of what you want.
here is a phpbuilder test that helps back up my claims.Sometimes speed is everything...
Which MySQL hasn't got, no matter how you look at it.
Postgres has shown time and time again that it blows the shit out of MySQL for any kind of select statement where your 'where' clause is even just slightly more complicated than 'x = y'. Even for simple selects, Postgres performance scales waaaaay better than MySQL. We're not talking hundreds of clients, either; we're talking dozens. MySQL falls flat on its face under heavy load.
And if your application just requires the simplest of simple selects, a hashed flat file is faster than MySQL because you don't actually have to parse up the SQL statement and return the result in a formatted fashion!
Face it: MySQL is a neat toy but that's about it. All this pandering about what 4.0's got now and how they think it's mission-critical-ready is bullshit, plain and simple. We've got an open-source, free ACID-compliant database already. MySQL has lost, they just don't know it yet.
The problem with this system is that you end up trusting everyone in the city to supply your internet access.
Actually it's not so bad at all. You lease out a part of their basement and build a room (or just use a wire cage or enclosure) and lock the damn thing. Pay a little up ahead and get a separate disconnect and of course run a UPS on the power feed. The idea is to be independent other than the physical quarters.