Actually they have a damned good idea what it will look like, a narrow peak. These are not known to occur in nature, but any technology using the radio spectrum for communication will cause these.
That's only true using the most simple transmission methods. Enter spread-spectrum or any of the carrierless transmissions and you lose that peak.
I had a pair of bitched-up Cel366s I (I think that was the speed) -- anyway -- one I tore apart and the die was welded directly to the heatsink pad, which is opposite of most chips and I believe the same as the 'flip-chips'. I don't beleive that process was unique to the E-series P3s.
The other I drilled a hole in the corner and is on my keychain.:-)
Just about every big E-commerce company will keep your credit card on hand so you don't have to enter it the next time you come in.
Bullshit.
Store a cookie with some unique identifier and pass that identifier along with the $ to take to a secondary server which is not net accessible ot do the actual transaction.
Infogenius blows goats. Try it for a couple weeks and see. It's the same problem as the GB emulator for Palm. Just isn't meant to do it.
Faceball 2000 isn't exactly what I meant by raycasted 3D graphics. I was meaning more along the lines of Doom/Quake. Wolfenstein graphics are pretty "blocky", as are Faceball's.
developing for a handheld that's still being commercially developed for sounds really cool
It is.:-) I developped a little hardware dongle and software that talked to a reduced voltage soft starter (see here) via I2C. They called it too much of a toy so I now do it on a Palmpilot for 5x the price.:-)
'sides.. The GB is a $70 child's toy, which means that our techs can't break 'em. Plus, they can play Tetris on the flight home.:-)
... in the gbdev mailing list. I run the archive at mixdown.org/gbdev.
The add-on would be a DSP or fast processor because, as one poster correctly put it, the GB processor (a bitched-up Z80) simply does not have the balls to decode an MP3 stream at any usable rate.
I too consider a GB MP3 device totally useless. A RIO gives you all that, has more memory (IIRC) and is better on batteries, to boot. The GB can't even be used as a (proper) audio output because there is only a single pin on the GB cartridge you can inject audio on, so that leaves stero operation out. Unless they've somehow used the GB sound chip in its digitized mode.
The people in that list have a lot of great ideas, but some seem to want to push the platform too far (read: beyond something economically worthwhile). Things like MP3 addons, PDA software, raycasted 3D graphics and <cough> a multitasking OS are, IMHO, a waste of effort and brainpower for otherwise bright minds. However... full-colour imagery, robotics and a multitude of cheap computing projects are well worth the effort.
If you've got one and you want to hack it, join up. You can buy Bung's cartridge to transfer your software to a real GB or use one designed by one of the list gurus. There are some people in there who do GB code for a living, others who are under Nintendo NDAs, and even others who seem to know more than Nintendo themselves knows about the GB.:-)
However Velocity is not Acceleration and Force is not Energy . (kinetic) Energy is 0.5 * m * v^2. Force is dU/dt (change in energy wrt time).
True. I was talking about the accelleration you undergo as you impact the wall (or vehicle, or telephone pole, etc.) You are certainly accellerating then, albeit negatively. Simiarly, the forces your vehicle is undergoing would be greater due to the higher energy required to get it to stop in a similar time frame.
Consequently, it is possible to be involved in a collision at 15 mph that exerts the same force on the occupant as a collision at 75 mph.
The original poster and myself were talking about the vehicles, but that's of no consequence. The energy that must be moved upon impact is much higher the faster you were going before you hit. Do you not have a higher kinetic energy when you are travelling at a faster speed? (this is where my physics becomes a little rusty)
Ek = 0.5mv^2, therefore a car travelling at 100km/h would have a four times the kinetic energy of the same vehicle moving at 50km/h, but would also take longer (but 4 times as long??) to come to rest.
Airbags don't "give you a graphic reason as to why [children should not be riding in the front seat]"; they make it unsafe. Since the mandation of passenger-side airbags in the USA, about 100 children have been killed by expanding airbags. That doesn't illustrate that sitting in the front seat is hazardous, only that airbags are hazardous.
My point is still true -- Rear seats (see below) are safer than the front seats, regardless as to whether airbags are present or not. I'd imagine this is only with front collisions (side ones would make it safer to be on the other side of the car) but the statement that kids should be in the back seat has been around for decades, not just since airbags have been introduced.
My statement about a "graphic" demonstration as to why children shouldn't be in the front with airbags is in regard to some mother who had her child decapitated by an airbag in a low-velocity collision. I wasn't stating that airbags are the only reason why front seats are unsafe for children, I was stating that back seats are safer
Besides, what if your vehicle only has front seats? Most pickup trucks and many two-door cars don't have back seats to put a child in.
I'm not 100% up on my cars here, but are there passenger-side airbags in two-seaters?
Lots of reasons. First of all, I want control over my own car. It's that feeling inside. I want to beable to shut them off whenever I want. My last car was old and had battery problems all the time.
Up here in Canada we've had daytime running lights for years. At least on our models, the lights go out when you go to start, and come on after again.
For another, there are circumstances beyond the all-wise and knowing government/automakers. Like the time my mom and I were being chased by a drunk driver, and we pulled into a driveway and turned off the lights and we lost him.
Not sure how to comment on that one.:-) Shut the engine off maybe?
Or like air bags, which for a while were seen as the greatest thing since squeezable mayo. Yet now I can't put my 5 year old in the front seat because they've found that airbags kill kids.
Children should never ever be put in the front seat, ever, airbags or otherwise. That rule has been around since the 70's if I recall. Airbags just gave you a very graphic reason as to why this is so.
The reasoning that rules like this exist are simple. It costs the government, and therefore taxpayers, more in damages and the like to have no rules than to have rules like daytime running lights, seatbelts and drunk driving legislature. You're on publicly-owned roads (at least MOST of the time) so you play by the rules set forth to benefit the public.
Where this gets out of hand, of course, is with bleeding hearts and lobbyiest groups. Up here I believe our 400-series highways were designed to be driven at 140kph (roughly 85mph). That's when they were safest. Unfortunately crying moms and the general public got it in their head that speed kills and therefore forced the limits down. Now the roads are less safe since you need to overcorrect for bends and the like.
I disagree. Speed doesn't kill, cars and stupid drivers kill. Ever seen the 15mph collision tests on cars? They get just as trashed as in a high-speed accident and survivability is only marginally altered.
That's bullshit, pure and simple. Force = mass times accelleration. If you hit a wall at 15mph and then (in a different car of the same model) hit a similar wall at 75mph there is a LOT of difference. There's a lot of energy that has to get distributed into the body of the car and wall that wasn't there in the 15mph crash.
Your fatality stats reflect the construction of the car -- the safety cage or crush zones or whatever they've put in there to control where the energy goes when you're rapidly negatively accellerating.
I'm not an advocate of this satellite control system, and I don't believe that speed kills (same as guns don't kill, same as drunk driving doesn't kill) -- it's all in the hands of the operator. If you're going too fast to properly control your vehicle (or too drunk), it's OPERATOR ERROR, not speed that caused the problem.
Less than ten dollars is cheap for a card. I wonder if USB isn't cheaper still to add to peripherals than adding a 10/100BaseT interface.
Cypress puts out a USB controller for under $3 in quantity, and no media transformer is required. I believe Microchip now puts out a USB-enabled PIC too.
I was recently reading about bluetooth. A vast number of vendors are supporting its development. It has got a good speed also. (cant remember it right now).Bluetooth is a very viable technology for home users and the speed is sufficient for printers, scanners, keyboards, mouse etc devices.
Wireless will play an important part of the future, but it will nto replace wired connections, ever. At least IMNSHO.
Yes it's fun, yes it's 31337, yes it can be fast. You'll always have interference problems when you want it most, or be just out of range, or something. Perhaps a combination of wireless and high speed serial will get us to where we need to be. The world is very very unfriendly towards wireless.
Re:Serial and Parallel in a SchizoPhrenic article?
on
Future I/O Standards
·
· Score: 5
The fact that Serial is much, much less tricky to physically handshake is the reason we've seen so many R&D development dollars poured into it.
Actually I think all the money's being poured into the design of fast serial because parallel interfaces need to be short and very rigidly controlled to be fast. And to get faster you need to add more lines (beyond the double-edge clocking and stuff). Serial offers more in this arena, and if you need to be faster than that yet, you can parallelize individual serial lines.
I won't argue with you that there's an agenda. However I don't see what's necessarily wrong with it.
Make no mistake--Serial may be awesome, but this is a new thing. The general attempt has been to spooge parallel design style into a serial interface.
This isn't necessarily true. Serial's been around forever. This LVD stuff you mention below is a relatively new commercial venue, but the idea for it has been around for quite some time. I believe some of our industrial controllers used the idea of a differential serial signal to get the point across a noisy environment and with low EMC for years now.
The fact that someone (TI and National are the biggest ones here) has thrown the design into a wire 'n go chipset doesn't make the whole idea new. Cheaper and faster, yes.:-)
(how many of these serial systems just have a "magic chip" that expands the incoming serial stream into the parallel bus everybody knows and loves?).
I was taking the article a different way. Replace the parallel busses with serial busses. Right up to the memory/cpu/video subsystems. In other words, make the controllers serial themselves. As a previous poster mentioned, the computer now becomes a series of NCs.
The conversion from serial to parallel wouldn't happen until right inside the silicon. and even then it can be split off properly to maximize chip space (i.e. split off the bits that are required for 'x' to 'x's spot, and for 'y' to 'y's spot. You aren't converting the whole thing to parallel at once, just where necessary. And if done correctly, the subsystems inside the die could possibly deal with the data at a lower data rate.
Oh my. Is that so. I would have thought it was easier with those aforementioned 90 pins of parallel joy to have quite a few streams of data traveling over physically independent traces, as opposed to a multiplexed, time lagged, two wire system, which incidentally has no requirement to be bidirectional at all thank you very much.
90 pins of parallel joy with independent pins are a waste of space and design time. Let's say you've got 6 slots sharing those 90 pins. there's only so many ways you can split them up and even if you took those 90 pins and split them in to 10 control pins and 10 independent 8-bit busses you still need to put the switching fabric on each and every device you plug into the bus, including the motherboard. It's a waste. Not to mention if some device wants to use all 10 busses to transfer something doubleplusfast, every other device must wait. In a cell-oriented serial architecture that doesn't happen. Can't happen if properly done.
You're correct in stating that you can do it with a parallel bus but I don't feel it's as flexible as a serial bus.
As far as time-lagged goes, if you designed it correctly (a la ATM) you could implement a Class of Service to the entire subsystem. And if your two wires just weren't pushing enough data, you can parallelize them then.
No, the real thing to worry about isn't so much untrustable drivers as untrustable hardware. What happens when your network bus is your keyboard bus is your hard drive bus is your memory bus? Answer: You've suddenly got lots and lots of meaningless, inconsequential hardware on the same bus as mission critical, highly secured equipment. Imagine a rootmouse that, upon being plugged in, was able to query the harddrive for the contents of/etc/shadow, completely independant of the directives from the underlying operating system. This must remain a top priority of I/O designers, and actually stands as a reason for separating heavily trafficked interfaces from less traveled, more justifiable to lock off ports.
This is significant. I believe this is the exact reason why they're taking a very hard and critical look at security on what they're proposing. Personally I think it's great. The idea of security and even encryption should be placed in Layer 1 or Layer 2 on the OSI network model, not up higher commonly sits.
I'm glad they're looking at the benefits of an open protocol as well. They hit the nail on the head with their statement about closed source drawing attention just because it's a challenge.
Your idea of a rootmouse is intriguing. How would one make sure that devices couldn't access parts it wasn't supposed to? Perhaps a seperate bus for critical system components, still allowing you to place everything on one but without the security? Perhaps a Bus Administration Unit which components must authenticate against to get access to other devices?
Then when we max out the viable speed of the serial bus we will aggregate them together having learned as much about serial bus implementation as we had parallel. In the end a happy mix between the two will be found.
exactly! massively parallel serial busses. It almost sounds oxymoronic but wow... You could even distribute data across the various parallel serial channels in order to help bottleneck issues. Each channel could have its own throttling / pritorizing management. Redundancy is kind of a lame concept here but the other aspects are sweet.
We're headed into ATM-style busses for intra-system connections!
Serial is taking over. Practically anybody could have predicted that. Firewire, USB, etc...
Two very intersting points, however, are a) They're considering Fibre in a consumer application and b) they're very seriously considering security of the link.
I haven't worked terribly much with fibre but just how sturdy is it? They're claiming up to 10kft which is a long long way... people are gonna run this under carpet, trip over it, the cat's gonna chew it... I thought that fibre was a pretty resilient technology from an EMI point of view, but what about the Home Factor? Copper wires are usually pretty good about being tripped over and ripped out of sockets. What of fibre? If you kink a fibre cable, what happens to it?
The other point was security. Basically they're arguing over two methods. One is "closed-source" and switched, while the other is "open-source". They go as far as to say that a closed implementation is a big flashy waving sign for hackers, as it's an irresistable challenge. They're bang-on there. I mean a fast standard that doesn't need 200+ connections? I'd be all over that in a heartbeat! It's refreshing to see a gathering of industry leaders actually see that aspect.
... I think it's neat... the philosophy for years has been more parallel connections. Transfer more per clock and you up your bandwidth and therefore your throughput. What's next? Serial processors? A couple megs of cache on the chip, maybe a serial bus to system memory, antoher to system I/O and one to the video subsystem? I mean they're talking throughput greater than PCI 2.1 here... Why NOT reduce the CPU to a dozen pins?
The implications here are utter foolishness. Have you ever flown across the country and looked out the window? The country has more forest now than it did several hundred years ago.
So I'm assuming you've flown over the country several hundred years ago to make this comparison. Your statement about "more forest than ever" is utter and complete bullshit The forest which was where all the cities and open parks and even farmer's fields are now was more likely than not forest.
Trees? Landfill space? We won't run out for many thousand years, if ever. At the current rate of consumption.
Another clueless statement. Rate of consumption is rising. Landfills are filling. Why do you think cities are now shipping their trash to other areas? Because they want to?
Your whole arguement rests on the suggestion that any given acre can be used for landfill or any given acre of forest can be used for logging. It just ain't so.
I agree with you on this. Those "Swifter" things are just plain stupid. But this is one lone example.
Swiffer/Swifter/whatever they are are actually a good idea. Not the throwaway part, but the electrostatically charged part. Dustbins just plain old don't pick up a lot of stuff and spread small particles everywhere. An allergy sufferer's nightmare (thankfully one I don't have). It would have been a great idea to have a grounding rod on the damn thing so that after you used it, you held it over the trash and grounded it. All the shit it picked out would fall off and be disposed of, and your cleaning utensil could be used again.
When do you figure that every last tree in the country will be eliminated. Next year? Five years from now? Maybe ten? I would really like to know.
It's not a question of short term use, but rather of long term. It doesn't take 5 or 10 years to grow a decent tree; it takes dozens of years. There are strict laws governing reforrestation but there are all kinds of loopholes. Cut down cedar or any kind of hardwood and it's reforrested with pine or some other quick-growth softwood and harvested again in 10 years. The rate of give is far below the rate of take. Go visit a logging company sometime and ask the old guys what the trees they cut down USED to look like. It ain't nothin' like it is now.
I was going to title this: "Msft solutions are Msft's problems" - but my first voyage into the world of FreeBSD years ago came with instructions to use the Microsoft® undocumented "fdisk/mbr" command - which taught me that those bastards take over the master boot record of you hard disk and don't even tell you about it! Talk about getting your foot in the door to leverage a monopoly...
Ummm... you *need* to write code to the MBR in order to boot from a hard drive. All that int19 knows to do is load cylinder 0, head 0, sector 0 to 0:7c00 and execute the code therein.
When DOS came out there were no contenders. There were no boot loaders. So it had to write a program there. LILO is a boot loader; it sits in the MBR and gets run when the system boots. What I don't like about Windows is the fact that it periodically decides to re-write the MBR and thus I lose LILO.
It had nothing to do with monopolistic tendencies (well except for the periodic MBR rewrite I mentioned) -- it is a ncecessary function in order to boot from HDD.
Which is terribly wrong indeed. The lowlevel formatting functionality provided by debug is intedended to be used for MFM and RLL disks. Those are now completely obsolete.
This is true. However you slip up here:
If you try this on a IDE disk, it will end up in killing the disk in such a horrible manner that only the manufacturer can make it usable again, if possible at all.
If you do that on an IDE drive Nothing will happen. Nada zip zero zilch. First off the command he gave would probably end up in a random procedure and just bomb out. Secondly, the ROM which existed on the MFM/RLL controller cards to do the low-level format doesn't exist since the card doesn't exist. Finally, if you had such a card in your computer, there's a pretty good chance that a) the drive would ignore the command (if the race conditions and bus contention worked out right) or b) it just plain wouldn't work, since the older drives had all the control on the card and not on the drive.
All those older drives had was lowlevel control. and first-stage head amps. The analog data came back down the wire to the controller card on your ISA bus. The controller card actually moved the heads and sent/received the analogue data.
IIRC those control cards sat on 0x170 / 0x1f0 just the same as the ATA controllers do. So if you had an MFM/RLL card in there and an IDE drive on the same physical I/O address pair, you'd end up with bus contention.
"Start your computer with the Linux setup floppy disk, type fdisk at the command prompt, and then press ENTER."
This passage is a joke. fdisk will not start until you give it a disk name. It responds with a usage message that explains you have to type something like "fdisk/dev/hda" or "fdisk/dev/sda" to go to the first drive.
BZZZZZT! Only with newer versions of fdisk does it force you to choose a drive. Slackware 3.4 and 3.6 worked this way. Slack4 requires the drive. This is a function of fdisk and if Microsoft was using an older distro of Linux their statement is perfectly correct.
Please note that I only use slackware, Redhat/Caldera/Debian/etc. may have had a different version of fdisk.
At any rate, that's not FUD; it's just plain (possibly) incorrect information. You could have used a much better example in the document, like where they say to boot Linux and type fdisk/mbr.
Last, but not least, if Microsoft wanted to be helpful, they should develp a "safe" low-level formatter for hard drives. That would de-install ANY OS, without all this faffing about.
(I like that term, 'faffing':-)
Anyway, there is no need to do this... I mean if w2k fdisk doesn't have a clue how to get rid of weird partitions, do this (in linux):
# dd if=/dev/zero of=/dev/hda bs=1k count=1
zero out the MBR and the disk looks like it's never been touched. To Linux or to Windows. No... ahem... faffing involved.:-)
but that's not what i'm talking about. my apperance is *very* tame. in an interview, there's no need of my possible employers knowing about the things i've done with a needle. it's listening to sexuaphobic, closeminded, prejudicial co-workers with intolerant opinions about things they haven't even considered trying to understand that annoy me.
I'm not sure I understand the original problem then... I thought you had said that you were upset that employers didn't take a liking to people with piercings, tattoos, etc.?
In the case of coworkers who don't like your style... well that's their problem. Personally I haven't run into an employer who sides with certain employees and not others; usually they say "deal with it."
people who then read the/. article about the fbi keeping an eye out for gamers, and get mad about how they are being judged for something they know doesn't make them a psycho.
Okay I think I see where you're coming from... Lemme know if this is right: "Slasdot reader reads about FBI targetting gamers, trenchcoat wearers and nerds. 'That's not fair; I'm not like that!' Same slashdot reader reads about body piercing, tattoos, and other forms of body modification. 'Hahahahahaha you FREAK god you guys must all be lunatics!'" -- this is what you're complaining about? If so I agree 100%. It's always easy to stereotype if you're not part of the group being stereotyped.
it saddens me to see that future employers and co-workers are so intolerant of such trivial things.
It's called marketability and employability. Businesses are intolerant of people who are so different because (at least for me) employees represent the company. I deal with customers on a regular basis, and I'm in Research and Development, nowhere near sales. If the customer/client is gonna gawk at you and distract from the sale, the company is gonna shun you. That's why the suits are the thing.
Just the same as why businesses don't allow you to swear and flip out. It's all part of ettiquitte, probably spelled wrong.:-)
Personally I think all this massive tattooing/piercing/modding is rather silly, but hey, it's your body.:-) About the most insane thing I've done is dye my hair blonde, then later "vivid plum".
Just be something can be written to once easily doesn't mean it can be changed easily. The serial number is probably stored on a PROM. You'd have to purchase that exact chip, read the information from the old PROM, change the serial number, write the new PROM, desolder the old chip, and solder in the new chip.
oh PUH-LEESE...
it is NOT difficult to do. first off, custom silicon isn't cheap, even in the thousands or tens of thousands. Most mask ROM or ASIC plants won't look at you till you hit a hundred thousand or more. So that leaves tradiditional write-once memories which are easy to obtain. But anyway back to the post at hand:
Desoldering and soldering is simple. Even at the SMT level and yes I know what I'm talking about. I used to hand-solder 204-pin PQFPs and 68-pin TQFP packages by hand. Hell, look at cell phones: YES a PROM would be the best solution, but what'd they do? EEPROM or Flash. Instant reprogramm-o. I have a neat little trick at mixdown which describes how to pick off ESN/MIN pairs from the air because they decided to use reprogrammable technology for the "unchangeable" ESN/MIN.
Look at it this way: if you put another chip on the board, you've all of a sudden added cost and space. And I/O that you didn't need before (think I2C here). So they put the codes in the Flash, or, if they already have some kind of nonvoltatile storage for parameters, E2PROM since Joe Computer user doesn't care or can't modify it.
Don't spew off this "oh muh GAWD you gotta desolder an' solder an' it's custom and oh muh GAWD!" If you wanna counterfeit you're not afraid of this. And most Joe Computer users who are concerned with privacy have a hacker friend around who isn't afraid of his soldering iron.
HAH! coming from a person who, obviously, is not a parent. Try living with a five year old while you're making the above decision. I assure you, it looks a whole lot more tempting.
Slashdot Mirror
Actually they have a damned good idea what it will look like, a narrow peak. These are not known to occur in nature, but any technology using the radio spectrum for communication will cause these.
That's only true using the most simple transmission methods. Enter spread-spectrum or any of the carrierless transmissions and you lose that peak.
I had a pair of bitched-up Cel366s I (I think that was the speed) -- anyway -- one I tore apart and the die was welded directly to the heatsink pad, which is opposite of most chips and I believe the same as the 'flip-chips'. I don't beleive that process was unique to the E-series P3s.
:-)
The other I drilled a hole in the corner and is on my keychain.
Just about every big E-commerce company will keep your credit card on hand so you don't have to enter it the next time you come in.
Bullshit.
Store a cookie with some unique identifier and pass that identifier along with the $ to take to a secondary server which is not net accessible ot do the actual transaction.
nintendo won bung in court and they're not allowed to make those cartidges anymore
North America only.
Infogenius blows goats. Try it for a couple weeks and see. It's the same problem as the GB emulator for Palm. Just isn't meant to do it.
:-) I developped a little hardware dongle and software that talked to a reduced voltage soft starter (see here) via I2C. They called it too much of a toy so I now do it on a Palmpilot for 5x the price. :-)
:-)
Faceball 2000 isn't exactly what I meant by raycasted 3D graphics. I was meaning more along the lines of Doom/Quake. Wolfenstein graphics are pretty "blocky", as are Faceball's.
developing for a handheld that's still being commercially developed for sounds really cool
It is.
'sides.. The GB is a $70 child's toy, which means that our techs can't break 'em. Plus, they can play Tetris on the flight home.
... in the gbdev mailing list. I run the archive at mixdown.org/gbdev.
:-)
The add-on would be a DSP or fast processor because, as one poster correctly put it, the GB processor (a bitched-up Z80) simply does not have the balls to decode an MP3 stream at any usable rate.
I too consider a GB MP3 device totally useless. A RIO gives you all that, has more memory (IIRC) and is better on batteries, to boot. The GB can't even be used as a (proper) audio output because there is only a single pin on the GB cartridge you can inject audio on, so that leaves stero operation out. Unless they've somehow used the GB sound chip in its digitized mode.
The people in that list have a lot of great ideas, but some seem to want to push the platform too far (read: beyond something economically worthwhile). Things like MP3 addons, PDA software, raycasted 3D graphics and <cough> a multitasking OS are, IMHO, a waste of effort and brainpower for otherwise bright minds. However... full-colour imagery, robotics and a multitude of cheap computing projects are well worth the effort.
If you've got one and you want to hack it, join up. You can buy Bung's cartridge to transfer your software to a real GB or use one designed by one of the list gurus. There are some people in there who do GB code for a living, others who are under Nintendo NDAs, and even others who seem to know more than Nintendo themselves knows about the GB.
However Velocity is not Acceleration and Force is not Energy . (kinetic) Energy is 0.5 * m * v^2. Force is dU/dt (change in energy wrt time).
:-)
True. I was talking about the accelleration you undergo as you impact the wall (or vehicle, or telephone pole, etc.) You are certainly accellerating then, albeit negatively. Simiarly, the forces your vehicle is undergoing would be greater due to the higher energy required to get it to stop in a similar time frame.
Consequently, it is possible to be involved in a collision at 15 mph that exerts the same force on the occupant as a collision at 75 mph.
The original poster and myself were talking about the vehicles, but that's of no consequence. The energy that must be moved upon impact is much higher the faster you were going before you hit. Do you not have a higher kinetic energy when you are travelling at a faster speed? (this is where my physics becomes a little rusty)
Ek = 0.5mv^2, therefore a car travelling at 100km/h would have a four times the kinetic energy of the same vehicle moving at 50km/h, but would also take longer (but 4 times as long??) to come to rest.
Physics is a wonderfull thing.
Indeed.
Airbags don't "give you a graphic reason as to why [children should not be riding in the front seat]"; they make it unsafe. Since the mandation of passenger-side airbags in the USA, about 100 children have been killed by expanding airbags. That doesn't illustrate that sitting in the front seat is hazardous, only that airbags are hazardous.
My point is still true -- Rear seats (see below) are safer than the front seats, regardless as to whether airbags are present or not. I'd imagine this is only with front collisions (side ones would make it safer to be on the other side of the car) but the statement that kids should be in the back seat has been around for decades, not just since airbags have been introduced.
My statement about a "graphic" demonstration as to why children shouldn't be in the front with airbags is in regard to some mother who had her child decapitated by an airbag in a low-velocity collision. I wasn't stating that airbags are the only reason why front seats are unsafe for children, I was stating that back seats are safer
Besides, what if your vehicle only has front seats? Most pickup trucks and many two-door cars don't have back seats to put a child in.
I'm not 100% up on my cars here, but are there passenger-side airbags in two-seaters?
Lots of reasons. First of all, I want control over my own car. It's that feeling inside. I want to beable to shut them off whenever I want. My last car was old and had battery problems all the time.
:-) Shut the engine off maybe?
Up here in Canada we've had daytime running lights for years. At least on our models, the lights go out when you go to start, and come on after again.
For another, there are circumstances beyond the all-wise and knowing government/automakers. Like the time my mom and I were being chased by a drunk driver, and we pulled into a driveway and turned off the lights and we lost him.
Not sure how to comment on that one.
Or like air bags, which for a while were seen as the greatest thing since squeezable mayo. Yet now I can't put my 5 year old in the front seat because they've found that airbags kill kids.
Children should never ever be put in the front seat, ever, airbags or otherwise. That rule has been around since the 70's if I recall. Airbags just gave you a very graphic reason as to why this is so.
The reasoning that rules like this exist are simple. It costs the government, and therefore taxpayers, more in damages and the like to have no rules than to have rules like daytime running lights, seatbelts and drunk driving legislature. You're on publicly-owned roads (at least MOST of the time) so you play by the rules set forth to benefit the public.
Where this gets out of hand, of course, is with bleeding hearts and lobbyiest groups. Up here I believe our 400-series highways were designed to be driven at 140kph (roughly 85mph). That's when they were safest. Unfortunately crying moms and the general public got it in their head that speed kills and therefore forced the limits down. Now the roads are less safe since you need to overcorrect for bends and the like.
I disagree. Speed doesn't kill, cars and stupid drivers kill. Ever seen the 15mph collision tests on cars? They get just as trashed as in a high-speed accident and survivability is only marginally altered.
That's bullshit, pure and simple. Force = mass times accelleration. If you hit a wall at 15mph and then (in a different car of the same model) hit a similar wall at 75mph there is a LOT of difference. There's a lot of energy that has to get distributed into the body of the car and wall that wasn't there in the 15mph crash.
Your fatality stats reflect the construction of the car -- the safety cage or crush zones or whatever they've put in there to control where the energy goes when you're rapidly negatively accellerating.
I'm not an advocate of this satellite control system, and I don't believe that speed kills (same as guns don't kill, same as drunk driving doesn't kill) -- it's all in the hands of the operator. If you're going too fast to properly control your vehicle (or too drunk), it's OPERATOR ERROR, not speed that caused the problem.
Less than ten dollars is cheap for a card. I wonder if USB isn't cheaper still to add to peripherals than adding a 10/100BaseT interface.
Cypress puts out a USB controller for under $3 in quantity, and no media transformer is required. I believe Microchip now puts out a USB-enabled PIC too.
I was recently reading about bluetooth. A vast number of vendors are supporting its development. It has got a good speed also. (cant remember it right now).Bluetooth is a very viable technology for home users and the speed is sufficient for printers, scanners, keyboards, mouse etc devices.
Wireless will play an important part of the future, but it will nto replace wired connections, ever. At least IMNSHO.
Yes it's fun, yes it's 31337, yes it can be fast. You'll always have interference problems when you want it most, or be just out of range, or something. Perhaps a combination of wireless and high speed serial will get us to where we need to be. The world is very very unfriendly towards wireless.
The fact that Serial is much, much less tricky to physically handshake is the reason we've seen so many R&D development dollars poured into it.
:-)
/etc/shadow, completely independant of the directives from the underlying operating system. This must remain a top priority of I/O designers, and actually stands as a reason for separating heavily trafficked interfaces from less traveled, more justifiable to lock off ports.
Actually I think all the money's being poured into the design of fast serial because parallel interfaces need to be short and very rigidly controlled to be fast. And to get faster you need to add more lines (beyond the double-edge clocking and stuff). Serial offers more in this arena, and if you need to be faster than that yet, you can parallelize individual serial lines.
I won't argue with you that there's an agenda. However I don't see what's necessarily wrong with it.
Make no mistake--Serial may be awesome, but this is a new thing. The general attempt has been to spooge parallel design style into a serial interface.
This isn't necessarily true. Serial's been around forever. This LVD stuff you mention below is a relatively new commercial venue, but the idea for it has been around for quite some time. I believe some of our industrial controllers used the idea of a differential serial signal to get the point across a noisy environment and with low EMC for years now.
The fact that someone (TI and National are the biggest ones here) has thrown the design into a wire 'n go chipset doesn't make the whole idea new. Cheaper and faster, yes.
(how many of these serial systems just have a "magic chip" that expands the incoming serial stream into the parallel bus everybody knows and loves?).
I was taking the article a different way. Replace the parallel busses with serial busses. Right up to the memory/cpu/video subsystems. In other words, make the controllers serial themselves. As a previous poster mentioned, the computer now becomes a series of NCs.
The conversion from serial to parallel wouldn't happen until right inside the silicon. and even then it can be split off properly to maximize chip space (i.e. split off the bits that are required for 'x' to 'x's spot, and for 'y' to 'y's spot. You aren't converting the whole thing to parallel at once, just where necessary. And if done correctly, the subsystems inside the die could possibly deal with the data at a lower data rate.
Oh my. Is that so. I would have thought it was easier with those aforementioned 90 pins of parallel joy to have quite a few streams of data traveling over physically independent traces, as opposed to a multiplexed, time lagged, two wire system, which incidentally has no requirement to be bidirectional at all thank you very much.
90 pins of parallel joy with independent pins are a waste of space and design time. Let's say you've got 6 slots sharing those 90 pins. there's only so many ways you can split them up and even if you took those 90 pins and split them in to 10 control pins and 10 independent 8-bit busses you still need to put the switching fabric on each and every device you plug into the bus, including the motherboard. It's a waste. Not to mention if some device wants to use all 10 busses to transfer something doubleplusfast, every other device must wait. In a cell-oriented serial architecture that doesn't happen. Can't happen if properly done.
You're correct in stating that you can do it with a parallel bus but I don't feel it's as flexible as a serial bus.
As far as time-lagged goes, if you designed it correctly (a la ATM) you could implement a Class of Service to the entire subsystem. And if your two wires just weren't pushing enough data, you can parallelize them then.
No, the real thing to worry about isn't so much untrustable drivers as untrustable hardware. What happens when your network bus is your keyboard bus is your hard drive bus is your memory bus? Answer: You've suddenly got lots and lots of meaningless, inconsequential hardware on the same bus as mission critical, highly secured equipment. Imagine a rootmouse that, upon being plugged in, was able to query the harddrive for the contents of
This is significant. I believe this is the exact reason why they're taking a very hard and critical look at security on what they're proposing. Personally I think it's great. The idea of security and even encryption should be placed in Layer 1 or Layer 2 on the OSI network model, not up higher commonly sits.
I'm glad they're looking at the benefits of an open protocol as well. They hit the nail on the head with their statement about closed source drawing attention just because it's a challenge.
Your idea of a rootmouse is intriguing. How would one make sure that devices couldn't access parts it wasn't supposed to? Perhaps a seperate bus for critical system components, still allowing you to place everything on one but without the security? Perhaps a Bus Administration Unit which components must authenticate against to get access to other devices?
Then when we max out the viable speed of the serial bus we will aggregate them together having learned as much about serial bus implementation as we had parallel. In the end a happy mix between the two will be found.
exactly! massively parallel serial busses. It almost sounds oxymoronic but wow... You could even distribute data across the various parallel serial channels in order to help bottleneck issues. Each channel could have its own throttling / pritorizing management. Redundancy is kind of a lame concept here but the other aspects are sweet.
We're headed into ATM-style busses for intra-system connections!
just a handful of pins (more then a dozen, but not much more)
:-)
How much do you pay for gloves?
Twelve pins, not 12 hands... <whack>
Serial is taking over. Practically anybody could have predicted that. Firewire, USB, etc...
Two very intersting points, however, are a) They're considering Fibre in a consumer application and b) they're very seriously considering security of the link.
I haven't worked terribly much with fibre but just how sturdy is it? They're claiming up to 10kft which is a long long way... people are gonna run this under carpet, trip over it, the cat's gonna chew it... I thought that fibre was a pretty resilient technology from an EMI point of view, but what about the Home Factor? Copper wires are usually pretty good about being tripped over and ripped out of sockets. What of fibre? If you kink a fibre cable, what happens to it?
The other point was security. Basically they're arguing over two methods. One is "closed-source" and switched, while the other is "open-source".
They go as far as to say that a closed implementation is a big flashy waving sign for hackers, as it's an irresistable challenge. They're bang-on there. I mean a fast standard that doesn't need 200+ connections? I'd be all over that in a heartbeat! It's refreshing to see a gathering of industry leaders actually see that aspect.
... I think it's neat... the philosophy for years has been more parallel connections. Transfer more per clock and you up your bandwidth and therefore your throughput. What's next? Serial processors? A couple megs of cache on the chip, maybe a serial bus to system memory, antoher to system I/O and one to the video subsystem? I mean they're talking throughput greater than PCI 2.1 here... Why NOT reduce the CPU to a dozen pins?
The implications here are utter foolishness. Have you ever flown across the country and looked out the window? The country has more forest now than it did several hundred years ago.
So I'm assuming you've flown over the country several hundred years ago to make this comparison. Your statement about "more forest than ever" is utter and complete bullshit The forest which was where all the cities and open parks and even farmer's fields are now was more likely than not forest.
Trees? Landfill space? We won't run out for many thousand years, if ever. At the current rate of consumption.
Another clueless statement. Rate of consumption is rising. Landfills are filling. Why do you think cities are now shipping their trash to other areas? Because they want to?
Your whole arguement rests on the suggestion that any given acre can be used for landfill or any given acre of forest can be used for logging. It just ain't so.
I agree with you on this. Those "Swifter" things are just plain stupid. But this is one lone example.
Swiffer/Swifter/whatever they are are actually a good idea. Not the throwaway part, but the electrostatically charged part. Dustbins just plain old don't pick up a lot of stuff and spread small particles everywhere. An allergy sufferer's nightmare (thankfully one I don't have). It would have been a great idea to have a grounding rod on the damn thing so that after you used it, you held it over the trash and grounded it. All the shit it picked out would fall off and be disposed of, and your cleaning utensil could be used again.
When do you figure that every last tree in the country will be eliminated. Next year? Five years from now? Maybe ten? I would really like to know.
It's not a question of short term use, but rather of long term. It doesn't take 5 or 10 years to grow a decent tree; it takes dozens of years. There are strict laws governing reforrestation but there are all kinds of loopholes. Cut down cedar or any kind of hardwood and it's reforrested with pine or some other quick-growth softwood and harvested again in 10 years. The rate of give is far below the rate of take. Go visit a logging company sometime and ask the old guys what the trees they cut down USED to look like. It ain't nothin' like it is now.
I was going to title this: "Msft solutions are Msft's problems" - but my first voyage into the world of FreeBSD years ago came with instructions to use the Microsoft® undocumented "fdisk /mbr" command - which taught me that those bastards take over the master boot record of you hard disk and don't even tell you about it! Talk about getting your foot in the door to leverage a monopoly...
Ummm... you *need* to write code to the MBR in order to boot from a hard drive. All that int19 knows to do is load cylinder 0, head 0, sector 0 to 0:7c00 and execute the code therein.
When DOS came out there were no contenders. There were no boot loaders. So it had to write a program there. LILO is a boot loader; it sits in the MBR and gets run when the system boots. What I don't like about Windows is the fact that it periodically decides to re-write the MBR and thus I lose LILO.
It had nothing to do with monopolistic tendencies (well except for the periodic MBR rewrite I mentioned) -- it is a ncecessary function in order to boot from HDD.
Which is terribly wrong indeed. The lowlevel formatting functionality provided by debug is intedended to be used for MFM and RLL disks. Those are now completely obsolete.
This is true. However you slip up here:
If you try this on a IDE disk, it will end up in killing the disk in such a horrible manner that only the manufacturer can make it usable again, if possible at all.
If you do that on an IDE drive Nothing will happen. Nada zip zero zilch. First off the command he gave would probably end up in a random procedure and just bomb out. Secondly, the ROM which existed on the MFM/RLL controller cards to do the low-level format doesn't exist since the card doesn't exist. Finally, if you had such a card in your computer, there's a pretty good chance that a) the drive would ignore the command (if the race conditions and bus contention worked out right) or b) it just plain wouldn't work, since the older drives had all the control on the card and not on the drive.
All those older drives had was lowlevel control. and first-stage head amps. The analog data came back down the wire to the controller card on your ISA bus. The controller card actually moved the heads and sent/received the analogue data.
IIRC those control cards sat on 0x170 / 0x1f0 just the same as the ATA controllers do. So if you had an MFM/RLL card in there and an IDE drive on the same physical I/O address pair, you'd end up with bus contention.
This passage is a joke. fdisk will not start until you give it a disk name. It responds with a
usage message that explains you have to type something like "fdisk
BZZZZZT! Only with newer versions of fdisk does it force you to choose a drive. Slackware 3.4 and 3.6 worked this way. Slack4 requires the drive. This is a function of fdisk and if Microsoft was using an older distro of Linux their statement is perfectly correct.
Please note that I only use slackware, Redhat/Caldera/Debian/etc. may have had a different version of fdisk.
At any rate, that's not FUD; it's just plain (possibly) incorrect information. You could have used a much better example in the document, like where they say to boot Linux and type fdisk
Last, but not least, if Microsoft wanted to be helpful, they should develp a "safe" low-level formatter for hard drives. That would de-install ANY OS, without all this faffing about.
:-)
... ahem... faffing involved. :-)
(I like that term, 'faffing'
Anyway, there is no need to do this... I mean if w2k fdisk doesn't have a clue how to get rid of weird partitions, do this (in linux):
# dd if=/dev/zero of=/dev/hda bs=1k count=1
zero out the MBR and the disk looks like it's never been touched. To Linux or to Windows. No
but that's not what i'm talking about. my apperance is *very* tame. in an interview, there's no need of my possible employers knowing about the things i've done with a needle. it's listening to sexuaphobic, closeminded, prejudicial co-workers with intolerant opinions about things they haven't even considered trying to understand that annoy me.
/. article about the fbi keeping an eye out for gamers, and get mad about how they are being judged for something they know doesn't make them a psycho.
I'm not sure I understand the original problem then... I thought you had said that you were upset that employers didn't take a liking to people with piercings, tattoos, etc.?
In the case of coworkers who don't like your style... well that's their problem. Personally I haven't run into an employer who sides with certain employees and not others; usually they say "deal with it."
people who then read the
Okay I think I see where you're coming from... Lemme know if this is right: "Slasdot reader reads about FBI targetting gamers, trenchcoat wearers and nerds. 'That's not fair; I'm not like that!' Same slashdot reader reads about body piercing, tattoos, and other forms of body modification. 'Hahahahahaha you FREAK god you guys must all be lunatics!'" -- this is what you're complaining about? If so I agree 100%. It's always easy to stereotype if you're not part of the group being stereotyped.
it saddens me to see that future employers and co-workers are so intolerant of such trivial things.
:-)
:-) About the most insane thing I've done is dye my hair blonde, then later "vivid plum".
It's called marketability and employability. Businesses are intolerant of people who are so different because (at least for me) employees represent the company. I deal with customers on a regular basis, and I'm in Research and Development, nowhere near sales. If the customer/client is gonna gawk at you and distract from the sale, the company is gonna shun you. That's why the suits are the thing.
Just the same as why businesses don't allow you to swear and flip out. It's all part of ettiquitte, probably spelled wrong.
Personally I think all this massive tattooing/piercing/modding is rather silly, but hey, it's your body.
Just be something can be written to once easily doesn't mean it can be changed easily. The serial number is probably stored on a PROM. You'd have to purchase that exact chip, read the information from the old PROM, change the serial number, write the new PROM, desolder the old chip, and solder in the new chip.
oh PUH-LEESE...
it is NOT difficult to do. first off, custom silicon isn't cheap, even in the thousands or tens of thousands. Most mask ROM or ASIC plants won't look at you till you hit a hundred thousand or more. So that leaves tradiditional write-once memories which are easy to obtain. But anyway back to the post at hand:
Desoldering and soldering is simple. Even at the SMT level and yes I know what I'm talking about. I used to hand-solder 204-pin PQFPs and 68-pin TQFP packages by hand. Hell, look at cell phones: YES a PROM would be the best solution, but what'd they do? EEPROM or Flash. Instant reprogramm-o. I have a neat little trick at mixdown which describes how to pick off ESN/MIN pairs from the air because they decided to use reprogrammable technology for the "unchangeable" ESN/MIN.
Look at it this way: if you put another chip on the board, you've all of a sudden added cost and space. And I/O that you didn't need before (think I2C here). So they put the codes in the Flash, or, if they already have some kind of nonvoltatile storage for parameters, E2PROM since Joe Computer user doesn't care or can't modify it.
Don't spew off this "oh muh GAWD you gotta desolder an' solder an' it's custom and oh muh GAWD!" If you wanna counterfeit you're not afraid of this. And most Joe Computer users who are concerned with privacy have a hacker friend around who isn't afraid of his soldering iron.
HAH! coming from a person who, obviously, is not a parent. Try living with a five year old while you're making the above decision. I assure you, it looks a whole lot more tempting.
:-)
AMEN!!
Score: 5 (Preach on, Brother!)