Seems to me that this CPU MHz race makes no sense at all: until we're stuck with PCI bandwith limitations these little monsters will only do more idle cycles, while waiting for data...
I agree that the 33Mhz 32bit PCI bus can be a limitation for some things, like trying to push a gigabit ethernet at a gigabit. I don't see this as the big problem in PC class machines just yet. Maybe in two years or so.
First off you can get 66Mhz 64bit (or maybe just 33Mhz 64bit) PCI slots in motherbords that cost under $300. That is 2x or 4x the bandwidth. So if 33Mhz 32bit PCI is a "little limiting", 66Mhz 64bit PCI should have a lot of head room.
Secondly, there are very very few things you hook up to a machine that push past the PCI bandwidth (the gigabit ethernet being on of the few, an extreamly fast RAID controler being another, and it is only a little past the 33Mhz 32bit PCI bandwidth). So you need a case where you push multiple devices to their limit before PCI is the limiting factor (like I want to read off my massave disk array and send it out these two GE ports...). (3D video cards being a modest execption, because they allready have their own "bus")
Thirdly, and more important, it is main memory that is the bottleneck for most things. It has been for over a decade. It isn't getting better (main memory is getting faster, but not as fast as CPUs are).
I really hope that the big players will find a new architecture, but something more interesting than the ridicolous Rambus thing:
From a technical point of view what is wrong with RAMbus? It is 1992 technology that was great then, and great for five years after. The compony that invented it charged too much for patent rights, never managed to hit the mass market, didn't get to drive costs down, and in the end didn't make enough money to plow it back into research to keep up with the entire rest of the world. But that isn't a technological problem, it is an econmic one. More importnatly RAMbus is extreamly intresting.
Plus if you want bandwith, and a little latency is Ok RAMBus kicks ass. Unfortunitly bandwith isn't really as useful as low latency for most applications, and at RAMBus's current price it is cheeper to build very wide normal memorys.
Oh, and RAMBus and PCI don't play in the same space. One is a memory system, the other is a perphrial system. It is like saying "Volvo's T5 engine is out dated, they should devlop something like the VW transmition!".
maybe they will come out with a solution like Sun's S-BUS, this would really change the PC market!
They did make something like the SBus. It is called PCI. On paper it uses the same FCode (in practice is normally uses Intel x86 assembly). It has vender and device IDs. It has auto config. It is fast (the SBus is 32bits at about 25Mhz, slightly slower then the PCI bus). PCI abandoned the SBus form factor. PCI abondened using strings for dev/manuf IDs. PCI dropped the IOMMU (which was re-invented for AGP as "Intel's innovatave new DIME"). But PCI is relitavly similar, and being designed afterwords it is even somewhat better in some ways.
Sun has dropped the SBus over the last few (3?) years. They are using PCI. Not just in the low end "PC priced" machines, but even their most expensave machines use PCI for perphrials (they use their own thing for memory and CPU boards, no big supprise).
In fact, if I remember well, S-Bus is not really a bus but each slot has a point-to-point connection to a dedicated controller that handles data without CPU usage: this would be a real change! (but correct me if I'm wrong)
I'm afarid you are wrong. The SBus is indeed a bus. many high end SPARC systems had multiple SBus's hooked up over what may have been a point-to-point controler (like the FHB), but i think that was just a bigger bus. Existing high end SPARCs hook backplane bords up over a point to point system, some backplane bords have CPU, others PCI busses, others memory. SGI does the same thing.
You may be thinking of Intel's NGIO (Next Gen I/O), or the Cisco/20others Future-something-or-oither. Both are extreamly fast serial-ish point to point systems that could have a fast non-blocking switch at the center. NGIO has been "in the works" since like 1995. Not sure when the other started, or when we will see anything.
The benchmark makes a big deal of the slow L2 cache. It doesn't mention that the L1 cache is 128K, quite a bit larger then the P-III L1 cache (which I think is 32K). So when the Athalon gets the faster L2 cache, while I have no doubt it will help a great deal, it won't help as much as, say going from no cache on the Celeron to a 128K cache.
The P-III also has a much lower latency to it's small L1 cache, and to it's decent sized L2 cache. That can make a big diffrence for anything that chaces pointers down a linked list, or any other extreamly latency sensitave application.
All that siad, I really like the Athalon, it is a good value for the money. My new Unix box sitting next to my desk here is an Athalon (only 650Mhz, I figure I'll pick up a DP system later in the year if I'm lucky).
the AMD 1Ghz just barely outperfom the Kyrotech 1Ghz chips. When you look at the cache, the kyrotech is an 800 upped to 1G, therefore the cache, which was at 320 is at 400 in the kyrotech, vs 333 in the AMD chip. What else was changed in the AMD chip to make it outperform an older version of itself with faster cache?
As far as I can tell, nothing. The motherboard the air-cooled 1Ghz part ran in has a better chipset (the KX133). If you look at page 3 air cooled part is shown with the KX133, and 256M of PC133 memory. If you happen to magically know what the Kyrotech part is (the benchmark didn't say) it is one of the old AMD750/751 baised motherboards, like the second set of systems. It doens't support PC100 memory, and it had may not have supported the PC100 memory as well as it could (many 750s can't use "Super Bypass" mode, which as far as I can tell is a way to skip 75% of the latency in the common case, without getting the wrong answer sometimes).
In other words this is kind of a lame CPU benchmark since the systems were not made as similar as possable. It is a fine system benchmark, since you won't get the Kyrotech in any other motherboard. You probbaly wouldn't want to put a new AMD in a non KX133 system. Still the totally diffrent hard drives and sound cards and stuff, and diffrent amounts of memory arn't a good idea to get a isolate component test! Maybe not even for the system test (what gamer would spend over $1000 on a CPU, and stick with crappy 2 chanel on the motherboard sound chip?)
So, for limited size operations, four to eight machines, give or take, wouldn't a monitor/keyboard switchbox be the way to go?
That might be cheeper. But won't a limited size operation have a limited number of people who can fix the problem? What if they are home sleeping? Or home sick? If all you have is the keybord/vid switch you either
Wait until they drive into the office
Force them to go through the extreamly low bandwidth lossy interfaces of "Ok what does it say now?" "Yeah, press the F1 key, that's the key with both F and one on it, not F then one!" "What did it do?" "No really" "Fuck"
For a big operation, it may only be the diffrence between the on duty person running form their desk to the right machine room, finding the crash cart and draging it to the right spot vs typing "console machine-name". Call it five to ten minutes. A big operation can lose a lot of money with five to ten extra minutes of down time.
Moreover, such solutions allow different platforms (ie Mac, Sun, and Linux Boxes) to be run through the same monitor and or keyboard.
The Sun allready has a great serial console. It can hard-reset the system. It can be told to boot off a diffrent disk controler. It can be told to boot off the same disk controler, but a diffrent disk (which no PC serial port re-director I have ever seen lets you!). It can let you boot off the distro CD and reformat the hard drive and re-install from scratch, all while the machine is sitting in a telco closet 300 miles from your closest employee. The Mac uses the same OpenFirmware base stuff, so I would hope it has retained this as well, but I have no direct knolage, nor really high hopes that Apple kept that bit of non-graphical greatness.
Another nice feature of a serial console vs. a switcher is you can run all the lines into a program that does logging, allows interactiave logins, and watches the log for anything an operator might need to look into "panic" "PAIRTY" and the like. You can get notice of a failure before sombody calls you, or before you next monitoring sweep. You can also get some log to analise, rather then thinking the new Froon2000 motherboard is a bit more flakey then the Froon1000 you can examine a months logs and get a fialure rate. Hard data is better then a vague feeling.
My question is does this gizmo let me bypass a damaged boot image and use my "spare" boot drive (or CD) so I can do a re-install? That would be kinda tough since it isn't the disk controler.
[Corpratism...]
In my experience, it is a word used by people who see that so-called free market capitalism regularly produces results which seem unsound, but are unwilling to question whether capitalism itself provides incentives toward sub-optimal outcomes.
Of corse free market capitalism regularly produces unsound results. The free market doesn't find global optima, it finds local optima. As far as I know it is the most efficent process known to find local econmic optmia. The only one in fact. There is no known way to find econmic global optima.
You can look at the local optmia that the free market does find, and imagine a better end result, but nobody has shown a process that finds that result for you! Certonally no econ text I have read talks about one. Certonally no non-free market economy seems to be doing better then the mostly-free-merket economies of the world. (I don't know any country that uses a total free market economy, but many are "close enough")
And come on people, be honest... Everyone who has never ever ever downloaded one song from napster which they did not already own, raise your hands high above everyone elses so we can call you liars.
Raises hand. I've never run napster. I'm pretty sure the only tracks I have downloaded (using ftp, or rcp, or Netscape) that I don't own the CD of are from two CDs that arn't available in the USA (plus stuff from MP3.com). One I have on order, but Wax Tracks keeps pusing the US release data back The other is H2SO4's Imatation Leather Jacket (I think). I havn't been able to find it anywhere.
I even spent about $200 buying all the import singles of my faverote band just so I didn't have to steal them.
More intrestingly, my avg. spending on CDs from 1993 to 1998 was about $0. In 1999 I spent at least $500 on them. (all from listening to a legal CD archive at work, and partly because my new car has a CD player)
It wouldn't be all that suprising if Linux could run on the custom CPUs. I seem to recall the MPR article on EE stating that Emotion Engine executed an extended MIPS III (IV?) instruction set.
But I havn't seen anything about a MMU on the PSX2. If it doesn't have one you won't get a normal Linux to run on it. You will need to port uLinux or whatever the Linux varient that doesn't have memory protection, and has either a relocator, or requires PIC code.
Doing that will substantally reduce the stability of Linux (or any OS), as errors in one program can easally damage another program.
Personally I think it is very possable that Sony will have left an MMU out. MMUs are of modest complexity, and tend to add a big chunk of work right in the LOAD/STORE pipeline where modern CPUs are striving for minimal extra cruft to reduce memory latency. They arn't needed in a game machine. They arn't needed in a DVD player. They arn't needed anywhere there is only one task going on and you can basically reboot into the next task. It is possable they were farsighted enough to decide that if they want to be a "PC killer" a MMU could have been useful, but I wouldn't bet any money on it.
P.S. the Dreamcast has an MMU because WinCE wants a MMU, and Sega wanted WinCE, in case it took off. That's why it can run a relitavly normal NetBSD or Linux port (I don't know of a Linux port, there was a BSD port of some sort).
But let's say that you want to give a "gift". In many cases, the banks prefer that you use what they call a "certified" check. Perhaps that's what you're thinking about and that's what I'm talking about. For me to write out a "personal" check for $20,000 for say, giving to the Linux Router Project...
I havn't given a large gift check beofre, but I know banks like you to use certified checks for any thing. Sometimes they get the charge a direct fee for cert. checks. Other times they win just by getting the "float" on the money. A cert. check actually moves the money from your (I assume) intrest bearing account into the banks's account (where they get the intrest) as soon as issued. So they love it when you pay for big ticket items like homes that way.
The seller likes cert. checks because they don't bounce for lack of sufficent funds, and the issuer can't put a stop payment on them (at least not normally). It is generally a requiremnt when you buy a home. Sometimes for used cars. It wasn't for any of the new cars I have bought.
As far as writing a $20,000 check to the "Linux Router Project", I don't see what eyebrows at a bank that will raise. They have no idea it is a gift. They probbably susspect you are buying a woodworking shop.
And besides, as previous posters have noted, if you're talking that kind of money, you should seek out or should already have a "financial advisor", who will take care of those pesky little details for ya!;-)
Indeed. However they can't issue cert. checks. They can route the money around, and advise you on whetehr you are better off cutting a normal check and not getting intrest on it durring the "settiling period", or paying evtra for the wire transfer which lets you get a few extra days of intrest.
They also may advise you to invest the $20k and make a fund that pays out $1k a year to your favored project (not all that likely for a "mere" $20k, but for $100k or more that could be the way to go).
If the music industry gets this in front of congress, runs a quick search and shows that 98% of all available songs on the Napster network are copyrighted it will absolutely destroy any credibility
According to the ninth circuit court you have the legal right to load a MP3 of a copyright song that you own on CD. I remember reading that off a link from slashdot, but couldn't find it in slashdot's search, but here is a diffrent summary http://www.nylj.com/tech/091399t3.html, unfortunitly it doesn't really discuss space shifting. As I recall the judge essensally ruled that owning the CD was like owning a "right to use", so owning Ray of Light on CD gave you the right to listen to it in MP3 or other forms. He went on to rule that it didn't matter if you gained the other form from a source that wasn't allowed to listen to it (which I found supprising). I wish I had kept a link to the ruling. Does anyone have one?
MP3.com's "BeamIt" relys on this ruling (as far as I can tell).
So you can't just point to the large number of copyrighted works in Napaster's list, you have to show that the people downloading the songs don't have the legal right to do so!
At the University of Maryland we wrote an extreamly primitave OS (no filesystem, no memory protection, but it had a text mode windowing system!). We did it from the raw hardware, so it was pretty damm chalanging. You learn a lot of things that way (like how to really write intrrupt handlers, not how to use someone else's framework!).
I think there is a lot of merit in that approch. It was the only class at UofM where we touched bare metal (the assembly class was close though). I think it is important that CS students do that at least once.
I also think students could benifit from doing larger things to an existing OS. But as a diffrent class. I would focus not on things Linux needs, but things the students could learn from. Like putting in a fixed-priority scheduler, and then testing for priority inversion, and finding a way to fix that. Maybe adding a batch scheduler. Writing a driver for a simple piece of hardware (like the serial port). Maybe something slighlty more complex, like something that DMAs. Maybe an IDE controler driver. Sound cards would be better then IDE controlers, except that would be a pain in a lab enviroment, and the hardware changes from year to year.
I know none of this would directly benifit the Linux comunity, but it would greatly benifit the students. Remember it is easyer to grade a project with a known outcome then something open ended! It is also easyer for the TAs to advise students on smaller projects with known results. The students will gain some first hand knolage of formerly abstract concepts, and some knolage of Linux internals.
Besides, it's a bit difficult to write out a check for US$20,000 and hand it to someone without your bank and the recipient having a fit (in fact they start bugging out if the check is for US$1,000 or more!).
Really? What bank? What recipent? I have been told banks get fussy about large cash withdraws, but I don't think that is the case for checks! I have written a check for my townhouse, then later my house, and a car even. All of which were bigger then US$20k. Never saw anyone having a fit. Also a few tax checks, but somone had a fit there. Me.
First, how much faster can processors get? I'm not only talking about the x86 world, but all the other ones that are silicon-alluminum/copper based? Four years ago (or thereabouts), when I got my P100 speeds of 1Ghz were almost unthikable of.
IBM is pretty sure 4Ghz is doable in the next two years by doing multiple independent clocks with async buffering between them. Slashdot ran something about that within the last month or so.
I don't know how fast CPUs can really get, but clock speed isn't the only factor. Work done per cycle is also important. If you look at today's (desktop/workstation) CPUs they all can execute more then one instruction per cycle. Two is a minimum. Three is the sustained max for Intel/AMD. Some RISC CPUs can do 5 instructions (UltraSPARC) if they are just the right set. This rarely happens, so most of hte time your two/three/five banger is executing zero (waiting for main memory), or one (too many read-after-write hazards) instruction. Transmeta is trying to fix this by making the (emulated) CPU really smart. The Alpha is trying to fix this by executing instrctions from more then one process at the same time (i.e. an ADD and MUL from your MP3 player, a LOAD and FMUL for your Quake server, and a STORE and a CMP for the re-compile of your Linux kernel). Compaq's simulations say this is really the shit. In two years I guess we will be able to see if it is. (the idea isn't new, the Terra supercomputer does something similar, and barrel processors have been doing something similar for decades).
As for 1Ghz being unthinkable four years ago, I assure you the design cycle for CPUs is long enough that the team that built the Athalon was almost certonally thinking of it. About eight years ago the Alpha archature manual was talking about it. Seven years I would have taken a bet that the Alpha would be the first "desktop" CPU to hit it. Apparently later this month I can be thankful nobody took me up on it.:-)
Second, except for PR purposes, what is the need for such fast cpus? I mean right now there isn't one thing that I need to get done that my P2 300 cannot do it.
I have a 200Mhz machine at work, and a 266Mhz at work. Both do nicely for a lot of tasks. I bought a new machine to ray trace on (you could give me a million 1Ghz machines and I could still use more CPU to raytrace on...well maybe not me, but a real artest I guess). Neither do well for modern games, which seem to be a big driver for fast desktop CPUs. My C++ compiler could use a faster CPU too, which is why I don't do compiles on my 200Mhz box at work.
Not to mention that I still use the P100 every day almost. I agree, there are certain computing tasks that require a _lot_ of processing power, but is that demand so great that the Crays (soon to be Tera soon to be Cray again), or the other supercomputers cannot handle it?
A fast desktop machine doesn't have the I/O of an oldish supercomputer. It does have a faster CPU. It's CPU is even competitave with modern supercomputers (sometimes it shares the CPU!). It's memory system and I/O is staggeringly far behind. Then again so is it's microscopic price tag.
So a fast desktop is good for anything that can get away with less memory, slower memory, and slower I/O, and just pain can't afford a supercomputer.
Since supercomputers are staggeringly expensave, I would guess lots of stuff "makes do" with desktop CPUs. Off the top of my head I would say:
The stuff listed above (ray trace, hungry compilers, games games games)
Non-ray trace digital movie special effects
CAD/CAM design of cars, cell phones, and dishwashers
Circuit design for new CPUs, MP3 players, and cellphones
Anyone who has to build or test or support the programs on this list
AMD has a brand new Athlon core to work with, but Intel is doing all they can to s t r e c h the PPro/PII/PIII core to faster speeds by increasing the length of the pipeline everywhere they can.
I assume the "increasing the length of the pipeline" is Intel's Wilmate (or whatever they call it). That is a totally new core. You don't double the pipeline length, slap on trace cache, and slip a 3Ghz ALU into an existing CPU. It is a totally new beast.
Of corse new doesn't mean better. It will be hell on self-modifying code, and it may not even tolarate code that has read-only data on the same page as code! (the new CPU doesn't allow the DTLB and ITLB to map the same page, there is speculation that DTLB entryes shoot down whole big chunks of the trace cache). There can also be teathing problems on new CPUs. (see comp.arch for disscussions)
Which doesn't mean this will go badly for Intel either. They normally do pretty well with each new CPU introduction. As long as they don't let AMD push them into going too fast, I don't expect problems, but who knows?
The Bell system (in the USA) was never goverment run. There were competing services, one of them convinced the goverment that the competing services would never hook up and interoperate (despite the fact that the services were allready somewhat interconnected, and and more were heading that way). They were granted the right to be the only phone compony (a monopoly). I think this is a simplifacation because GTE might have been allowed to provide phone service as well as Bell Telephone.
The monopoly was not part of the goverment. It was a publicly traded compony. If you don't beleve me get a pre-breakup stock listing and look at the NYSE stock symbol "T" (which is AT and T today). As a publically traded compony it had an obligation to make money for it's stockholders. Were it a part of the goverment it would have had a diffrent mission. As a monopoly it was subject to lots of extra regulation, so the goverment could do things like mandate "universal access", but the Bell System was very not part of goverment. I don't think they would have devloped the 5ESS, or maybe even mechinical pulse switchched calls (the goverment would have been happy to employ many citizens to make the call connections when you lifted the hook and said "Bob Jones in Fairfax please").
The breakup (the Modifyed Final Agreement? Modifyed Final Judgement?) not only tore the Bell System apart, but allowed other componies to compete for phone service (long distance for sure, but local as well, but it just wasn't profitable if you had to string your own wires, so that mostly had to wait for the Telicom Reform Act). If it had been part of the goverment it would have been much harder to turn it into a comperitave compony. Just look at the Post Office!
If I read correctly the processor used a 106k gate fpga.
Not a chance. Those didn't exist in the late 80s/very early 90s. It is a custom gate array (maybe not full custom). I have one in my basement. It might not have 20k gates, it might have 40k. I don't know how to tell from the packaging.
I could beleve that the SPARC in the SPARCStation1 (~15MIPS? ~20? I think 20, I'm almost positave it was a 20Mhz CPU) was 106k gates. Unless it had an on-chip cache, those eat gates like no tommrow (4T or 6T per bit of SRAM is state of the art!).
Remember I'm talking the very first SPARC CPU sun sold outside the labs. Back when $10,000 got you a ~4MIPS VAX. Back before there was a "SPECmark". Back when RISC was "no multiply instruction, branch delay slot, one instruction per cycle, god that's fast!". This was the very second (I think the IBM RT/ROMP made it to market first) RISC CPU in the (Unix Workstation) market.
Still 104k gates can be done on a ~$10 gate array, subject to routing constraints and grouping constraints.
Another CPU I'm pretty sure of the gate count for is the original 68000, roumor has it it used almost eaxactly 68000 gates. So that is also in shooting range for a dirt cheap FPGA. Of corse the 68000 is dirt cheep these days too, the 68000-decendent in the PalmPilot has lots of integrated perphrials (LCD controler, RAM controler, and so on) and it costs under $20 (for the DragonBallEZ; the DragonBallVX in the Palm IIIc is more like just about $30).
Umm.. how about implementing other encryption algorithms. Perhaps of non-US origin? Try GOST from Russia for example.
RSA is a public key algo, one key to encrypt, a diffrent key to decrypt. GOST is a private key algo, on key that can either encrypt or decrypt. If you have a public key algo you can publish your encryption key in a "well known place", and anyone can use it to send messages only you can decrypt (read). With a private key cryptosystem you can not publish the key, anyone that had it could not only send messages, but read them.
To replace RSA in a functional sense you need another public key algo. The only one I know of is a circular arc or some similar thing, "only" discovered within the last decade (five years I think), and not understood by cryptographers well enough to trust all that much. I think GPG can/does use it.
The other problem is that would only be a functional replacment, it won't interoperate with SSL implmentations using RSA. For that only RSA will do. Which can be used outside the USA patent free. In the USA we have to wait until later this year (Septemberish).
P.S. the reason PGP/GPG/SSL uses a public key system plus a private key system is that public key systems are slow and bulky. They greatly expand the size of the data you encrypt with them (like sending a 8-bit value with a 1024bit RSA key gives a 1024bit ciphertext). So they make a random sesison key encrypt it with the public key system, sent it, and send the rest of the message encrypted in the session key using the private key cryptosystem. This give three points of attack, the public key system, the private key system, and the random number gennerator used to make the session keys, so obviously this would be avoided if it could!
Unfortunately, who the heck has the resources to punch out one of these things besides the major chip manufacturers anyway?
For a MicroSPARC? I would guess that you need full custom logic, which isn't that expensave if you are buying tens of thousands of the device. It's suck if you want, say, three.
For the OpenCore CPU? That one is being targeted at FPGAs, which cost a small number of thousands (like two-ish) allready soddered on a PCI bord and ready for love (this would be for the million-gate-ish FPGAs). The "smaller" FPGAs, like 10k to 200k gates are available for way cheep, like under $10 for some of them (with 100k gates even!), very few over $100.
Remember that the first SPARC implmentation was a 20K gate array, it ran at about 10MIPS if the wind was going it's way (Sun 4/110). So you can probbably design a low speed CPU on a $5 FPGA and have room for a USB interface. Spend $40 and you have room for some periphrials too.
Unfortunitly the hard part is the dev tools. Many cost over $100k. I don't know of any Open Source FPGA design tools. Wish I did. I would love to design a non VHDL language!
For FPGA examples and prices look at xilinx. Not sure where to go to look for software pricing.
First, I understand the "paranoid" desire to encrypt everything, everwhere, but I prefer to be realistic. I really don't care if people want to watch everything I do -- it might be a little embarassing, but it's not going to cause nations to fail. That being said...
So why should you subject yourself to the embarasment? Will nations fall if you don't?
Walking into an office and plugging yourself into an ethernet port is "latching oneself into the cable plant."
Ok, but to me that "the cable plant" brings up an image of the wireing rooms, or at least a phone closet. Not the 1000 ethernet jacks scattered two to a cubicle four to an office.
There aren't many offices (relatively speaking) where one could just walk in and plug into the ethernet.
Go to a uniform store and buy a FedEx/UPS/Airborne uniform. You'll be able to get into almost any office. Change into the appropriate attire for the bisness in the bathroom, look like you know what you are doing, go into an empty office (you did find empty ones by looking in the windows didn't you?), or if you are brave cube. If anyone questions you tell them your from Author Anderson, or KPMG.
I havn't done it. But I have friends that do security audits for two diffrent consulting groups, they claim that works at almost every place they have been hired by. They might be yanking my leg, but it sounds plausable to me.
I know where I work I got a temp badge just by knowing the name of an employee (myself), and walking to the security desk and saying I had left mine at home (I had). I bet that'll work a lot of other places as well.
I always made sure conference rooms, and the like, were connected to (monitored) switched ports that were disabled when not in use. I also never let non-employees plug things into non-switched ports -- unless they are bound by an NDA.
Good. With the cost of switches coming down, I would hope most places are doing that. Are the systems inside or outside your firewall? If they guy has an acompless in the garage loged into his laptop can they hack their way through your systems, or is the confrence room totally seprate?
I understand the arguement for one universal solution, but I don't think it should be unconditionally applied.
Why not? If it is then it is much harder for someone to find the conversation you do want private and work on that one. As a matter of habbit I encrypt every login session (either SSH, normally with 3DES, or Kerb5, with whatever it's default is, I expect 56bit single DES, which ain't all that safe, but at least it makes me "not low hanging fruit"). Not just because every login session starts with a password that I want to keep safe (well the Kerb ones don't), but because the middle of the session might have an su, with another password I want safe.
Should every URL begin https://?
Of corse not, that is a lot of extra typing, many billboards and print ads to change. We should just use IPsec:-)
In reality, I would rather have all https then the not-enough-https you see today. Or IPsec, merely because I think longer term it will be easyer to accelarate, and more secure. And more to the point it allows the sender and reciever to decide if they want encryption, auth, or just whatever the other guy wants.
Very little network traffic genuinely deserves to be scrambled.
Who should decide? You? The sender? The reciever?
On one hand, this is pure paranoia. On the other, it's a pointless protest against "The Man" (be that government(s), large corporations, your boss, or that guy down the street who looked at you funny last year.)
Or maybe I just want to solve a problem before it makes front page news for once?
As far as I know nobody has taped any traffic I want private for eight or nine years (I know for a fact it was done to me nine years ago, but it wasn't that big of a deal, they were just trolling for passwords). As far as I know nobody has ever mounted and actiave attack and hijacked a TCP session from me. But I know both things are not hard to do. I would like them made hard to do before the genneral public realises how easy it is.
You can call it paranoia if you like, but for me, I know how easy it is, and I want it harder.
Latching oneself into the cable plant would be far harder than driving through the parking lot with a receiver in the trunk...
"Latching oneself into the cable plant" isn't needed if the office uses hubs. Walk into an office, and use the ethernet jack there. Frequently even the confrence rooms have them. Driving through the parking lot isn't likely to get you much at my office, 802.11 seems to have a hard time escaping the semi-reflectave coating on the windows (which I susspect was put on to make it impossable to get FM radio reception inside!).
However smartass aside, yes, it is simpler to tap into a wirless net then a wired one, at least if you are talking about an office LAN. If you are talking about a Internet connection from home, there are generally wires outside that are fairly easy to tap into (the demark for my T1 may be inside, but it is obvious which wires coming into the house are the T1!). Plus if the tap is being done by the ISP, or the LEC (presumably as the result of a goverment order) it is even easyer then them driving anywhere near the transmiter!
I'm thinking the encryption is not so much to protect the information "end to end" but to protect the "over the air where bad people can hear it without me being able to stop them."
I still think it is much-much-much better to do end-to-end-encryption then just cover one link hop. After all, do you want to solve the problem once and be done with it forever, or do you want to solve it for 802.11, 802.3, HDLC, async-PPP, and on and on for several new network technologies each year? Plus wouldn't it be better to be able to communicate securly from home to work, or your home to your friends home, and not just the last 100 feet of each connection?
Additionally, the wireless traffic is generally going to be "local" traffic.
And only my local traffic needs to be private? I should be worried someone might snoop the MP3's I'm sending to my bedroom, but not care if they see the smut I'm fetching from Australia? Or maybe the research I'm doing on a new drug the HMO doctor wants to put me on? I want it all private. Every bit. Over as many miles of the path as I can get.
don't think there are StrongARMs without MMUs anyway. They don't have a FPU, though.
I donno about StrongARMs, but some of hte ARM9E-S's don't. See http://www.arm.com/Pro+Peripherals/Cores/ARM9ES/ look at the 2nd of the last three tables. No MMU. It's harder to tell with the Intel StrongARMs.
No, QNX does not start taking up space. Have you ever seen their demos?
No I havn't seen their demos. Not the modern ones. I did evaluate it in '92 for use in an embeded system. Had it loaded up and doing stuff. It was much smaller then SunOS was at the time. Much much much smaller. But it was still not tiny when you configured it with a GUI and TCP/IP.
I didn't say it was as big as Linux. I said it was as big as PalmOS. Which is (I think) 2M including a ok datebook, and ok todo list (they should have been integrated together like datebook3, or action-names), memo pad, app launcher, pref tools, the OS, TCP/IP, an IRDA subset, and a bunch of other stuff. This is uncompressed in ROM, and doesn't rely on a system BIOS. So I would guess it is around the same amount of stuff you can fit on a floppy.
And does developer support really matter? Most PDA users won't run command line apps on their PDA, and you're not telling me they tried to shoehorn X into there are you?
Devloper support matters huge. I expect part of why Palm did OK is they had good devloper support (Palm emulator, gdb for the real palm, APIs, gcc for free, and Code Warrier for cheep). I totally admit that X vs. some other (sane) windowing system doens't really matter. I doubt command line apps will be of any use to most PDA users. But a good port of ssh would be nice.
Not much different from QNX, which is a POSIX system and the developers having to learn Photon. QNX is also extremely modular, for most purposes, just as modular as Linux.
You seem to think I hate QNX. I don't. I think it is more moduar then Linux. It has some advantages. Being designed to fit in that space is a big advantage. It has some disadvantages. Cheif among them is closed source -- I won't be able to fix a bug that is irratating me. I have to rely on Samsung or QNX to do it.
I dislike the hype that has people saying "QNX can do a OS and GUI in 32K". Just like I would dislike it if someone said "Linux runs faster on my C=64 then NT4.0 does on my P-III-800". Hype does nobody any good. I like facts.
The hardware gateways are fairly expensive, but simply setting them up peer to peer and using IP Masqing works pretty well.
That will work, but "ad hoc" mode (which is the "no base station" mode) misses out on a few things you get when you have the access-point/basestation thing.
The access-point can hold packets for systems that have going into low-power mode, and only turn on the reciever once every few seconds. This allows greatly reduced battery use (like less then 5% of normal use!) when you arn't doing much with the network. The low-power mode is not used in "ad hoc" mode because you might never get your messages! The low-power mode can be used anytime you have nothing to transmit, and havn't recieved anything for a second or two, so between clicks on a web page you can be saving power.
The access-point can arange to use a RTS/CTS protocall where it tells everyone who gets the "wire" for the next thousand or so bit-times, which greatly reduces the hidden tranmitter* problem, and increses the effectave range (and the bandwidth at longer ranges).
Some funky things also can be done with multiple access points, but I'm not quite sure what they are. I think they end up just being able to bridge together multiple wireless nets, which isn't a big deal if you are ok with changing your IP address when you roam from one net to another. This is probbably a non-issue in a normal sized house, but could be a big deal in a reasonable sized office building (we need two access points per floor).
So if you are using unpluged laptops, a base station will can increse your battery life. If you have problems getting the range you want a base station can help that too.
* The hidden transmitter is where you have, say, three machines, A, B, and C. A can hear B but not C, C and hear B but not A, and B can hear both. If A and C both talk they don't hear each other, so they won't do the ehternet I-heard-a-collision-while-I-was-talking-so-I'll-ba ck-off thing. B will hear both messages, but they will damage each other, so all B will realy hear is a really long collison. With an access point (either where B is, or close by) it will mediate A and C's demands to talk. The RTS (request to send) is a ver short message so the chances of collisons when sending them is quite low. There is a slight increse in latency this way.
With the proliferation of wireless devices like this, it seems to be more important than ever to make sure that we aren't sending unencrypted packets between machines.
Does the 802.11 spec cover this, or is it just a connectivity protocol for wireless devices (I assume the latter)
802.11 has a encryption spec for it (I think the original "Wire Equivolent Privicy" had a 4-bit RC4 -- which is about worthless, thw Lucent Gold cards advertise a 128bit crypto, so I guess it got better).
However I don't think that is the right way to fix the problem. After all if you transmit important data and it is encrypted over 802.11, but unencrypted out the cable plant, across the global backbone, and off to wherever you sent it, you have only fixed about 100 feet worth of a (possabbly) multi-thousand mile problem.
Can somebody provide some pointers to IP-level cryptography? I'll be wanting to go with an in-home set up like this in the near future but I really chafe at the idea of how trivially easy it would be for people to sniff my packets. I realize that encryption is easily built into higher-level protocols, but I really like the idea of minimum disclosure to eavesdroppers, particularly for signals that otherwise wouldn't even leave my home (not everything is outbound to the ISP, you know).
Exactly! Try looking at IPSEC, it is required for IPv6, and optional for IPv4. You could also just try to tunnel everything through SSH.
When you hear about something like this, you really have to ask yourself, is it practical? Linux is a UNIX. No matter how slimmed down, it still carries a lot of UNIX baggage.
No, Linux has a lot of new Unix baggage. Remember Unix was devloped on a machine with 40K words (I think 80K bytes) of memory. It has grown quite a bit over the years, but don't make the mistake of thinking Unix == big-bloated-OS.
Now, I expect even a trimmed down Linux to take a lot more space then PalmOS, and it looks like the Samsung PDA hasn't learned the lessons of Palm, so the apps may not be what you want, and that start button definitly isn't as nice as a full screen launcher plus a few buttons for extramly common programs.
...QNX. The kernel is 32K, includeds networking, and Photon is really small and fast.
The QNX kenrnel is indeed very small. However the 32K kernel includes context switching, semaphores, and (non-network) nessage passing. No TCP/IP, no GUI, no filesystem, no serial ports, no way to talk to a user at all. Once you add the same sort of things PalmOS has QNX starts taking up real space.
It seems to me that Palm, GeOS, and Netwon are the only ones who ever "got it."
As a former Nokia9000 owner (GeOS PDA/phone), I have to say GeOS wasn't bad there, but the Palm was much better. Of corse GeOS started off as a desktop platform, so if they can make the transition, why can't Linux?
P.S. the sukyest thing about the Palm is that a buggy app can not only crash the whole machine, it can destroy data (since it is all in RAM, and there is no MMU). Hopefully the ARM Samsung chose has a MMU, and they use it.
Slashdot Mirror
I agree that the 33Mhz 32bit PCI bus can be a limitation for some things, like trying to push a gigabit ethernet at a gigabit. I don't see this as the big problem in PC class machines just yet. Maybe in two years or so.
First off you can get 66Mhz 64bit (or maybe just 33Mhz 64bit) PCI slots in motherbords that cost under $300. That is 2x or 4x the bandwidth. So if 33Mhz 32bit PCI is a "little limiting", 66Mhz 64bit PCI should have a lot of head room.
Secondly, there are very very few things you hook up to a machine that push past the PCI bandwidth (the gigabit ethernet being on of the few, an extreamly fast RAID controler being another, and it is only a little past the 33Mhz 32bit PCI bandwidth). So you need a case where you push multiple devices to their limit before PCI is the limiting factor (like I want to read off my massave disk array and send it out these two GE ports...). (3D video cards being a modest execption, because they allready have their own "bus")
Thirdly, and more important, it is main memory that is the bottleneck for most things. It has been for over a decade. It isn't getting better (main memory is getting faster, but not as fast as CPUs are).
From a technical point of view what is wrong with RAMbus? It is 1992 technology that was great then, and great for five years after. The compony that invented it charged too much for patent rights, never managed to hit the mass market, didn't get to drive costs down, and in the end didn't make enough money to plow it back into research to keep up with the entire rest of the world. But that isn't a technological problem, it is an econmic one. More importnatly RAMbus is extreamly intresting.
Plus if you want bandwith, and a little latency is Ok RAMBus kicks ass. Unfortunitly bandwith isn't really as useful as low latency for most applications, and at RAMBus's current price it is cheeper to build very wide normal memorys.
Oh, and RAMBus and PCI don't play in the same space. One is a memory system, the other is a perphrial system. It is like saying "Volvo's T5 engine is out dated, they should devlop something like the VW transmition!".
They did make something like the SBus. It is called PCI. On paper it uses the same FCode (in practice is normally uses Intel x86 assembly). It has vender and device IDs. It has auto config. It is fast (the SBus is 32bits at about 25Mhz, slightly slower then the PCI bus). PCI abandoned the SBus form factor. PCI abondened using strings for dev/manuf IDs. PCI dropped the IOMMU (which was re-invented for AGP as "Intel's innovatave new DIME"). But PCI is relitavly similar, and being designed afterwords it is even somewhat better in some ways.
Sun has dropped the SBus over the last few (3?) years. They are using PCI. Not just in the low end "PC priced" machines, but even their most expensave machines use PCI for perphrials (they use their own thing for memory and CPU boards, no big supprise).
I'm afarid you are wrong. The SBus is indeed a bus. many high end SPARC systems had multiple SBus's hooked up over what may have been a point-to-point controler (like the FHB), but i think that was just a bigger bus. Existing high end SPARCs hook backplane bords up over a point to point system, some backplane bords have CPU, others PCI busses, others memory. SGI does the same thing.
You may be thinking of Intel's NGIO (Next Gen I/O), or the Cisco/20others Future-something-or-oither. Both are extreamly fast serial-ish point to point systems that could have a fast non-blocking switch at the center. NGIO has been "in the works" since like 1995. Not sure when the other started, or when we will see anything.
The benchmark makes a big deal of the slow L2 cache. It doesn't mention that the L1 cache is 128K, quite a bit larger then the P-III L1 cache (which I think is 32K). So when the Athalon gets the faster L2 cache, while I have no doubt it will help a great deal, it won't help as much as, say going from no cache on the Celeron to a 128K cache.
The P-III also has a much lower latency to it's small L1 cache, and to it's decent sized L2 cache. That can make a big diffrence for anything that chaces pointers down a linked list, or any other extreamly latency sensitave application.
All that siad, I really like the Athalon, it is a good value for the money. My new Unix box sitting next to my desk here is an Athalon (only 650Mhz, I figure I'll pick up a DP system later in the year if I'm lucky).
As far as I can tell, nothing. The motherboard the air-cooled 1Ghz part ran in has a better chipset (the KX133). If you look at page 3 air cooled part is shown with the KX133, and 256M of PC133 memory. If you happen to magically know what the Kyrotech part is (the benchmark didn't say) it is one of the old AMD750/751 baised motherboards, like the second set of systems. It doens't support PC100 memory, and it had may not have supported the PC100 memory as well as it could (many 750s can't use "Super Bypass" mode, which as far as I can tell is a way to skip 75% of the latency in the common case, without getting the wrong answer sometimes).
In other words this is kind of a lame CPU benchmark since the systems were not made as similar as possable. It is a fine system benchmark, since you won't get the Kyrotech in any other motherboard. You probbaly wouldn't want to put a new AMD in a non KX133 system. Still the totally diffrent hard drives and sound cards and stuff, and diffrent amounts of memory arn't a good idea to get a isolate component test! Maybe not even for the system test (what gamer would spend over $1000 on a CPU, and stick with crappy 2 chanel on the motherboard sound chip?)
That might be cheeper. But won't a limited size operation have a limited number of people who can fix the problem? What if they are home sleeping? Or home sick? If all you have is the keybord/vid switch you either
For a big operation, it may only be the diffrence between the on duty person running form their desk to the right machine room, finding the crash cart and draging it to the right spot vs typing "console machine-name". Call it five to ten minutes. A big operation can lose a lot of money with five to ten extra minutes of down time.
The Sun allready has a great serial console. It can hard-reset the system. It can be told to boot off a diffrent disk controler. It can be told to boot off the same disk controler, but a diffrent disk (which no PC serial port re-director I have ever seen lets you!). It can let you boot off the distro CD and reformat the hard drive and re-install from scratch, all while the machine is sitting in a telco closet 300 miles from your closest employee. The Mac uses the same OpenFirmware base stuff, so I would hope it has retained this as well, but I have no direct knolage, nor really high hopes that Apple kept that bit of non-graphical greatness.
Another nice feature of a serial console vs. a switcher is you can run all the lines into a program that does logging, allows interactiave logins, and watches the log for anything an operator might need to look into "panic" "PAIRTY" and the like. You can get notice of a failure before sombody calls you, or before you next monitoring sweep. You can also get some log to analise, rather then thinking the new Froon2000 motherboard is a bit more flakey then the Froon1000 you can examine a months logs and get a fialure rate. Hard data is better then a vague feeling.
My question is does this gizmo let me bypass a damaged boot image and use my "spare" boot drive (or CD) so I can do a re-install? That would be kinda tough since it isn't the disk controler.
Of corse free market capitalism regularly produces unsound results. The free market doesn't find global optima, it finds local optima. As far as I know it is the most efficent process known to find local econmic optmia. The only one in fact. There is no known way to find econmic global optima.
You can look at the local optmia that the free market does find, and imagine a better end result, but nobody has shown a process that finds that result for you! Certonally no econ text I have read talks about one. Certonally no non-free market economy seems to be doing better then the mostly-free-merket economies of the world. (I don't know any country that uses a total free market economy, but many are "close enough")
Raises hand. I've never run napster. I'm pretty sure the only tracks I have downloaded (using ftp, or rcp, or Netscape) that I don't own the CD of are from two CDs that arn't available in the USA (plus stuff from MP3.com). One I have on order, but Wax Tracks keeps pusing the US release data back The other is H2SO4's Imatation Leather Jacket (I think). I havn't been able to find it anywhere.
I even spent about $200 buying all the import singles of my faverote band just so I didn't have to steal them.
More intrestingly, my avg. spending on CDs from 1993 to 1998 was about $0. In 1999 I spent at least $500 on them. (all from listening to a legal CD archive at work, and partly because my new car has a CD player)
But I havn't seen anything about a MMU on the PSX2. If it doesn't have one you won't get a normal Linux to run on it. You will need to port uLinux or whatever the Linux varient that doesn't have memory protection, and has either a relocator, or requires PIC code.
Doing that will substantally reduce the stability of Linux (or any OS), as errors in one program can easally damage another program.
Personally I think it is very possable that Sony will have left an MMU out. MMUs are of modest complexity, and tend to add a big chunk of work right in the LOAD/STORE pipeline where modern CPUs are striving for minimal extra cruft to reduce memory latency. They arn't needed in a game machine. They arn't needed in a DVD player. They arn't needed anywhere there is only one task going on and you can basically reboot into the next task. It is possable they were farsighted enough to decide that if they want to be a "PC killer" a MMU could have been useful, but I wouldn't bet any money on it.
P.S. the Dreamcast has an MMU because WinCE wants a MMU, and Sega wanted WinCE, in case it took off. That's why it can run a relitavly normal NetBSD or Linux port (I don't know of a Linux port, there was a BSD port of some sort).
I havn't given a large gift check beofre, but I know banks like you to use certified checks for any thing. Sometimes they get the charge a direct fee for cert. checks. Other times they win just by getting the "float" on the money. A cert. check actually moves the money from your (I assume) intrest bearing account into the banks's account (where they get the intrest) as soon as issued. So they love it when you pay for big ticket items like homes that way.
The seller likes cert. checks because they don't bounce for lack of sufficent funds, and the issuer can't put a stop payment on them (at least not normally). It is generally a requiremnt when you buy a home. Sometimes for used cars. It wasn't for any of the new cars I have bought.
As far as writing a $20,000 check to the "Linux Router Project", I don't see what eyebrows at a bank that will raise. They have no idea it is a gift. They probbably susspect you are buying a woodworking shop.
Indeed. However they can't issue cert. checks. They can route the money around, and advise you on whetehr you are better off cutting a normal check and not getting intrest on it durring the "settiling period", or paying evtra for the wire transfer which lets you get a few extra days of intrest.
They also may advise you to invest the $20k and make a fund that pays out $1k a year to your favored project (not all that likely for a "mere" $20k, but for $100k or more that could be the way to go).
According to the ninth circuit court you have the legal right to load a MP3 of a copyright song that you own on CD. I remember reading that off a link from slashdot, but couldn't find it in slashdot's search, but here is a diffrent summary http://www.nylj.com/tech/091399t3.html, unfortunitly it doesn't really discuss space shifting. As I recall the judge essensally ruled that owning the CD was like owning a "right to use", so owning Ray of Light on CD gave you the right to listen to it in MP3 or other forms. He went on to rule that it didn't matter if you gained the other form from a source that wasn't allowed to listen to it (which I found supprising). I wish I had kept a link to the ruling. Does anyone have one?
MP3.com's "BeamIt" relys on this ruling (as far as I can tell).
So you can't just point to the large number of copyrighted works in Napaster's list, you have to show that the people downloading the songs don't have the legal right to do so!
At the University of Maryland we wrote an extreamly primitave OS (no filesystem, no memory protection, but it had a text mode windowing system!). We did it from the raw hardware, so it was pretty damm chalanging. You learn a lot of things that way (like how to really write intrrupt handlers, not how to use someone else's framework!).
I think there is a lot of merit in that approch. It was the only class at UofM where we touched bare metal (the assembly class was close though). I think it is important that CS students do that at least once.
I also think students could benifit from doing larger things to an existing OS. But as a diffrent class. I would focus not on things Linux needs, but things the students could learn from. Like putting in a fixed-priority scheduler, and then testing for priority inversion, and finding a way to fix that. Maybe adding a batch scheduler. Writing a driver for a simple piece of hardware (like the serial port). Maybe something slighlty more complex, like something that DMAs. Maybe an IDE controler driver. Sound cards would be better then IDE controlers, except that would be a pain in a lab enviroment, and the hardware changes from year to year.
I know none of this would directly benifit the Linux comunity, but it would greatly benifit the students. Remember it is easyer to grade a project with a known outcome then something open ended! It is also easyer for the TAs to advise students on smaller projects with known results. The students will gain some first hand knolage of formerly abstract concepts, and some knolage of Linux internals.
Really? What bank? What recipent? I have been told banks get fussy about large cash withdraws, but I don't think that is the case for checks! I have written a check for my townhouse, then later my house, and a car even. All of which were bigger then US$20k. Never saw anyone having a fit. Also a few tax checks, but somone had a fit there. Me.
IBM is pretty sure 4Ghz is doable in the next two years by doing multiple independent clocks with async buffering between them. Slashdot ran something about that within the last month or so.
I don't know how fast CPUs can really get, but clock speed isn't the only factor. Work done per cycle is also important. If you look at today's (desktop/workstation) CPUs they all can execute more then one instruction per cycle. Two is a minimum. Three is the sustained max for Intel/AMD. Some RISC CPUs can do 5 instructions (UltraSPARC) if they are just the right set. This rarely happens, so most of hte time your two/three/five banger is executing zero (waiting for main memory), or one (too many read-after-write hazards) instruction. Transmeta is trying to fix this by making the (emulated) CPU really smart. The Alpha is trying to fix this by executing instrctions from more then one process at the same time (i.e. an ADD and MUL from your MP3 player, a LOAD and FMUL for your Quake server, and a STORE and a CMP for the re-compile of your Linux kernel). Compaq's simulations say this is really the shit. In two years I guess we will be able to see if it is. (the idea isn't new, the Terra supercomputer does something similar, and barrel processors have been doing something similar for decades).
As for 1Ghz being unthinkable four years ago, I assure you the design cycle for CPUs is long enough that the team that built the Athalon was almost certonally thinking of it. About eight years ago the Alpha archature manual was talking about it. Seven years I would have taken a bet that the Alpha would be the first "desktop" CPU to hit it. Apparently later this month I can be thankful nobody took me up on it. :-)
I have a 200Mhz machine at work, and a 266Mhz at work. Both do nicely for a lot of tasks. I bought a new machine to ray trace on (you could give me a million 1Ghz machines and I could still use more CPU to raytrace on...well maybe not me, but a real artest I guess). Neither do well for modern games, which seem to be a big driver for fast desktop CPUs. My C++ compiler could use a faster CPU too, which is why I don't do compiles on my 200Mhz box at work.
A fast desktop machine doesn't have the I/O of an oldish supercomputer. It does have a faster CPU. It's CPU is even competitave with modern supercomputers (sometimes it shares the CPU!). It's memory system and I/O is staggeringly far behind. Then again so is it's microscopic price tag.
So a fast desktop is good for anything that can get away with less memory, slower memory, and slower I/O, and just pain can't afford a supercomputer.
Since supercomputers are staggeringly expensave, I would guess lots of stuff "makes do" with desktop CPUs. Off the top of my head I would say:
I assume the "increasing the length of the pipeline" is Intel's Wilmate (or whatever they call it). That is a totally new core. You don't double the pipeline length, slap on trace cache, and slip a 3Ghz ALU into an existing CPU. It is a totally new beast.
Of corse new doesn't mean better. It will be hell on self-modifying code, and it may not even tolarate code that has read-only data on the same page as code! (the new CPU doesn't allow the DTLB and ITLB to map the same page, there is speculation that DTLB entryes shoot down whole big chunks of the trace cache). There can also be teathing problems on new CPUs. (see comp.arch for disscussions)
Which doesn't mean this will go badly for Intel either. They normally do pretty well with each new CPU introduction. As long as they don't let AMD push them into going too fast, I don't expect problems, but who knows?
The Bell system (in the USA) was never goverment run. There were competing services, one of them convinced the goverment that the competing services would never hook up and interoperate (despite the fact that the services were allready somewhat interconnected, and and more were heading that way). They were granted the right to be the only phone compony (a monopoly). I think this is a simplifacation because GTE might have been allowed to provide phone service as well as Bell Telephone.
The monopoly was not part of the goverment. It was a publicly traded compony. If you don't beleve me get a pre-breakup stock listing and look at the NYSE stock symbol "T" (which is AT and T today). As a publically traded compony it had an obligation to make money for it's stockholders. Were it a part of the goverment it would have had a diffrent mission. As a monopoly it was subject to lots of extra regulation, so the goverment could do things like mandate "universal access", but the Bell System was very not part of goverment. I don't think they would have devloped the 5ESS, or maybe even mechinical pulse switchched calls (the goverment would have been happy to employ many citizens to make the call connections when you lifted the hook and said "Bob Jones in Fairfax please").
The breakup (the Modifyed Final Agreement? Modifyed Final Judgement?) not only tore the Bell System apart, but allowed other componies to compete for phone service (long distance for sure, but local as well, but it just wasn't profitable if you had to string your own wires, so that mostly had to wait for the Telicom Reform Act). If it had been part of the goverment it would have been much harder to turn it into a comperitave compony. Just look at the Post Office!
D'oh! Sorry.
Not a chance. Those didn't exist in the late 80s/very early 90s. It is a custom gate array (maybe not full custom). I have one in my basement. It might not have 20k gates, it might have 40k. I don't know how to tell from the packaging.
I could beleve that the SPARC in the SPARCStation1 (~15MIPS? ~20? I think 20, I'm almost positave it was a 20Mhz CPU) was 106k gates. Unless it had an on-chip cache, those eat gates like no tommrow (4T or 6T per bit of SRAM is state of the art!).
Remember I'm talking the very first SPARC CPU sun sold outside the labs. Back when $10,000 got you a ~4MIPS VAX. Back before there was a "SPECmark". Back when RISC was "no multiply instruction, branch delay slot, one instruction per cycle, god that's fast!". This was the very second (I think the IBM RT/ROMP made it to market first) RISC CPU in the (Unix Workstation) market.
Still 104k gates can be done on a ~$10 gate array, subject to routing constraints and grouping constraints.
Another CPU I'm pretty sure of the gate count for is the original 68000, roumor has it it used almost eaxactly 68000 gates. So that is also in shooting range for a dirt cheap FPGA. Of corse the 68000 is dirt cheep these days too, the 68000-decendent in the PalmPilot has lots of integrated perphrials (LCD controler, RAM controler, and so on) and it costs under $20 (for the DragonBallEZ; the DragonBallVX in the Palm IIIc is more like just about $30).
RSA is a public key algo, one key to encrypt, a diffrent key to decrypt. GOST is a private key algo, on key that can either encrypt or decrypt. If you have a public key algo you can publish your encryption key in a "well known place", and anyone can use it to send messages only you can decrypt (read). With a private key cryptosystem you can not publish the key, anyone that had it could not only send messages, but read them.
To replace RSA in a functional sense you need another public key algo. The only one I know of is a circular arc or some similar thing, "only" discovered within the last decade (five years I think), and not understood by cryptographers well enough to trust all that much. I think GPG can/does use it.
The other problem is that would only be a functional replacment, it won't interoperate with SSL implmentations using RSA. For that only RSA will do. Which can be used outside the USA patent free. In the USA we have to wait until later this year (Septemberish).
P.S. the reason PGP/GPG/SSL uses a public key system plus a private key system is that public key systems are slow and bulky. They greatly expand the size of the data you encrypt with them (like sending a 8-bit value with a 1024bit RSA key gives a 1024bit ciphertext). So they make a random sesison key encrypt it with the public key system, sent it, and send the rest of the message encrypted in the session key using the private key cryptosystem. This give three points of attack, the public key system, the private key system, and the random number gennerator used to make the session keys, so obviously this would be avoided if it could!
For a MicroSPARC? I would guess that you need full custom logic, which isn't that expensave if you are buying tens of thousands of the device. It's suck if you want, say, three.
For the OpenCore CPU? That one is being targeted at FPGAs, which cost a small number of thousands (like two-ish) allready soddered on a PCI bord and ready for love (this would be for the million-gate-ish FPGAs). The "smaller" FPGAs, like 10k to 200k gates are available for way cheep, like under $10 for some of them (with 100k gates even!), very few over $100.
Remember that the first SPARC implmentation was a 20K gate array, it ran at about 10MIPS if the wind was going it's way (Sun 4/110). So you can probbably design a low speed CPU on a $5 FPGA and have room for a USB interface. Spend $40 and you have room for some periphrials too.
Unfortunitly the hard part is the dev tools. Many cost over $100k. I don't know of any Open Source FPGA design tools. Wish I did. I would love to design a non VHDL language!
For FPGA examples and prices look at xilinx. Not sure where to go to look for software pricing.
So why should you subject yourself to the embarasment? Will nations fall if you don't?
Ok, but to me that "the cable plant" brings up an image of the wireing rooms, or at least a phone closet. Not the 1000 ethernet jacks scattered two to a cubicle four to an office.
Go to a uniform store and buy a FedEx/UPS/Airborne uniform. You'll be able to get into almost any office. Change into the appropriate attire for the bisness in the bathroom, look like you know what you are doing, go into an empty office (you did find empty ones by looking in the windows didn't you?), or if you are brave cube. If anyone questions you tell them your from Author Anderson, or KPMG.
I havn't done it. But I have friends that do security audits for two diffrent consulting groups, they claim that works at almost every place they have been hired by. They might be yanking my leg, but it sounds plausable to me.
I know where I work I got a temp badge just by knowing the name of an employee (myself), and walking to the security desk and saying I had left mine at home (I had). I bet that'll work a lot of other places as well.
Good. With the cost of switches coming down, I would hope most places are doing that. Are the systems inside or outside your firewall? If they guy has an acompless in the garage loged into his laptop can they hack their way through your systems, or is the confrence room totally seprate?
Why not? If it is then it is much harder for someone to find the conversation you do want private and work on that one. As a matter of habbit I encrypt every login session (either SSH, normally with 3DES, or Kerb5, with whatever it's default is, I expect 56bit single DES, which ain't all that safe, but at least it makes me "not low hanging fruit"). Not just because every login session starts with a password that I want to keep safe (well the Kerb ones don't), but because the middle of the session might have an su, with another password I want safe.
Of corse not, that is a lot of extra typing, many billboards and print ads to change. We should just use IPsec :-)
In reality, I would rather have all https then the not-enough-https you see today. Or IPsec, merely because I think longer term it will be easyer to accelarate, and more secure. And more to the point it allows the sender and reciever to decide if they want encryption, auth, or just whatever the other guy wants.
Who should decide? You? The sender? The reciever?
Or maybe I just want to solve a problem before it makes front page news for once?
As far as I know nobody has taped any traffic I want private for eight or nine years (I know for a fact it was done to me nine years ago, but it wasn't that big of a deal, they were just trolling for passwords). As far as I know nobody has ever mounted and actiave attack and hijacked a TCP session from me. But I know both things are not hard to do. I would like them made hard to do before the genneral public realises how easy it is.
You can call it paranoia if you like, but for me, I know how easy it is, and I want it harder.
"Latching oneself into the cable plant" isn't needed if the office uses hubs. Walk into an office, and use the ethernet jack there. Frequently even the confrence rooms have them. Driving through the parking lot isn't likely to get you much at my office, 802.11 seems to have a hard time escaping the semi-reflectave coating on the windows (which I susspect was put on to make it impossable to get FM radio reception inside!).
However smartass aside, yes, it is simpler to tap into a wirless net then a wired one, at least if you are talking about an office LAN. If you are talking about a Internet connection from home, there are generally wires outside that are fairly easy to tap into (the demark for my T1 may be inside, but it is obvious which wires coming into the house are the T1!). Plus if the tap is being done by the ISP, or the LEC (presumably as the result of a goverment order) it is even easyer then them driving anywhere near the transmiter!
I still think it is much-much-much better to do end-to-end-encryption then just cover one link hop. After all, do you want to solve the problem once and be done with it forever, or do you want to solve it for 802.11, 802.3, HDLC, async-PPP, and on and on for several new network technologies each year? Plus wouldn't it be better to be able to communicate securly from home to work, or your home to your friends home, and not just the last 100 feet of each connection?
And only my local traffic needs to be private? I should be worried someone might snoop the MP3's I'm sending to my bedroom, but not care if they see the smut I'm fetching from Australia? Or maybe the research I'm doing on a new drug the HMO doctor wants to put me on? I want it all private. Every bit. Over as many miles of the path as I can get.
I donno about StrongARMs, but some of hte ARM9E-S's don't. See http://www.arm.com/Pro+Peripherals/Cores/ARM9ES/ look at the 2nd of the last three tables. No MMU. It's harder to tell with the Intel StrongARMs.
No I havn't seen their demos. Not the modern ones. I did evaluate it in '92 for use in an embeded system. Had it loaded up and doing stuff. It was much smaller then SunOS was at the time. Much much much smaller. But it was still not tiny when you configured it with a GUI and TCP/IP.
I didn't say it was as big as Linux. I said it was as big as PalmOS. Which is (I think) 2M including a ok datebook, and ok todo list (they should have been integrated together like datebook3, or action-names), memo pad, app launcher, pref tools, the OS, TCP/IP, an IRDA subset, and a bunch of other stuff. This is uncompressed in ROM, and doesn't rely on a system BIOS. So I would guess it is around the same amount of stuff you can fit on a floppy.
Devloper support matters huge. I expect part of why Palm did OK is they had good devloper support (Palm emulator, gdb for the real palm, APIs, gcc for free, and Code Warrier for cheep). I totally admit that X vs. some other (sane) windowing system doens't really matter. I doubt command line apps will be of any use to most PDA users. But a good port of ssh would be nice.
You seem to think I hate QNX. I don't. I think it is more moduar then Linux. It has some advantages. Being designed to fit in that space is a big advantage. It has some disadvantages. Cheif among them is closed source -- I won't be able to fix a bug that is irratating me. I have to rely on Samsung or QNX to do it.
I dislike the hype that has people saying "QNX can do a OS and GUI in 32K". Just like I would dislike it if someone said "Linux runs faster on my C=64 then NT4.0 does on my P-III-800". Hype does nobody any good. I like facts.
That will work, but "ad hoc" mode (which is the "no base station" mode) misses out on a few things you get when you have the access-point/basestation thing.
So if you are using unpluged laptops, a base station will can increse your battery life. If you have problems getting the range you want a base station can help that too.
a ck-off thing. B will hear both messages, but they will damage each other, so all B will realy hear is a really long collison. With an access point (either where B is, or close by) it will mediate A and C's demands to talk. The RTS (request to send) is a ver short message so the chances of collisons when sending them is quite low. There is a slight increse in latency this way.
* The hidden transmitter is where you have, say, three machines, A, B, and C. A can hear B but not C, C and hear B but not A, and B can hear both. If A and C both talk they don't hear each other, so they won't do the ehternet I-heard-a-collision-while-I-was-talking-so-I'll-b
802.11 has a encryption spec for it (I think the original "Wire Equivolent Privicy" had a 4-bit RC4 -- which is about worthless, thw Lucent Gold cards advertise a 128bit crypto, so I guess it got better).
However I don't think that is the right way to fix the problem. After all if you transmit important data and it is encrypted over 802.11, but unencrypted out the cable plant, across the global backbone, and off to wherever you sent it, you have only fixed about 100 feet worth of a (possabbly) multi-thousand mile problem.
Exactly! Try looking at IPSEC, it is required for IPv6, and optional for IPv4. You could also just try to tunnel everything through SSH.
No, Linux has a lot of new Unix baggage. Remember Unix was devloped on a machine with 40K words (I think 80K bytes) of memory. It has grown quite a bit over the years, but don't make the mistake of thinking Unix == big-bloated-OS.
Now, I expect even a trimmed down Linux to take a lot more space then PalmOS, and it looks like the Samsung PDA hasn't learned the lessons of Palm, so the apps may not be what you want, and that start button definitly isn't as nice as a full screen launcher plus a few buttons for extramly common programs.
The QNX kenrnel is indeed very small. However the 32K kernel includes context switching, semaphores, and (non-network) nessage passing. No TCP/IP, no GUI, no filesystem, no serial ports, no way to talk to a user at all. Once you add the same sort of things PalmOS has QNX starts taking up real space.
As a former Nokia9000 owner (GeOS PDA/phone), I have to say GeOS wasn't bad there, but the Palm was much better. Of corse GeOS started off as a desktop platform, so if they can make the transition, why can't Linux?
P.S. the sukyest thing about the Palm is that a buggy app can not only crash the whole machine, it can destroy data (since it is all in RAM, and there is no MMU). Hopefully the ARM Samsung chose has a MMU, and they use it.