From my read of the GSM spec (a friend bought me the huge expensave book for Christmas one year...) the update timer is way shorter then hours.
More importantly from putting my 1900Mhz-GSMish phone near my computer speakers I heard transmit bursts from it multiple times an hour. Also just after it was turned off (as in I press off, the backlight turns on, it says "powering down", screen goes blank and THEN "blip-blip-blip").
Beats me how ofen CDMA phones transmit (I know they do handset assisted cell handoff, so they will transmit quite a bit when they are close to a cell boundry). I havn't read the spec, and I havn't noticed any interference from the phone yet (I switched when the provider in my areaa ditched GSM@1900Mhz to go with CDMA@1900Mhz, which has been providing me with fewer services, but doing them just as well, for moer money, what a bargin!)
Motorola first "went RISC" with the 88000. I forget whether they pitched the 88000 to Sun, but Sun didn't bite - they rolled their own, SPARC.
What actually happend was Andy Bechlstien (and others) at Sun read a lot of the academic papers about RISC (possabbly before it got that name), specifically the SAIL and a few other CPUs. They told Motorola that there was definitate comercial intrest from Sun.
Motorola in effect blew them off (Sun was a largeish buyer of 680x0s, but not the same kind of volume as many of mot's other customers).
Sun partnered with (I think) Fujtsu to build the first SPARC on a 20K gate-array (the original 68000 was a 68K gate full custom job, so the SPARC was really quite impressave). That ran around 15Mhz to 20Mhz (the 68020 ran 20Mhz to 33Mhz at the time), but it got far more work done per cycle. The result was a $10,000 "12MIPS" machine (Sun4/110) as opposed to the $10,000 "4MIPS" machine the 68020 powered (3/150, or the slightly slower 3/60, or lots of 3/numbers-here machines).
Mot started a crash program to devlop the "88k", which DG eventually used for some ill-fated Unix workstations (The AvIlon i think). They may have started the program before Sun brought the SPARC out, because IBM managed to market a RISC baised machine before Sun's SPARC got out the door (About "6 MIPS", the IBM RT). That CPU had actually been around internal to IBM for a number of years, but never turned into a computer product (I think it came out of hte typewriter labs).
The 88k never really got any signifigant market share. Even upstart MIPSco got more market share (in part because DIGITAL was cought by Sun -- Sun's boxes were TEN times faster for the same money until DIGITAL droped their internal titan project, and brought out some nice MIPS R2000 and R3000 baised machines, total design to market time of about 8 months, incredable work, and the R3000s were slightly faster then the SPARC, at least for a little bit).
Then a whole bunch more stuff hapened:
eventually some big complicated Apple-IBM-Mot deal created the PowerPC which failed to crush the world, but has managed to capture decent market share.
DIGITAL droped the MIPSs in favor of their own quite nice Alpha, which despite being far ahead of every other CPU for many years (or at least bing allways in the top 3, and normally in the top one for FP perfomance, and in the top 5 for integer performance)...um...where was I, oh yes, the Alpha also failed to crush the world. Then again the world has repeatdly failed to crush the Alpha, so i guess they are even.
HP's PA showed up and battled the Alpha for a long time, frequently having the number one spot for weeks at a time. Even months sometimes. It seems to have withered a bit in the past year or two.
The death of RISC has benn predected several times. As has the death of CISC.
Intel brought out a pretty cool RISc CPU, the i860, which went in a OkiData Unix workstation, and then faded pretty much from existance
Lot of other stuff that I forgot, didn't know, or don't think is important
I mostly agree. Here are my few points of contention:
A CPU bound process in user space, like POVray isn't at a mesurably diffrent speed from a in-kernel "process", because it makes almost no U<->K transitions.
The Cursoe makes the DragonBall look anemic in terms of performance. It is about 20 times faster then the DragonBallVX. However it is also 15 times the price, and fails to include a LCD controler, and many of the other intgrated components on the DragonBall. Then again the ColdFire has been able to exevute (almost exactly) the same instruction set as the DragonBall at 200Mhz, and it costs more like $50.
It can execute x86 code. Great, we have tons of x86 code that needs executing. In thery it could execute PowerPC or SPARC code as well (as long as doing the FP internally at 80bits, and having a MMU with x86-style page attributes doesn't get in the way too much, oh, and remember it will probbably have to be a 32bit SPARC or PPC, but a very fast one). In practice we have no idea if we will see anything other then the x86 morphing engine. It would have been nice to have a more sane ISA in addtion to the x86 one. There is no reason it would have to be the natiave VLIW one (and in fact the natiave VLIW one seems like a bad idea, as it is totally not what comercial compilers are good at targeting, and differes between all of Transmetas current products).
You say you can get a 1Ghz K7, but it is hamstrung by the RAM, drive, and other parts. Well, for some things, yes, totally. for other things you get good cache use, and your only bottleneck is RAM access speed. Weather prediction, Raytracing, Bruteforce crypto keyspace search, maybe SETTI@Home. And the RAM thing is getting better all the time (in part just by incresing the size and number of levels in the CPU cache system).
If you use your modifications only internally, I you aren't required to release the source to them. That clause only applies if you distribute the code.
I have heard that about GPL a lot. I'm not sure it is really true. I want to try a thought exparament.
Let's say FOOcorp takes a GPLed product and uses it "in house". Let's say I work for FOOcorp. One day I leave FOOcorp. Doesn't the GPL says I am entitled to a copy of the source if I want to pay reasonable copying costs?
I mean there is nothing in the GPL that excepts emploies, nor does it say you currently need a binary copy to have the rights granted to you by the licence.
When was the last time you played a CD (music) on your Sony PlayStation?
My wife use to all the time. After I got the DVD player she still did, because the PSX's crappy CD interface was better thent he really crappy one on the DVD (to be honest the DVD one works with the TV off, the PSX doesn't, and it may have been because she was use to the PSX one).
She doens't anymore because I had to take back that S-Video input jack away from the PSX and give it to the dreamcast.
If you want it, then start it up. If you cannot get enough people interested in it, then forget it.
Keep in mind that if you yourself can program "enough people" is one. Many great projects start that way. Many more then having someone map out a great plan and then look for someone else to code it up. So if you have a Great Idea, and can't intrest others, go out and buy a good book on programming, dig in. Be the next Linus. The world over can mispronunce your name too!
To sum up, maybe someone can give me a opinion on a good "Starter C++" platform:
I would have to say GTK-- (a C++ wraper for GTK+) pretty much kicks ass. GTK+ has a decent OO design, which is kind of a pain to use in C, but GTK-- manages to make GTK+ easy to use without losing functionality, or being so totally diffrent from GTK+ that you can't use GTK+ documentation to "figure out" how some underdocumented Gtk-- bit works.
I use to do a lot of Xt and Xaw, and even raw Xlib work. Then nothing for about six years. Then I picked up GTK-- and wrote a half decent MP3 juke box in a cupple of weeks. Higly recomended.
(Sometimes you hear computer science-types speculate about the possibility of automatic software validation, i.e. the possibility of developing a new language where it's possible to mathematically prove that your software is is correct. I'm not holding my breath.)
Actually there are such languages. CF Pascal for example. It might even be possable in Java. The big problem is unrestricted pointers (i.e. C style) make it impossable to prove anything.
There is another problem. You can prove that program X matched mathmatical model Y, but that doens't say that Y solves the problem you wanted. This wasn't treated as a big problem in my CMSC classes (back in '91), but it feels like a big problem to me. For example if model Y had two digit dates, then program X could have a bad bug, and the proof wouldn't find it, because it matches the bug in the model!
Also, for me at least, it was far simpler to write the code then to prove things about it. Like by at least an order of magnitude. A simple simple simple 10 line function would take hours for me to make formal statments about. I expect others do better. But as far as I could tell this level of effort could only be justifyed by life critical applications.
There are some pretty good results you can get by modeling part of your program logic. Like if you can model the locking hierachy of a multithreaded program the SPIN tool is a major help in finding race conditions, lock inversions, and deadlocks.
But please explain: precisely what "freedom" is it that corporations are in this particular situation "taking away from us"? The "freedom" to purchase a DVD and play it on a Unix box?
Specifically, well, yes. And that isn't a very important freedom.
However this is a use of the more general freedom to reverse engener. A quite important freedom. Not as importnat as some (say the freedom to bear arms, or to speak your mind), but not a pidly little pissant freedom, like say the freedom to pick your nose in public.
This is normal. In order to get more optmisation, the binary sizes _will_ increase. It does when you enable optimisation with gcc like -O6, this is hardly a new thing, but I'm not sure if it's due to the pentium(or itanium)'s design.
The IA64 puts 3 instructions in a 128bit bundle along with some dependency, and other coding information. The Alpha puts 4 instructions in the same 128bit space. I don't recall the IA64 instructions being particurlally more powerful for the most part. So the IA64 has to overcome that.
The IA64 does have a few little gimics to get some of the effects of unrolling a loop without unrolling it (they call it "software pipelining", but it's really just "modulo scheduling" all over agian). However some loops still benifit from both software pipelining, and unrolling, so that isn't a consistant win.
The IA64 can save a little space using predicates on short "if statements", but most of the ones where the savings is signifigant the Alpha can use a conditonal move.
So, yeah, it's easy to beleve 20%+ will be the IA64 code bloat baised on design alone. Then again RISC had a substantial code bloat disadvantage over CISC, and they still can make faster RISCs then CISCs in the same process/transaistor budget (Intel manages to pull ahead of many RISCs because they have a better process, and transistor budget, and way outspend on design -- and still the Alpha beats them).
Of corse when is code bloat not design? It may be bad design, or good design, but it is allways part of arch design, except maybe for a collage project (like the "one instruction machine").
How many peple actually watch the commercials? Would it be safe to say that the overwhelming majority fast-forwards through the commercials?
I have to admit, I watch maybe 25% of the comercials in a taped show. Sometimes I just plain forget I'm watching a tape and can skip. Sometimes the first comercial of the bunch looks intresting (like for a movie I havn't heard about, or a comercial that's actually entertaining). I'm kind of embarased to admit, but I have also been known to stop the FF and watch a comercial I find intresting.
I know I'm not the only one who does it. I've seen my wife do it too:-) Besides it's no less weird then people who watch the superbowl just to see the comercials.
The thing I wish I could skip (even in live TV, even at FF speed) was the comercial for a TV show I'm going to watch anyway, and all the ad will do is spoil the plot. I allways end up knowing more about the next episode of ER then I want too.
There's an interesting sci-fi scenario that might be relevant here. Basically, in the future, medical health technology comes to dominate society. The rich try to live forever, the poor can't, and everyone is taxed on how healthy they can stay without spending medical money. You thought the gap between rich and poor was bad before... think about what this means. Social Darwinism back in force. Is this what we want when we think of a working human society?
Well there are some other choices
Stop medical science, make sure nobody can live forever.
Force people who have worked hard (or been lucky) to give wealth to those who havn't (worked hard and/or been lucky)
Do you have better ideas? Do they still seem better if we replace "medical technology" with "car technology", or "lawn care"?
I know that sounds silly, but really it depends on your context. If you're a record-label executive, Cher might be quite a bit more important than BP. In fact, in most places other than the Open Source Community, BP isn't very important at all.
It depends on who you are and what is important to you.
Cher may well be more important to a record-label exec (or not, maybe the exec only does country or rap music). Cher is probbably more important to a divorced woman seeking a role model.
Bruce is almost certonally more important to open-software types (unless they are also a divorced woman seaking a role model... or a pop music record exec...).
To someone who is none of the above, I expect Bruse will have a more lasting change in their life. After all most people interact with software somehow, and unless Open Source's main arguments are all crap, Bruce has the chance to improve the quality of a vast amount of software. Thus slightly, but definitly, improving the lives of most people. At least the "most people" who use electricity, and the internet, and such.
P.S.: I'm not attempting to imply that Cher is the only, or best female role model, merely that she is probbably more accessable to females as a role model then most anyone with a first name of "Bruce".
If I misunderstand the application of role models, I'm sorry, I guess life tought me a few wrong lessons. Please feel free to set me stright.
P.P.S. I'm not trying to imply that Cher is a bad role model either. Judging almost entirely from the VH-1 behind the music show, she seems very happy (at long last) with her life. That's a good goal for anyone. Not to mention the film and music...wait, I said not montioning it right?
Actually while that is a good explanation of how the FreeBSD linux emulator works, it is not a good description of how the BSD/OS one works.
The FreeBSD one has a lot of in-kernel goo to translate syscall numbers (and sometimes arguments) from Linux numbers/arguments to FreeBSD ones. It also does a useful bit of jiggering to make overlay the contents of/usr/compat/linux/ onto/.
The BSD/OS one is 100% outside the kernel. It interposes a new libc shim between anything that looks for a linux libc and the real linux libc. the shim only contains syscalls (the stuff from section two of the manual), and makes BSD syscalls instead, sometimes re-jiggering the arguments. It does a similar overlay trick.
The BSD/OS one has some minor advantages. Since it doesn't add anything at all to the kernel it doesn't increses non-swapable memory, bugs that could lead to panics, or kernel complexity. These are minor advantages becuase Linux emulation is a small kernel module, and barely does any of those things.
It also has some disadvantages. It won't work for anything that makes syscalls without using the shared lib functions to do it. So no staticaly linked code will work. Nor will porgrams that do an inline expansion of the select syscall to make it work slightly diffently (that would be the Linux Netscape, and I assume other versions of Netscape as well).
I'm going to have to say the disadvatanges are bigger then the advantages.
In both cases the "emulation" is very fast. It is one basically a table lookup (or three) per syscall, and as syscalls are allready quite expensave, the extra work won't be noticed. Actually you might be able to notice a diffrence if all you do is call getpid(2), or getuid(2) a lot, but if you call write(2), read(2), or socket(2) then you won't be able to notice a diffrence.
In both cases the "emulation" only maps Linux features onto existing BSDish features. The read and write calls will be handled, but syscalls that exist only (very few, I think clone is one, FreeBSD could handle it by doing an rfork(2), but BSD/OS can't currently) on Linux will not work.
If the systems were farther apart then the emulation would be both harder to code, and possably introduce a real slowdown.
AMD's benchmark pages showed about a 9% lead in integer performance, and 45% in fp (using the SPEC suite of benchmarks) for a P-III and K7 at the same clock speed.
Assuming the coppermine is no better (or worse!) then the other P-III's (an Ok assumption) and everything scales with the clock (wrong, to the extent that there are cache misses) then bumping the P-III clock by 5% (733Mhz vs. 700Mhz) will pull even closer for SPECint, but not catch up, and will still be signifigantly behind on SPECfp.
Note, this is filled with "could be wrong" assumptions. But untill you can benchmark it yourself, it's not a shabby guess.
Well, I guess you buy into the theory that Bill Gates wants Microsoft to be broken up then.
Not really.
I'm pretty much sure bill doesn't want Microsoft broken apart (this is not the same as saying he might not mind one way or the other). If he wanted it broken up there would be one clear telling sign. He would start doing it.
There doesn't need to be a court order to split a compony. Look at the break up of AT and T a few years ago into Lucent, NCR(?), and ATandT. Look at Ford "spining off" thair parts division.
The stockholders probbably wouldn't complain, and if he was somehow afarid of them he would have at least sounded it out a bit.
No, this is too big a risk to be some disire to have big Gov'mnt split up Microsoft. It may be an accident. It may be delibrate. But that's not the reason.
Who's this we? It ain't all "BSD lovers", I'm rather fond of BSD, and I don't hate the GPL. In fact FreeBSD, NetBSD, and (I think) OpenBSD all ship with some GPLed software. So does BSD/OS.
Linux is technically inferior to BSD.
And BSD is technically inferior to Linux. BFD. BSD (in thery) has better seporation between chunks of the kernel. Linux has that cool slab allocator. BSD (now) has a soft-updating-FFS (similar speed to ext2fs, but without the danger), and is soon to get NetApp-like snapshots. Linux is getting XFS and/or RiserFS. (I don't mean to choose weaker examples for Linux here; I'm just more in touch with BSD stuff)
Surely one system or the other has more intresting bits of technology, but which bits are more interesting or important are more of an value judgement, and less an objectave fact.
Linux is an SVR4 clone.
Yes, it appears to be more or less. And I (mostly) like the BSD flavor better, but there isn't as much of a diffrence as in the old BSD4.2 vs. SysVR3 days. Both have reliable signals for instance. Since Linux has BSD style sockts and not TLI, I don't think there is any unlivable SysVism in it.
It has a poor development model.
Bull.
As a long-time BSD user I'm in awe of Linux's devlopment model. Not the thery behind it. The actual results. Dammed impressave.
Furthermore, BSD isn't fragmenting the UNIX community, Linux is. BSD was in widespread usage before Linux. The real UNIX fragmentation problem is the absurd number of Linux distros, which, despite what some Linux folk say, have very significant differences. Also, we're not 'splitting tasks'. Hardly anyone develops specifically for BSD, in fact, we suggest that they develop for Linux, since we can run the binaries natively, and port the source fairly easily.
Oh bite me.
Neither Linux nor (the free) BSDs are doing much to split the Unix community. That's all comercial Unix bullshit product diferention. I'll grant that Linux has a bunch of somewhat incompatable distros (even if they are baised on diffrent versions of the same kernel, changing the useland that much makes for compatability issues). But it just isn't a big deal.
I'm really getting sick of the Linux mentality that we need a gleaming, one world OS. The world needs different OSes, because every OS sucks at certain things, and they're always going to. The Open Source movement is about MORE decisions, not less, and the more choices we have, the better.
I'm not sure that is a Linux mentality. Sure a bunch of Linux fans seem to think it from time to time, but I don't think it is true of a large percentage of Linux users. I would bet most of them think more OSes are better then less.
As you get out of your car it begins to recharge itself form the docking station built into your garage and downlaods the audio notes you were dictating on the way home to your computer where they are converted to nice document form and ready on your desktop to do whatever you want with them.
Recharging: Not needed to be on the net.
Indeed, recharging is a poor reason to want your car on the net. Here are a few good ones:
Traffic updates so your on board route planner can guide you around traffic accidents, or other hevey traffic zones
Uploading your newly bought MP3's from your home (or work) stereo to your car's stereo
The same, but for movies (yes, requires way more storage, but we are heading that way, and it also requires people who want such things in the car...like pasangers, or maybe when autopilots get really good....)
I work irregular hours, so having a remotely controled thermostat would be nice except my wife is pretty much allways home before I am, and on a more regular schedule, so it's not a big deal to me. To couples that both have irregular schedules, or to single people it might well be nice. Nicer still if the car would tell the house to warm up/cool down baised on it's GPS as opposed to me telling it...
As you stated remote "tapeing" of TV (and I assume radio) could be handy. So could sending the programs from my house to work (assuming I get enough bandwidth - 256Kbits isn't what it use to be!) could also be useful (if I'm stuck at work waiting for a 3 hour test run to complete, it could be nice to watch ER).
As for putting random other home devices on the net, well I have been known to leave things on that I should have turned off, or off that should be on. It might help if I could "fix it" remotely, but I don't do it offen enough to be worth any real amount of money or risk that others may play play with it remotely.
I think those are pretty much the same devices - the WorkPad is just a relabeled Pilot, and the Phone is pretty much just a borg-like combination of the pilot and a phone... I think the Visor is the only device that is significantly different, hardware-wise.
The Visor is signifigantly the same as well. Same CPU, and the "CPU" includes the LCD controler, memory controler, serial, IR...
Even the "big diffrence" is hardware-wise just a bunch of pins that go to the CPU bus! (plus a few power lines and the Mic line). Well that and USB for sync'ing. (oh, nad no FLASH, so no OS3.3, but Handspring's version of PalmOS has the euro symbol, and some of the other 3.3 features -- it may be patachable to 3.3 in the RAM)
That happens to be enough to make me want to upgrade to it (maybe mine will show this week even), but I did want to point out that even the Visor is pretty damm similar to the olde Palms hardware wise.
To start with I want to point out that I agree with you on this. It's some of your other arguments that I'm not "at one with".
If you change the API, then you fragment and may the hordes of angry Linux hackers persecute you for the rest of your miserable days.
I don't agree with this, nor do I think it is a worthwhile goal either.
Let's say I add a utility that allows one to specify a power max or a tempature maximum. This changes the command line API (i.e. it adds a new command, probbably one only the "system manager" would bother with, and most likely only on portables, but still...). I don't think anyone will oblitarate me (assuming I release the source to all the needed kernel mods). I do think almost nobody will pay attention to me unless I release the source to my command line utility.
Same for the system interface, let's say I add a setsockopt(2) that tells the kernel to include timestamps on each packet read via recvmsg(2). Assuming I realase source (required as the code in question is GPLed) nobody will obliterate me.
In both cases most people would ignore the changes unless they made it into a major distro. Even then many people would ignore them unless they made it into almost all major distros.
However some small number of people that found the functionality very useful would use it. This would be good for them. They might lobby some of the distros to include the changes. They might not. A very few people might use some of these things and only later discover that they arn't very portable from Linux to Linux. That would be bad for them.
I could do a similar example with device drivers, but I leave that as an excorsize to the intrested reader.:-)
Yes, someone could fork the kernel tree, but at what price? I would hate them for it (as probably/hopefully millions of other people also would), which would automatically reduce their chances of successfully marketing whatever it is they make.
Then how do we get any change that isn't driven directly through Linus? I think the issue is less about forks in the tree, but forks that never join back up. It is good if the tree forks a little. It is good if some of the forks are deemed bad and allowed to die off. It is good if some of those forks are deemed good and folded back into the main line. It is very very bad if some of the forks are deemed good, but don't make it back into the main line.
The GPL makes sure that the code formed by forking a GPLed package (the kernel, and many but not all user level utilities) is available for folding back. That is a major strength of Linux. It doesn't prevent forking (as the sun community licence more or less does). I for one think that is also a major strength of Linux.
Re:Honestly, I could care less about faster Athalo
on
700 MHz Athlon
·
· Score: 2
Now, if AMD can come out with a chipset/motherboard that has 4-8 slots, AND I can stick the "commodity" (ie non-Ultra) Athalons in it, well, then, GoodBye Intel! AMD needs to realize that there is a huge opportunity here at the P3 / Xeon split, a place that they can heavily exploit.
I think AMD is pretty aware of this. After all they went to great effort to get a good SMP bus from Digital (now Compaq). However they don't make motherboards. They don't even want to be in the motherbord chipset bisness. In some ways both of these things are good. In other ways it is bad, mostly in reducing their time to market.
Look to Hotrail (I think that is a new compony name, was Posidon, or some other sea related name) for SMP chipsets. I heard they were trying to do 4-way, 8-way and 16-way ones. 4-way and maybe 8-way to be out first half of next year. I think. Ah, wait they say late 1999 for 4 and 8 way K7's.
Just in case I'm not totally clear here, what I want is to be able to use the SAME CPU from the low-end machines to the high end ones. Now, I know I'll get better performance by buying the Athalon Ultras (much more L2 cache), but I'd at least like the option of using the base Athalons, rather than be forced to use the more expensive chips, just because the manufacture want me to (that's the reason for the Slot1 vs Slot2 division - it's a pure Intel marketing decision).
As far as I know all the K7's are SMP capable. However the Ultra's are not just bigger cached non-Ultras. They also run the point to point bus faster, which means more memory bandwidth. I think they are planning on running it twice as fast as the non-Ultra K7's. Which means the extra bus traffic won't hurt as much.
The faster bus speed requires a cleaner eletrical enviroment the the lower bus speed. That is provided by the "Slot B" systems (shorter strighter traces I guess). Acording to AMD one could make a Slot A system that clean, but it isn't part of the Slot A specs AND costs more, so it is unlikely to be done on the Slot A systems.
My guess is you will see 2-way K7 systems, and 4-way K7 ultra systems, and later some 4-way K7's, but no 8-way or 16-way non Ultra systems. Of corse if there is a market for 8 and 16 way non-Ultra systems it doesn't look like AMD will stand in the way. It's not like the non-ultras were designed not to work in the SMP world, and it's not like the SMP chipset, or motherboards are made by AMD!!
Lastly when Intel first designed the Slot 1 vs. Slot 2 systems I thought that the PII Slot 1 module was too small to both hold the larger cache, and have enough extra cooling, which makes a real reason to have had Slot 2 in the first place. I assume that has gone away as SRAM tech has advanced.
Does this bug appear under any OS other than NT? Does anyone else thing this sounds more like a bug in NT than in the chip?
Since it only shows up under high load in an 8-way system there is a large chance that there are almost no non-NT systems configured that way.
It may end up cauing a BSOD on NT, and a panic on Unixish systems. It may cause just a plain lockup and the reporter assumed anything that crashes is a BSOD. It is easy to imagine the "bug" ends up loading the wrong thing into a cahe line which would upset any OS, or maybe it signals a non-correctable ECC failure which a good OS will panic on, a bad one will ignore (a great one will log the error, and if the page it is on is clean page it in from the backing store again, if dirty kill that pricess, or restart from the last checkpoint...)
UofMD had a long lived expariment in making a multiprocessor. It was baised on the Z-80. The goal was to get 64K of them all running in one big cabnet. I think they were still working on it in '92.
Re:Compact Flash! Palm? Handspring? Anyone but CE?
on
Palm Vx Coming Soon
·
· Score: 1
Well for one I assume they wanted more then just compact flash. For example the sprinboard connector has to use two pins for the mic input. I don't doubt someone will do a CF adaptor, even if springboard memory drops in price there is still going to be a desire to read CF from cameras and all...
Just remember a new bus (even with an old conector) isn't just an incompatable pain in the ass, but also a chance to add new functionality, or at least new features.
Slashdot Mirror
Um, no.
From my read of the GSM spec (a friend bought me the huge expensave book for Christmas one year...) the update timer is way shorter then hours.
More importantly from putting my 1900Mhz-GSMish phone near my computer speakers I heard transmit bursts from it multiple times an hour. Also just after it was turned off (as in I press off, the backlight turns on, it says "powering down", screen goes blank and THEN "blip-blip-blip").
Beats me how ofen CDMA phones transmit (I know they do handset assisted cell handoff, so they will transmit quite a bit when they are close to a cell boundry). I havn't read the spec, and I havn't noticed any interference from the phone yet (I switched when the provider in my areaa ditched GSM@1900Mhz to go with CDMA@1900Mhz, which has been providing me with fewer services, but doing them just as well, for moer money, what a bargin!)
You said:
What actually happend was Andy Bechlstien (and others) at Sun read a lot of the academic papers about RISC (possabbly before it got that name), specifically the SAIL and a few other CPUs. They told Motorola that there was definitate comercial intrest from Sun.
Motorola in effect blew them off (Sun was a largeish buyer of 680x0s, but not the same kind of volume as many of mot's other customers).
Sun partnered with (I think) Fujtsu to build the first SPARC on a 20K gate-array (the original 68000 was a 68K gate full custom job, so the SPARC was really quite impressave). That ran around 15Mhz to 20Mhz (the 68020 ran 20Mhz to 33Mhz at the time), but it got far more work done per cycle. The result was a $10,000 "12MIPS" machine (Sun4/110) as opposed to the $10,000 "4MIPS" machine the 68020 powered (3/150, or the slightly slower 3/60, or lots of 3/numbers-here machines).
Mot started a crash program to devlop the "88k", which DG eventually used for some ill-fated Unix workstations (The AvIlon i think). They may have started the program before Sun brought the SPARC out, because IBM managed to market a RISC baised machine before Sun's SPARC got out the door (About "6 MIPS", the IBM RT). That CPU had actually been around internal to IBM for a number of years, but never turned into a computer product (I think it came out of hte typewriter labs).
The 88k never really got any signifigant market share. Even upstart MIPSco got more market share (in part because DIGITAL was cought by Sun -- Sun's boxes were TEN times faster for the same money until DIGITAL droped their internal titan project, and brought out some nice MIPS R2000 and R3000 baised machines, total design to market time of about 8 months, incredable work, and the R3000s were slightly faster then the SPARC, at least for a little bit).
Then a whole bunch more stuff hapened:
I mostly agree. Here are my few points of contention:
I have heard that about GPL a lot. I'm not sure it is really true. I want to try a thought exparament.
Let's say FOOcorp takes a GPLed product and uses it "in house". Let's say I work for FOOcorp. One day I leave FOOcorp. Doesn't the GPL says I am entitled to a copy of the source if I want to pay reasonable copying costs?
I mean there is nothing in the GPL that excepts emploies, nor does it say you currently need a binary copy to have the rights granted to you by the licence.
My wife use to all the time. After I got the DVD player she still did, because the PSX's crappy CD interface was better thent he really crappy one on the DVD (to be honest the DVD one works with the TV off, the PSX doesn't, and it may have been because she was use to the PSX one).
She doens't anymore because I had to take back that S-Video input jack away from the PSX and give it to the dreamcast.
Keep in mind that if you yourself can program "enough people" is one. Many great projects start that way. Many more then having someone map out a great plan and then look for someone else to code it up. So if you have a Great Idea, and can't intrest others, go out and buy a good book on programming, dig in. Be the next Linus. The world over can mispronunce your name too!
I would have to say GTK-- (a C++ wraper for GTK+) pretty much kicks ass. GTK+ has a decent OO design, which is kind of a pain to use in C, but GTK-- manages to make GTK+ easy to use without losing functionality, or being so totally diffrent from GTK+ that you can't use GTK+ documentation to "figure out" how some underdocumented Gtk-- bit works.
I use to do a lot of Xt and Xaw, and even raw Xlib work. Then nothing for about six years. Then I picked up GTK-- and wrote a half decent MP3 juke box in a cupple of weeks. Higly recomended.
Personally i find that cars are much easyer to use and have more features and is overal better then tires.
Actually there are such languages. CF Pascal for example. It might even be possable in Java. The big problem is unrestricted pointers (i.e. C style) make it impossable to prove anything.
There is another problem. You can prove that program X matched mathmatical model Y, but that doens't say that Y solves the problem you wanted. This wasn't treated as a big problem in my CMSC classes (back in '91), but it feels like a big problem to me. For example if model Y had two digit dates, then program X could have a bad bug, and the proof wouldn't find it, because it matches the bug in the model!
Also, for me at least, it was far simpler to write the code then to prove things about it. Like by at least an order of magnitude. A simple simple simple 10 line function would take hours for me to make formal statments about. I expect others do better. But as far as I could tell this level of effort could only be justifyed by life critical applications.
There are some pretty good results you can get by modeling part of your program logic. Like if you can model the locking hierachy of a multithreaded program the SPIN tool is a major help in finding race conditions, lock inversions, and deadlocks.
Specifically, well, yes. And that isn't a very important freedom.
However this is a use of the more general freedom to reverse engener. A quite important freedom. Not as importnat as some (say the freedom to bear arms, or to speak your mind), but not a pidly little pissant freedom, like say the freedom to pick your nose in public.
The IA64 puts 3 instructions in a 128bit bundle along with some dependency, and other coding information. The Alpha puts 4 instructions in the same 128bit space. I don't recall the IA64 instructions being particurlally more powerful for the most part. So the IA64 has to overcome that.
The IA64 does have a few little gimics to get some of the effects of unrolling a loop without unrolling it (they call it "software pipelining", but it's really just "modulo scheduling" all over agian). However some loops still benifit from both software pipelining, and unrolling, so that isn't a consistant win.
The IA64 can save a little space using predicates on short "if statements", but most of the ones where the savings is signifigant the Alpha can use a conditonal move.
So, yeah, it's easy to beleve 20%+ will be the IA64 code bloat baised on design alone. Then again RISC had a substantial code bloat disadvantage over CISC, and they still can make faster RISCs then CISCs in the same process/transaistor budget (Intel manages to pull ahead of many RISCs because they have a better process, and transistor budget, and way outspend on design -- and still the Alpha beats them).
Of corse when is code bloat not design? It may be bad design, or good design, but it is allways part of arch design, except maybe for a collage project (like the "one instruction machine").
I have to admit, I watch maybe 25% of the comercials in a taped show. Sometimes I just plain forget I'm watching a tape and can skip. Sometimes the first comercial of the bunch looks intresting (like for a movie I havn't heard about, or a comercial that's actually entertaining). I'm kind of embarased to admit, but I have also been known to stop the FF and watch a comercial I find intresting.
I know I'm not the only one who does it. I've seen my wife do it too :-) Besides it's no less weird then people who watch the superbowl just to see the comercials.
The thing I wish I could skip (even in live TV, even at FF speed) was the comercial for a TV show I'm going to watch anyway, and all the ad will do is spoil the plot. I allways end up knowing more about the next episode of ER then I want too.
Well there are some other choices
Do you have better ideas? Do they still seem better if we replace "medical technology" with "car technology", or "lawn care"?
It depends on who you are and what is important to you.
Cher may well be more important to a record-label exec (or not, maybe the exec only does country or rap music). Cher is probbably more important to a divorced woman seeking a role model.
Bruce is almost certonally more important to open-software types (unless they are also a divorced woman seaking a role model... or a pop music record exec...).
To someone who is none of the above, I expect Bruse will have a more lasting change in their life. After all most people interact with software somehow, and unless Open Source's main arguments are all crap, Bruce has the chance to improve the quality of a vast amount of software. Thus slightly, but definitly, improving the lives of most people. At least the "most people" who use electricity, and the internet, and such.
P.S.: I'm not attempting to imply that Cher is the only, or best female role model, merely that she is probbably more accessable to females as a role model then most anyone with a first name of "Bruce".
If I misunderstand the application of role models, I'm sorry, I guess life tought me a few wrong lessons. Please feel free to set me stright.
P.P.S. I'm not trying to imply that Cher is a bad role model either. Judging almost entirely from the VH-1 behind the music show, she seems very happy (at long last) with her life. That's a good goal for anyone. Not to mention the film and music...wait, I said not montioning it right?
Actually while that is a good explanation of how the FreeBSD linux emulator works, it is not a good description of how the BSD/OS one works.
The FreeBSD one has a lot of in-kernel goo to translate syscall numbers (and sometimes arguments) from Linux numbers/arguments to FreeBSD ones. It also does a useful bit of jiggering to make overlay the contents of /usr/compat/linux/ onto /.
The BSD/OS one is 100% outside the kernel. It interposes a new libc shim between anything that looks for a linux libc and the real linux libc. the shim only contains syscalls (the stuff from section two of the manual), and makes BSD syscalls instead, sometimes re-jiggering the arguments. It does a similar overlay trick.
The BSD/OS one has some minor advantages. Since it doesn't add anything at all to the kernel it doesn't increses non-swapable memory, bugs that could lead to panics, or kernel complexity. These are minor advantages becuase Linux emulation is a small kernel module, and barely does any of those things.
It also has some disadvantages. It won't work for anything that makes syscalls without using the shared lib functions to do it. So no staticaly linked code will work. Nor will porgrams that do an inline expansion of the select syscall to make it work slightly diffently (that would be the Linux Netscape, and I assume other versions of Netscape as well).
I'm going to have to say the disadvatanges are bigger then the advantages.
In both cases the "emulation" is very fast. It is one basically a table lookup (or three) per syscall, and as syscalls are allready quite expensave, the extra work won't be noticed. Actually you might be able to notice a diffrence if all you do is call getpid(2), or getuid(2) a lot, but if you call write(2), read(2), or socket(2) then you won't be able to notice a diffrence.
In both cases the "emulation" only maps Linux features onto existing BSDish features. The read and write calls will be handled, but syscalls that exist only (very few, I think clone is one, FreeBSD could handle it by doing an rfork(2), but BSD/OS can't currently) on Linux will not work.
If the systems were farther apart then the emulation would be both harder to code, and possably introduce a real slowdown.
AMD's benchmark pages showed about a 9% lead in integer performance, and 45% in fp (using the SPEC suite of benchmarks) for a P-III and K7 at the same clock speed.
Assuming the coppermine is no better (or worse!) then the other P-III's (an Ok assumption) and everything scales with the clock (wrong, to the extent that there are cache misses) then bumping the P-III clock by 5% (733Mhz vs. 700Mhz) will pull even closer for SPECint, but not catch up, and will still be signifigantly behind on SPECfp.
Note, this is filled with "could be wrong" assumptions. But untill you can benchmark it yourself, it's not a shabby guess.
Not really.
I'm pretty much sure bill doesn't want Microsoft broken apart (this is not the same as saying he might not mind one way or the other). If he wanted it broken up there would be one clear telling sign. He would start doing it.
There doesn't need to be a court order to split a compony. Look at the break up of AT and T a few years ago into Lucent, NCR(?), and ATandT. Look at Ford "spining off" thair parts division.
The stockholders probbably wouldn't complain, and if he was somehow afarid of them he would have at least sounded it out a bit.
No, this is too big a risk to be some disire to have big Gov'mnt split up Microsoft. It may be an accident. It may be delibrate. But that's not the reason.
Who's this we? It ain't all "BSD lovers", I'm rather fond of BSD, and I don't hate the GPL. In fact FreeBSD, NetBSD, and (I think) OpenBSD all ship with some GPLed software. So does BSD/OS.
And BSD is technically inferior to Linux. BFD. BSD (in thery) has better seporation between chunks of the kernel. Linux has that cool slab allocator. BSD (now) has a soft-updating-FFS (similar speed to ext2fs, but without the danger), and is soon to get NetApp-like snapshots. Linux is getting XFS and/or RiserFS. (I don't mean to choose weaker examples for Linux here; I'm just more in touch with BSD stuff)
Surely one system or the other has more intresting bits of technology, but which bits are more interesting or important are more of an value judgement, and less an objectave fact.
Yes, it appears to be more or less. And I (mostly) like the BSD flavor better, but there isn't as much of a diffrence as in the old BSD4.2 vs. SysVR3 days. Both have reliable signals for instance. Since Linux has BSD style sockts and not TLI, I don't think there is any unlivable SysVism in it.
Bull.
As a long-time BSD user I'm in awe of Linux's devlopment model. Not the thery behind it. The actual results. Dammed impressave.
Oh bite me.
Neither Linux nor (the free) BSDs are doing much to split the Unix community. That's all comercial Unix bullshit product diferention. I'll grant that Linux has a bunch of somewhat incompatable distros (even if they are baised on diffrent versions of the same kernel, changing the useland that much makes for compatability issues). But it just isn't a big deal.
I'm not sure that is a Linux mentality. Sure a bunch of Linux fans seem to think it from time to time, but I don't think it is true of a large percentage of Linux users. I would bet most of them think more OSes are better then less.
Indeed, recharging is a poor reason to want your car on the net. Here are a few good ones:
I work irregular hours, so having a remotely controled thermostat would be nice except my wife is pretty much allways home before I am, and on a more regular schedule, so it's not a big deal to me. To couples that both have irregular schedules, or to single people it might well be nice. Nicer still if the car would tell the house to warm up/cool down baised on it's GPS as opposed to me telling it...
As you stated remote "tapeing" of TV (and I assume radio) could be handy. So could sending the programs from my house to work (assuming I get enough bandwidth - 256Kbits isn't what it use to be!) could also be useful (if I'm stuck at work waiting for a 3 hour test run to complete, it could be nice to watch ER).
As for putting random other home devices on the net, well I have been known to leave things on that I should have turned off, or off that should be on. It might help if I could "fix it" remotely, but I don't do it offen enough to be worth any real amount of money or risk that others may play play with it remotely.
The Visor is signifigantly the same as well. Same CPU, and the "CPU" includes the LCD controler, memory controler, serial, IR...
Even the "big diffrence" is hardware-wise just a bunch of pins that go to the CPU bus! (plus a few power lines and the Mic line). Well that and USB for sync'ing. (oh, nad no FLASH, so no OS3.3, but Handspring's version of PalmOS has the euro symbol, and some of the other 3.3 features -- it may be patachable to 3.3 in the RAM)
That happens to be enough to make me want to upgrade to it (maybe mine will show this week even), but I did want to point out that even the Visor is pretty damm similar to the olde Palms hardware wise.
To start with I want to point out that I agree with you on this. It's some of your other arguments that I'm not "at one with".
I don't agree with this, nor do I think it is a worthwhile goal either.
Let's say I add a utility that allows one to specify a power max or a tempature maximum. This changes the command line API (i.e. it adds a new command, probbably one only the "system manager" would bother with, and most likely only on portables, but still...). I don't think anyone will oblitarate me (assuming I release the source to all the needed kernel mods). I do think almost nobody will pay attention to me unless I release the source to my command line utility.
Same for the system interface, let's say I add a setsockopt(2) that tells the kernel to include timestamps on each packet read via recvmsg(2). Assuming I realase source (required as the code in question is GPLed) nobody will obliterate me.
In both cases most people would ignore the changes unless they made it into a major distro. Even then many people would ignore them unless they made it into almost all major distros.
However some small number of people that found the functionality very useful would use it. This would be good for them. They might lobby some of the distros to include the changes. They might not. A very few people might use some of these things and only later discover that they arn't very portable from Linux to Linux. That would be bad for them.
I could do a similar example with device drivers, but I leave that as an excorsize to the intrested reader. :-)
Then how do we get any change that isn't driven directly through Linus? I think the issue is less about forks in the tree, but forks that never join back up. It is good if the tree forks a little. It is good if some of the forks are deemed bad and allowed to die off. It is good if some of those forks are deemed good and folded back into the main line. It is very very bad if some of the forks are deemed good, but don't make it back into the main line.
The GPL makes sure that the code formed by forking a GPLed package (the kernel, and many but not all user level utilities) is available for folding back. That is a major strength of Linux. It doesn't prevent forking (as the sun community licence more or less does). I for one think that is also a major strength of Linux.
I think AMD is pretty aware of this. After all they went to great effort to get a good SMP bus from Digital (now Compaq). However they don't make motherboards. They don't even want to be in the motherbord chipset bisness. In some ways both of these things are good. In other ways it is bad, mostly in reducing their time to market.
Look to Hotrail (I think that is a new compony name, was Posidon, or some other sea related name) for SMP chipsets. I heard they were trying to do 4-way, 8-way and 16-way ones. 4-way and maybe 8-way to be out first half of next year. I think. Ah, wait they say late 1999 for 4 and 8 way K7's.
As far as I know all the K7's are SMP capable. However the Ultra's are not just bigger cached non-Ultras. They also run the point to point bus faster, which means more memory bandwidth. I think they are planning on running it twice as fast as the non-Ultra K7's. Which means the extra bus traffic won't hurt as much.
The faster bus speed requires a cleaner eletrical enviroment the the lower bus speed. That is provided by the "Slot B" systems (shorter strighter traces I guess). Acording to AMD one could make a Slot A system that clean, but it isn't part of the Slot A specs AND costs more, so it is unlikely to be done on the Slot A systems.
My guess is you will see 2-way K7 systems, and 4-way K7 ultra systems, and later some 4-way K7's, but no 8-way or 16-way non Ultra systems. Of corse if there is a market for 8 and 16 way non-Ultra systems it doesn't look like AMD will stand in the way. It's not like the non-ultras were designed not to work in the SMP world, and it's not like the SMP chipset, or motherboards are made by AMD!!
Lastly when Intel first designed the Slot 1 vs. Slot 2 systems I thought that the PII Slot 1 module was too small to both hold the larger cache, and have enough extra cooling, which makes a real reason to have had Slot 2 in the first place. I assume that has gone away as SRAM tech has advanced.
Since it only shows up under high load in an 8-way system there is a large chance that there are almost no non-NT systems configured that way.
It may end up cauing a BSOD on NT, and a panic on Unixish systems. It may cause just a plain lockup and the reporter assumed anything that crashes is a BSOD. It is easy to imagine the "bug" ends up loading the wrong thing into a cahe line which would upset any OS, or maybe it signals a non-correctable ECC failure which a good OS will panic on, a bad one will ignore (a great one will log the error, and if the page it is on is clean page it in from the backing store again, if dirty kill that pricess, or restart from the last checkpoint...)
Let's hope it's not a (well the) z-mob.
UofMD had a long lived expariment in making a multiprocessor. It was baised on the Z-80. The goal was to get 64K of them all running in one big cabnet. I think they were still working on it in '92.
Well for one I assume they wanted more then just compact flash. For example the sprinboard connector has to use two pins for the mic input. I don't doubt someone will do a CF adaptor, even if springboard memory drops in price there is still going to be a desire to read CF from cameras and all...
Just remember a new bus (even with an old conector) isn't just an incompatable pain in the ass, but also a chance to add new functionality, or at least new features.