That a new expansion of B8ZS by me, I've seen Bipolar, with 8-Zero Substitution from the telcos
THAT'S IT... I knew it didn't sound right but I couldn't make any other words work. And I was pretty sure that AMI and B8ZS were competing formats but I couldn't work that out with my expansion of B8ZS.:-) Thank you for clearing it up!
You can get a T3, and it carries a DS3.
That's news to me... I thought DS3s were always carried over something optical because there'd be too much trouble doing 45mbit over copper for any kind of distance and with any kind of reliability.
Technically modems don't modulate either; nowadays they encode and decode. The DSP just selects the correct output sequence to hit the right phase and amplitude of the sinewave from a trellis pattern stored in ROM. Decode just watches the line and converts the precieved amplitude and phase back into a bit sequence.
I don't think I've seen a real modem since the old 2400 baud jobs.
With a DSL line, the connection between you, and your service provider, is a constant, flat rate. No matter what your neighbors do, you never slow down. Theoretically. There is a potential bottleneck tho, your service provider, has to have a big enough pipe from their office, to the internet to support all the users. But since most of the time it's a phone company, they can certainly afford the pipe(s) out to the net.
Unfortunately most (all?) providers overcommit. The level of overcommit is actually able to go up with the more customers they get because the whole thing shares really well if people are just browsing. Overcommits on dialup-class service can easily hit 100:1 on bandwidth and 7:1 on lines. It works just fine as long as you don't have a two-digit percentage of the people you're overcommitting doing some kind of long high-bandwidth transfer.
I'm not sure what the numbers are like for DSL/Cable but they can't be much better.. That's a wad of bandwidth they're giving each person and DS3s are neither cheap nor enough to service a lot of 1-meg customers doing fulltime downloads.
DSL connections do not work between COs for the simple reason that there is no unloaded copper between COs. Most COs are hooked together via frame clouds/ATM/SONET/what have you. Once the individual pairs hit a CO it's concentrated into your carrier lines: DS1-3 and piped either via a single copper/fiber/RF channel (usually copper but the new ones are all fiber I believe).
24 phone lines can be carried in a single T1 line. That's were you get your 56k from. The DS1 spec is (simple form): 193 bits per frame, 1 for frame sync, the other 192 for 24 8-bit channels. 8000 frames per second gives you 8000*193 or 1544000 bits/sec, with 1536000 bits/sec actual useable data.
Now about those 24 8-bit channels. They need to be encoded because you want to maintain a net 0 voltage on the line. so too many 1s or too many 0's gets you into trouble, not to mention confuses the clock recovery circuitry. Enter AMI. Alternate Mark Inversion just reversed the polarity of a '1' every other time it occurred. This still didn't solve the problem of too many 0s though, but with the 8kHz PCM modulated voice data it wasn't a problem because any kind of little noise would send an LSB to the '1' state and keep the clock recovery happy.
(I'm a little hazy here, and I can't look up my old/. comment (about 6 months ago) that described this in eerily gory details, if someone can tell me how to search OLD OLD COMMENTS (not just stories) email me PLEASE!) Somewhere in the past B8ZS (Bit 8 Zero Set) came along and, with AMI, cleaned up everything. Basically if too many zeros were sent a '1' was injected with the same polarity as the last '1'. The clock recovery circuitry didn't care, but the data recovery circuit would notice that the mark had the same polarity and change it to a zero to keep everything 'right'.
Anyway. To be able to put 24 phone conversations and have them all be kept track of properly, the telcos decided to band 12 of these frames together (12 frames, each with 24 channels) and use the LSB of each conversation for switching information. I believe it was the 6th and 12th frames of the Super Frame (SF) which carried this info, call them bit A and B.
Bit A and B were the line status bits. They told the telco equipment whether each line was on-hook, off-hook, busy or ringing. Now with 8kHz PCM conversations going on, losing a bit 1/6 of the time meant nothing important and it was hardly missed. For data conversations though that reduced your 24 64k channels to 24 56k channels since the end modems have no idea when that bit will be lost. There's your limit to analog modems. ISDN gives you a 64k channel because the equipment doesn't screw with the data frames every 6th frame.
Anyway the SF format was put away and the ExtendedSupaFormat (ESF) method was brought in. All it is is instead of using 12 193-bit frames, it uses 24 and continues the "I need the LSB of every channel every 6th frame" to give the telco 4 line status bits, A, B, C and D. The other two bits aren't used yet but it's for future expansion. They typically just mirror the A and B bits for now.
T1 is actually both a Layer 1 and a Layer 2 spec. It originated from the old Bellcore D1 spec in the 60s and details both the actual line voltages and the framing of data to get to those line voltages. There are no such things as T2s and T3s, only DS2s and DS3s.
quick summary:
DS0 - 64k channel
DS1 - (T1 data spec) - 24 DS0s with framing
DS2 - 4 DS1s with framing and filling
DS3 - 7 DS2s with framing and filling
Now the DS2 framing gets REALLY weird because the DS1 lines feeding them are not likely to be in sync so there are variable fill rates and such to maintain an intermediate bit rate which isn't really standardized... it sits between 1.544mbps and 1.56mbps I believe and is tuned at each installation since the DS1s feeding the DS2s are more or less unique. Simiarly, the DS2s feeding the DS3 aren't necessarily in sync the DS3 too has an intermediate rate.
Anyway the whole point of this post is to show that once you hit a CO you are no longer on your own copper pair. You are part of the collective. You are just a 64k channel (with an involuntary loss of 1 bit, thus dropping you to a 56k channel) in a sea of millions and millions of bits. And the fact that it all works pretty much flawlessly is a tribute to the Bellcore engineers.
Actually most T1s these days are just HDSL to the telco, then (usually) on a frame cloud. Parigain/Adtran units are on the wall and provide a DSX-1 port to your DSU/CSU. The line quality can actually be quite a bit shittier for an HDSL connection than a HDSL2 connection, since you're distributing the "load" over two pair instead of one. Go read up on it at Adtran's site. They have great documentation.
How do I know? I'm the technical admin for a small (500 customer) ISP.
Back in the early '90s I made a pair of programs which did exactly this. (I was way into virus research back then and made a little bit of a living in my early teens doing just this) All it did was scan the drive from sector 1 looking for a partition signature, analysed it and jumped to where it indicated a boot sector was and if it existed, wrote it in to the MBR. Made a partition resizer too. Also played a lot with DOS MCBs and managed ot make a permanent LoadHigh program by altering the last MCB in the chain.
I never thought much of these programs until years later when Partition Magic came out and I realized I'd yet again screwed myself out of a cool idea. Other ideas? Hooking a modem up to the original NES (I think I still have drawings for this), 2-way paging, etc.
How do you reconcile these two statements: Not to sound like a prick, but it sounds like user error to me. and In response: Don't run Linux on "weird" or shitty hardware.?
Easy.
He was talking about not being able to get a bootdisk to work except floppy install. I said that in all cases except for bad/misconfigured/misdetected hardware the CD-ROM drivers work, so it must be user error.
The "Don't run Linux on shitty or 'weird' hardware" comes from his statement that Windows was working on all the boxes before he got to 'em. Linux does push the hardware more, so hardware which is on the edge (the "shitty" part of that statement) tends to break or act funny. The fact that Linux doesn't have support for every weird IDE controller or video card on the planet gives rise to the "weird" part of the statement. Linux runs most hardware out there, with the exception of the bleeding edge or the truly funky. And even in the latter case it seems to support the odd device.
I find no trouble reconciling those two statements.
Yes, I think you are a prick. The fact that you call the guy inept for not being able to install Linux on hardware that you say it won't run on anyway proves it.
You can think what you like; that is your perogative. I perhaps did not explain thoroughly enough, but as you can (hopefully) now see my statements are not in conflict with each other.
Finally, I did not call him inept. I questioned his use of weird and/or shitty hardware to base his decisions on the usability/installability of Linux. I suggest a simpler course for him, as in his own words he was no Linux guru. If that makes me a prick in your eyes, so be it.
Well, I've had a miserable time trying to get as far as a GUI. I sometimes don't even succeed in getting a boot disk to run; so far, most CD-ROM drives/drivers seem not to work, for one reason or another, so I can't do better than Debian's 7-floppy Base (Bless Debian...) in general. All that wonderful SuSE stuff... S.O.L...
Not to sound like a prick, but it sounds like user error to me. I've installed Linux on close to probably 75 or 80 machines now, from pokey (my original 80386DX/33 with Weitek copro and 8MB expansion board) to numbskull, my dual Cel466 BP6 server. From shittly little dial-on-demand computers that sit in the corner and collect dust (and dial:-) to full GUI systems for small offices. I have never had problems getting a boot disk to work. Not on IDE or even RLL (XT-style) hard drives. Actually no that's not true. I hate floppy disks and floppy drives. They are the bane of my existence.:-) Network boot? No problem.
CD-ROM troubles are almost exclusively user error, from either selecting the wrong IO/IRQ to even using the wrong driver. The older CD-ROMs can be tricky, yes, but they always work when tickled the right way.
Now on to X and GUI.
X works tickety-boo if you start out with the VGA16 driver and move on up to the SVGA or one of the specific accelerated drivers. Most problems with X occur becuase the installer is trying to either push the hardware or thinks the hardware can do something it can't.
One machine (NEC) had 990K (or 956K) of video RAM, and apparently X Win didn't like that.
Did you turn off accelleration or try the VGA16 driver first? Not to sound fecetious here, but always start from ground zero and work up if you run into trouble. Don't try to downgrade from a system that should work, rip out the config file and start from ground zero. Sometimes it's just a matter of an accelerated driver not being avaiable and you being stuck with a slow X. Other times it's the driver is buggy. You run into both these problems on Windows systems, albeit less often in my experience.
However, every single one of them was running Win 95 when the customers turned them in.
In response: Don't run Linux on "weird" or shitty hardware. Windows has a track record of supporting weird installations or flaky hardware. Linux tends to push the hardware a little harder and as such it breaks. So don't put it on weird/flaky stuff if you can help it or if you don't want to try and expand its list of compatible hardware. Especially if you're trying to impress someone. Would you load up Win2k on a 486DX4/120 with 24MB RAM to show it off for a SOHO type situation?
No, I haven't asked for help, because these attempts at installation are quite the opposite of "mission-critical", and I don't want to waste the energy and good will of someone for a relatively-trivial cause. Maybe worse, I have not kept notes, so I have only mental recollections of the problems I've encountered.
Being, as you said, not real experienced with Linux, why are you trying to see how easy it is to install on weird hardware? I've found the only real way to learn it so you can install it in unusual installations is to ask. Especially with legacy CD-ROMs and X. X is a bitch sometimes, but it does seem to be a loyal one.:-)
Believe me, my intent in this message is not to put down Linux; it's only to point out problems I've had.
I didn't take it as a put-down, but I am more or less replying to keep perspective. You will have all these same problems getting the original Windows 95 OS on them to work from a fresh install if the drivers aren't there or are buggy. How many times has someone brought a machine into the shop and said "It was working" and the only way to get it back was a fresh install? My brother owns a computer shop and I do the insanely weird technical stuff for a different small ISP/computer store. Driver problems and "weird shit" are abundant in Win9x.
I'm not exactly a newbie; was a midnight hacker in 1960, but was isolated from computers until ~1982, so I'm not really all that experienced.
I'm glad you are tinkering around with the systems that are brought in, but my advice would be to get a standard (modern) system with IDE CD-ROM and normal (read: well-supported) video and network card working before trying to get the weird stuff to work.
That being said, I kind of miss the old days of jumered motherboards, MFM/RLL controllers and obscene BIOS gestures. That old 386 I mentioned up above was one of the orignal 80386DX motherboards (before there was a 386SX) and it implements the cache control as discrete logic on its full-size motherboard. I kinda miss all that because nowadays the hardware is mostly toss-away if it breaks. The generations of hackers to come will be mostly software and programmable logic. The era of security-bits and write-only memory techniques hinder all these fresh young minds. *sniff*
Yup. I've got one. Hardware is an 80186-based system (more embedded computer) with some kind of weird-ass token ring network. I contacted QNX for information about these systems, as I have done with Unisys but neither was able to help. Is there anyone here with hardware information on those old Unisys ICON computers? I have a few I'd like to play with...
One of the problems with using the cellular phone service contract has to do with the use of the phone itself. If you try to weasel your way out of the contract, they can always shut off the phone service, and usually do. And a cell phone that won't send or recieve phone calls is essentially an expensive plastic paperweight.
To the average user, perhaps. The Netpliance is the exact same to the average user.
If I fail to agree to the ToS of the cellphone contract, they take my phone or bill me for the amount left owing. If they didn't, I could just take the phone to another area and get service with someone else. Netpliance tried to get around this by locking the dialup account to one account. They figured "Nobody will not get service, because it'll just be an expensive plastic paperweight without the service."
They didn't lock you down for a term, like all cellphone contracts with outrageously low prices for the unit. Their mistake, my gain.
Do you not think they'd do the same if the tables were reversed? I do. I'm fighting UUNet over something similar right now.
This is the cellular phone model: if you don't pay for your service contract, Netpliance will chase you in the courts, and you will lose.
INCORRECT
With the cellular contracts you SIGN a piece of paper saying you agree to pay according to the terms set out on the paper. When I ordered my iopener from Netpliance's web site there were no terms of service and no minimum contract. Netpliance's oversight does not give them the right to make me pay for something I did not agree to. I did agree to $99 for the box plus $40 for shipping. NOTHING MORE
Your cellular model fails because there was no contract, no "I agree" button, nadda.
If they try to get another $21 from me, they will not get it. They have no right to it.
fix your posting. It's not like you haven't known about this for ages. Not very subtle for a troll/flamebait but to risk getting moderated into Offtopic-ness: you don't correct a problem by ignoring it. Bugs are supposed to be fixed, not avoided.
Post-accident tests have shown that when the legs are initially unfolded during the final descent, springs push them so hard that they "bounce" and trigger the microswitches by accident. As a result, the computer receives what it believes are indications of a successful touchdown, and it shuts off the engines.
As an embedded systems designer I find this hard to believe. All mechanical switches bounce. That is a different kind of bounce, however. I imagine this "spring bounce" could be just as easily detected and ignored through reprogramming the system in-flight, just as they twiddled with the Mars Explorer firmware. A simple "if close time
I agree with an earlier poster that if you don't want the ability for people to do it remotely, don't put it in there in the first place. This can't be done in all circumstances, of course, but read on.
I hope to God that the arming circuitry requires some kind of hardwire interface at least for the last stage of final go-ahead for launch.
I would have though that with military tech. being, what, 5 years or more in advance of what we civilians get they would be using multiple signal, spread spectrum, 2GB encryption keys and a slew of other technologies that make it at least infeasable to try and crack. And yes I do mean for navigation and indeed all subsystems of any kind of military device or even civillian device which has the possibility for far-reaching or deadly effects if such a system were to be compromised.
<sigh> I guess that's what they mean by "military intelligence".
What exactly is "GPU TBA" 3D accelleration? Graphics Processing Unit - To Be Announced?
It sounds neat (the box, not the accellerator) -- the 4 USB ports sounds like they want to hook up the controllers that way (Gravis has a neat gamepad or three) which is a very wise move IMO. I wonder if they will support regular cable and DSL modems through the network connection as well. Does anyone have more info on "DV linux"?
I mean this is a good thing. The questions asked will be on how to apply the knowledge, not the knowledge of the knowlege itself. That in itself is invaluable. I wish high schools worked that way but many are still stuck on the "To get the answer right, you must do it exactly how we taught. If you skip steps or do it another (valid) way, you will fail."
The part about requiring a laptop and wireless access is kind of stupid if you ask me. Why laptops? What's wrong with using the lab computers? Making each student procure a laptop is a little silly and tends to weed out the poor from the rich kids.
As far as the infrared sharing goes, You could bathe the room in randomly modulated infrared light. Or simpler, just get some bright orange electrical tape and cover the infrared port. Think of it though. All these guys are connected to the 'net. What's so hard about firing up an ICQ ActiveList or IRC or even plain email?
I believe they have ships that regularly pull up the cable and replace the batteries in the repeaters
Incorrect. The cable that gets put into the ocean is a very complex cable. At the heart is the fiber, but there is also high voltage running down the wire which the repeaters use to power themselves. Throw on a bunch more cladding, some more reinforcing steel, antother couple thousand volts, more cladding, more steel, armour and a rubber outer shell and I think you're done.
And you thought that Gobstoppers were layered!:-)
I also am pretty sure that the cable rests at the bottom of the ocean, quite some way for a ship to be pulling it up.
They also have problems with sharks attacking the repeaters because they have a slight electro-magnetic field that sharks can detect.
I haven't heard of this but wouldn't really worry too much about it.
... with the author's desire to completely circumvent the administrator's control over their own network. There are technolgies in this software to specifically prevent it from being throttled.
Yes I'm all for free speech and the freedom of information but at what cost? I can see the entire QoS of dorms and "open" labs to be turned way way way down over this. It would have been much better to have some kind of control app which the network admins could say "300kbps tops during peak times" or something to that effect.
Mind you I can now also see work being put into firewall software which monitors for large bandwidth useage on an connection basis and, if it exceeds xkbps for y seconds, throttle that IP down or turn them off completely.
It doesn't mention a minimium period, but I'm sure there is one.
I bought one and there was no mention anywhere about a minimum length of contract, so they're screwed. I didn't sign anything / click on anything that said I agreed to anything whatsoever so I guess it's tough titty for them!
Buy the 3 months service for $65, and you have to pay more for the machine itself.
How do you figure? $99 machine, $65 for 3 months service. $65
Slashdot Mirror
That a new expansion of B8ZS by me, I've seen Bipolar, with 8-Zero Substitution from the telcos
THAT'S IT... I knew it didn't sound right but I couldn't make any other words work. And I was pretty sure that AMI and B8ZS were competing formats but I couldn't work that out with my expansion of B8ZS. :-) Thank you for clearing it up!
You can get a T3, and it carries a DS3.
That's news to me... I thought DS3s were always carried over something optical because there'd be too much trouble doing 45mbit over copper for any kind of distance and with any kind of reliability.
Sorry, just being a shit:
Technically modems don't modulate either; nowadays they encode and decode. The DSP just selects the correct output sequence to hit the right phase and amplitude of the sinewave from a trellis pattern stored in ROM. Decode just watches the line and converts the precieved amplitude and phase back into a bit sequence.
I don't think I've seen a real modem since the old 2400 baud jobs.
Unfortunately most (all?) providers overcommit. The level of overcommit is actually able to go up with the more customers they get because the whole thing shares really well if people are just browsing. Overcommits on dialup-class service can easily hit 100:1 on bandwidth and 7:1 on lines. It works just fine as long as you don't have a two-digit percentage of the people you're overcommitting doing some kind of long high-bandwidth transfer.
I'm not sure what the numbers are like for DSL/Cable but they can't be much better.. That's a wad of bandwidth they're giving each person and DS3s are neither cheap nor enough to service a lot of 1-meg customers doing fulltime downloads.
DSL connections do not work between COs for the simple reason that there is no unloaded copper between COs. Most COs are hooked together via frame clouds/ATM/SONET/what have you. Once the individual pairs hit a CO it's concentrated into your carrier lines: DS1-3 and piped either via a single copper/fiber/RF channel (usually copper but the new ones are all fiber I believe).
24 phone lines can be carried in a single T1 line. That's were you get your 56k from. The DS1 spec is (simple form): 193 bits per frame, 1 for frame sync, the other 192 for 24 8-bit channels. 8000 frames per second gives you 8000*193 or 1544000 bits/sec, with 1536000 bits/sec actual useable data.
Now about those 24 8-bit channels. They need to be encoded because you want to maintain a net 0 voltage on the line. so too many 1s or too many 0's gets you into trouble, not to mention confuses the clock recovery circuitry. Enter AMI. Alternate Mark Inversion just reversed the polarity of a '1' every other time it occurred. This still didn't solve the problem of too many 0s though, but with the 8kHz PCM modulated voice data it wasn't a problem because any kind of little noise would send an LSB to the '1' state and keep the clock recovery happy.
(I'm a little hazy here, and I can't look up my old /. comment (about 6 months ago) that described this in eerily gory details, if someone can tell me how to search OLD OLD COMMENTS (not just stories) email me PLEASE!) Somewhere in the past B8ZS (Bit 8 Zero Set) came along and, with AMI, cleaned up everything. Basically if too many zeros were sent a '1' was injected with the same polarity as the last '1'. The clock recovery circuitry didn't care, but the data recovery circuit would notice that the mark had the same polarity and change it to a zero to keep everything 'right'.
Anyway. To be able to put 24 phone conversations and have them all be kept track of properly, the telcos decided to band 12 of these frames together (12 frames, each with 24 channels) and use the LSB of each conversation for switching information. I believe it was the 6th and 12th frames of the Super Frame (SF) which carried this info, call them bit A and B.
Bit A and B were the line status bits. They told the telco equipment whether each line was on-hook, off-hook, busy or ringing. Now with 8kHz PCM conversations going on, losing a bit 1/6 of the time meant nothing important and it was hardly missed. For data conversations though that reduced your 24 64k channels to 24 56k channels since the end modems have no idea when that bit will be lost. There's your limit to analog modems. ISDN gives you a 64k channel because the equipment doesn't screw with the data frames every 6th frame.
Anyway the SF format was put away and the ExtendedSupaFormat (ESF) method was brought in. All it is is instead of using 12 193-bit frames, it uses 24 and continues the "I need the LSB of every channel every 6th frame" to give the telco 4 line status bits, A, B, C and D. The other two bits aren't used yet but it's for future expansion. They typically just mirror the A and B bits for now.
T1 is actually both a Layer 1 and a Layer 2 spec. It originated from the old Bellcore D1 spec in the 60s and details both the actual line voltages and the framing of data to get to those line voltages. There are no such things as T2s and T3s, only DS2s and DS3s.
quick summary:
Now the DS2 framing gets REALLY weird because the DS1 lines feeding them are not likely to be in sync so there are variable fill rates and such to maintain an intermediate bit rate which isn't really standardized... it sits between 1.544mbps and 1.56mbps I believe and is tuned at each installation since the DS1s feeding the DS2s are more or less unique. Simiarly, the DS2s feeding the DS3 aren't necessarily in sync the DS3 too has an intermediate rate.
Anyway the whole point of this post is to show that once you hit a CO you are no longer on your own copper pair. You are part of the collective. You are just a 64k channel (with an involuntary loss of 1 bit, thus dropping you to a 56k channel) in a sea of millions and millions of bits. And the fact that it all works pretty much flawlessly is a tribute to the Bellcore engineers.
And no, I'm not a Bellcore engineer. :-)
Actually most T1s these days are just HDSL to the telco, then (usually) on a frame cloud. Parigain/Adtran units are on the wall and provide a DSX-1 port to your DSU/CSU. The line quality can actually be quite a bit shittier for an HDSL connection than a HDSL2 connection, since you're distributing the "load" over two pair instead of one. Go read up on it at Adtran's site. They have great documentation.
How do I know? I'm the technical admin for a small (500 customer) ISP.
Damn you beat me to the punch. :-)
Back in the early '90s I made a pair of programs which did exactly this. (I was way into virus research back then and made a little bit of a living in my early teens doing just this) All it did was scan the drive from sector 1 looking for a partition signature, analysed it and jumped to where it indicated a boot sector was and if it existed, wrote it in to the MBR. Made a partition resizer too. Also played a lot with DOS MCBs and managed ot make a permanent LoadHigh program by altering the last MCB in the chain.
I never thought much of these programs until years later when Partition Magic came out and I realized I'd yet again screwed myself out of a cool idea. Other ideas? Hooking a modem up to the original NES (I think I still have drawings for this), 2-way paging, etc.
sigh.
How do you reconcile these two statements: Not to sound like a prick, but it sounds like user error to me. and In response: Don't run Linux on "weird" or shitty hardware.?
Easy.
He was talking about not being able to get a bootdisk to work except floppy install. I said that in all cases except for bad/misconfigured/misdetected hardware the CD-ROM drivers work, so it must be user error.
The "Don't run Linux on shitty or 'weird' hardware" comes from his statement that Windows was working on all the boxes before he got to 'em. Linux does push the hardware more, so hardware which is on the edge (the "shitty" part of that statement) tends to break or act funny. The fact that Linux doesn't have support for every weird IDE controller or video card on the planet gives rise to the "weird" part of the statement. Linux runs most hardware out there, with the exception of the bleeding edge or the truly funky. And even in the latter case it seems to support the odd device.
I find no trouble reconciling those two statements.
Yes, I think you are a prick. The fact that you call the guy inept for not being able to install Linux on hardware that you say it won't run on anyway proves it.
You can think what you like; that is your perogative. I perhaps did not explain thoroughly enough, but as you can (hopefully) now see my statements are not in conflict with each other.
Finally, I did not call him inept. I questioned his use of weird and/or shitty hardware to base his decisions on the usability/installability of Linux. I suggest a simpler course for him, as in his own words he was no Linux guru. If that makes me a prick in your eyes, so be it.
All nice and such, but should you not add the following as well?
Just a few other suggestions. I too am proud of the firewalls I run. :-)
Well, I've had a miserable time trying to get as far as a GUI. I sometimes don't even succeed in getting a boot disk to run; so far, most CD-ROM drives/drivers seem not to work, for one reason or another, so I can't do better than Debian's 7-floppy Base (Bless Debian...) in general. All that wonderful SuSE stuff... S.O.L...
Not to sound like a prick, but it sounds like user error to me. I've installed Linux on close to probably 75 or 80 machines now, from pokey (my original 80386DX/33 with Weitek copro and 8MB expansion board) to numbskull, my dual Cel466 BP6 server. From shittly little dial-on-demand computers that sit in the corner and collect dust (and dial :-) to full GUI systems for small offices. I have never had problems getting a boot disk to work. Not on IDE or even RLL (XT-style) hard drives. Actually no that's not true. I hate floppy disks and floppy drives. They are the bane of my existence. :-) Network boot? No problem.
CD-ROM troubles are almost exclusively user error, from either selecting the wrong IO/IRQ to even using the wrong driver. The older CD-ROMs can be tricky, yes, but they always work when tickled the right way.
Now on to X and GUI.
X works tickety-boo if you start out with the VGA16 driver and move on up to the SVGA or one of the specific accelerated drivers. Most problems with X occur becuase the installer is trying to either push the hardware or thinks the hardware can do something it can't.
One machine (NEC) had 990K (or 956K) of video RAM, and apparently X Win didn't like that.
Did you turn off accelleration or try the VGA16 driver first? Not to sound fecetious here, but always start from ground zero and work up if you run into trouble. Don't try to downgrade from a system that should work, rip out the config file and start from ground zero. Sometimes it's just a matter of an accelerated driver not being avaiable and you being stuck with a slow X. Other times it's the driver is buggy. You run into both these problems on Windows systems, albeit less often in my experience.
However, every single one of them was running Win 95 when the customers turned them in.
In response: Don't run Linux on "weird" or shitty hardware. Windows has a track record of supporting weird installations or flaky hardware. Linux tends to push the hardware a little harder and as such it breaks. So don't put it on weird/flaky stuff if you can help it or if you don't want to try and expand its list of compatible hardware. Especially if you're trying to impress someone. Would you load up Win2k on a 486DX4/120 with 24MB RAM to show it off for a SOHO type situation?
No, I haven't asked for help, because these attempts at installation are quite the opposite of "mission-critical", and I don't want to waste the energy and good will of someone for a relatively-trivial cause. Maybe worse, I have not kept notes, so I have only mental recollections of the problems I've encountered.
Being, as you said, not real experienced with Linux, why are you trying to see how easy it is to install on weird hardware? I've found the only real way to learn it so you can install it in unusual installations is to ask. Especially with legacy CD-ROMs and X. X is a bitch sometimes, but it does seem to be a loyal one. :-)
Believe me, my intent in this message is not to put down Linux; it's only to point out problems I've had.
I didn't take it as a put-down, but I am more or less replying to keep perspective. You will have all these same problems getting the original Windows 95 OS on them to work from a fresh install if the drivers aren't there or are buggy. How many times has someone brought a machine into the shop and said "It was working" and the only way to get it back was a fresh install? My brother owns a computer shop and I do the insanely weird technical stuff for a different small ISP/computer store. Driver problems and "weird shit" are abundant in Win9x.
I'm not exactly a newbie; was a midnight hacker in 1960, but was isolated from computers until ~1982, so I'm not really all that experienced.
I'm glad you are tinkering around with the systems that are brought in, but my advice would be to get a standard (modern) system with IDE CD-ROM and normal (read: well-supported) video and network card working before trying to get the weird stuff to work.
That being said, I kind of miss the old days of jumered motherboards, MFM/RLL controllers and obscene BIOS gestures. That old 386 I mentioned up above was one of the orignal 80386DX motherboards (before there was a 386SX) and it implements the cache control as discrete logic on its full-size motherboard. I kinda miss all that because nowadays the hardware is mostly toss-away if it breaks. The generations of hackers to come will be mostly software and programmable logic. The era of security-bits and write-only memory techniques hinder all these fresh young minds. *sniff*
These I believe were ICON 2's (80186 computer, Arcnet-type network, diskless. Color screens with blue background.
The teachers watched us *very* closely with those things. I remember getting in shit for trying to get to a prompt...
Yup. I've got one. Hardware is an 80186-based system (more embedded computer) with some kind of weird-ass token ring network. I contacted QNX for information about these systems, as I have done with Unisys but neither was able to help. Is there anyone here with hardware information on those old Unisys ICON computers? I have a few I'd like to play with...
To the average user, perhaps. The Netpliance is the exact same to the average user.
If I fail to agree to the ToS of the cellphone contract, they take my phone or bill me for the amount left owing. If they didn't, I could just take the phone to another area and get service with someone else. Netpliance tried to get around this by locking the dialup account to one account. They figured "Nobody will not get service, because it'll just be an expensive plastic paperweight without the service."
They didn't lock you down for a term, like all cellphone contracts with outrageously low prices for the unit. Their mistake, my gain.
Do you not think they'd do the same if the tables were reversed? I do. I'm fighting UUNet over something similar right now.
INCORRECT
With the cellular contracts you SIGN a piece of paper saying you agree to pay according to the terms set out on the paper. When I ordered my iopener from Netpliance's web site there were no terms of service and no minimum contract. Netpliance's oversight does not give them the right to make me pay for something I did not agree to. I did agree to $99 for the box plus $40 for shipping. NOTHING MOREYour cellular model fails because there was no contract, no "I agree" button, nadda.
If they try to get another $21 from me, they will not get it. They have no right to it.
fix your posting. It's not like you haven't known about this for ages. Not very subtle for a troll/flamebait but to risk getting moderated into Offtopic-ness: you don't correct a problem by ignoring it. Bugs are supposed to be fixed, not avoided.
FIX YOUR GODDAMN PREVIEW ROB!! -- it's not like you haven't known about it for ages!
The last part of my post SHOULD have read:
A simple "if close time < 1s, ignore" statement is not hard to work into software.
As an embedded systems designer I find this hard to believe. All mechanical switches bounce. That is a different kind of bounce, however. I imagine this "spring bounce" could be just as easily detected and ignored through reprogramming the system in-flight, just as they twiddled with the Mars Explorer firmware. A simple "if close time
Indeed. Imagine what a well-placed tfn/trinoo DDoS could do to in a critical situation!
I agree with an earlier poster that if you don't want the ability for people to do it remotely, don't put it in there in the first place. This can't be done in all circumstances, of course, but read on.
I hope to God that the arming circuitry requires some kind of hardwire interface at least for the last stage of final go-ahead for launch.
I would have though that with military tech. being, what, 5 years or more in advance of what we civilians get they would be using multiple signal, spread spectrum, 2GB encryption keys and a slew of other technologies that make it at least infeasable to try and crack. And yes I do mean for navigation and indeed all subsystems of any kind of military device or even civillian device which has the possibility for far-reaching or deadly effects if such a system were to be compromised.
<sigh> I guess that's what they mean by "military intelligence".
That was most certainly not me. Spin off, coward. Spin off and die.
What exactly is "GPU TBA" 3D accelleration? Graphics Processing Unit - To Be Announced?
It sounds neat (the box, not the accellerator) -- the 4 USB ports sounds like they want to hook up the controllers that way (Gravis has a neat gamepad or three) which is a very wise move IMO. I wonder if they will support regular cable and DSL modems through the network connection as well. Does anyone have more info on "DV linux"?
at a university? wow.
I mean this is a good thing. The questions asked will be on how to apply the knowledge, not the knowledge of the knowlege itself. That in itself is invaluable. I wish high schools worked that way but many are still stuck on the "To get the answer right, you must do it exactly how we taught. If you skip steps or do it another (valid) way, you will fail."
The part about requiring a laptop and wireless access is kind of stupid if you ask me. Why laptops? What's wrong with using the lab computers? Making each student procure a laptop is a little silly and tends to weed out the poor from the rich kids.
As far as the infrared sharing goes, You could bathe the room in randomly modulated infrared light. Or simpler, just get some bright orange electrical tape and cover the infrared port. Think of it though. All these guys are connected to the 'net. What's so hard about firing up an ICQ ActiveList or IRC or even plain email?
I believe they have ships that regularly pull up the cable and replace the batteries in the repeaters
Incorrect. The cable that gets put into the ocean is a very complex cable. At the heart is the fiber, but there is also high voltage running down the wire which the repeaters use to power themselves. Throw on a bunch more cladding, some more reinforcing steel, antother couple thousand volts, more cladding, more steel, armour and a rubber outer shell and I think you're done.
And you thought that Gobstoppers were layered! :-)
I also am pretty sure that the cable rests at the bottom of the ocean, quite some way for a ship to be pulling it up.
They also have problems with sharks attacking the repeaters because they have a slight electro-magnetic field that sharks can detect.
I haven't heard of this but wouldn't really worry too much about it.
You can do that now: Pong for N64
... with the author's desire to completely circumvent the administrator's control over their own network. There are technolgies in this software to specifically prevent it from being throttled.
Yes I'm all for free speech and the freedom of information but at what cost? I can see the entire QoS of dorms and "open" labs to be turned way way way down over this. It would have been much better to have some kind of control app which the network admins could say "300kbps tops during peak times" or something to that effect.
Mind you I can now also see work being put into firewall software which monitors for large bandwidth useage on an connection basis and, if it exceeds xkbps for y seconds, throttle that IP down or turn them off completely.
Maybe this isn't such a bad thing after all.
I bought one and there was no mention anywhere about a minimum length of contract, so they're screwed. I didn't sign anything / click on anything that said I agreed to anything whatsoever so I guess it's tough titty for them!
Buy the 3 months service for $65, and you have to pay more for the machine itself.How do you figure? $99 machine, $65 for 3 months service. $65