IP however is really not a high performance protocol. It is routed rather than switched, it has variable size packets, It has a relativly high header to payload ratio, and its dependant on the concept of packet broadcast. [...] I think something similiar to ATM would make a real 'information superhighway', in contrast to the information dirt trail we have now. I mean video on demand, streaming virtual reality, video conferencing, etc.
Because IP has (about) 40 bytes of header on 0-1500 bytes of data (on most media - as little as 500ish bytes or as much as almost 64K on others), you want to use a 16 byte cell that is 33% header?
Did you know the really big ISPs are switcing away from ATM? Because nobody can make SARs fast enough? Not "they can't make enough SARs per month (which is a problem with lasers for OC48 or 192 now)", but "damm, we can't assemble packts fast enough!".
You are right that nobody wants to route IP thorough a whole big network. Older designs used Frame Relay or ATM to carry the traffic on most hops (making only a few routing choices). There is great hope that MPLS can be used in the future, with IP at the edges still of corse (MPLS is still variable sized packets, almost nobody advocates fixed size packets, the closest I have seen is an ATM like system with two sizes of packets (like 64 bytes and 512 bytes).
Most of your issues with IP are non-issues. Everything but the routed vs. switched, and there are hacks around that.
P.S. my ATM info is about a year old, it may have changed since then, but MPLS still seems to be the trend. Ask Juniper...
What is with the americans and GMS? The rest of the world seems to love it
I won't claim to speek for the other amaricans, but I had GSM service for about two years, until Sprint changed the wasington area from GSM to CDMA. The switch was a botch from a customer relations point of view (bad choice of free replacment phones, accessory upgrade only if you took the free phone, tight deadlines, phone shortages; going to the local stores and talking nice seemed to help alot though).
The new CDMA service is slightly nicer then the old GSM-1900 service. It sounds a little better. It has somewhat better covrage, the phone was smaller and lighter (well, that would have been true if I had traded my old GSM phone for a new one). I lost the ability to send text messages from the phone (can still recieve them), but got the wireless web stuff......the wireless web stuff is just a cut above crap, but not by a lot.
So from my point of view it was a modest improvment, but an improvment none the less.
From their point of view it in thery lets them get more calls in the same bandwidth (I think original projections were for 40x analog usage while GSM is about 8x or 12x; I think the estimates have come down to far less then 40x, but still a bit above GSM's).
That doesn't really do much for me, unless a cellular price war forces prices down to close to costs (or if I had FON or AWE stock). Prices are coming down, so maybe that is happening.
When I had a GSM (at 1900Mhz) phone, Sprint didn't have roaming agreements with the UK. That was about the only place I went outside the USA, and no covrage from orange or vodaphone, or anyone. I was even willing to rent a phone for my SIMM, but no dice.
So I don't really miss GSM much. Maybe the visor phone will come out in a CDMA version. Who knows. I'm not sure I would want to pay $200 for it, my existing phone is pretty small...
TIVO is doing a little more than they are actaully required to by the GPL.
More then required by the GPL and the binary module exception, yes.
My point wasn't that TiVo are bad guys (I don't think they are), but that what Apple is doing with BSD is pretty much the same thing TiVo is doing with Linux, so if one doesn't like what Apple is doing, don't think the GPL on Linux saves it from the same fate.
I do admit Apple could have done "worse", but that wasn't what the previous poster said. The were upset about OSX, and wanted to stick to GPL'ed things to prevent that.
If TIVO wanted to be jerks, they could require you to send in the UPC code for your TIVO before they would mail you a floppy disk with the kernel code on it. Of course, that would actually be more work for them, and it would be bad press, so there's no advantage.
Sure, and if they wanted to be jerks they would take a hard stance against hacking the TiVo and see if they could get all the bad press iOpener and CueCat got too. But they have the totally reasonable stance "if you open it and play with it that's cool, but if you break it don't call customer support for anything other then laughter".
A shame about that no-ethernet and no-firewire thing though.
I'm not a BSD user because developments like MacOS X make me uncomfortable. It's an ideological difference. I don't like the idea of someone modifying my code and not showing me what they did.
As far as I know Apple has published the source to all the BSD stuff they have touched. The closed source parts of OS-X are things they wrote in house (like DisplayPostscript, er, DisplayPDF I mean, the OS 8 compatability box, and the candy coated GUI).
That is pretty much like the TiVo people giving back the few Linux kernel mods they did (I don't think they gave back the filesystem, since they use a kernel loadable module there, but I donno for sure). I know they don't give back their candy coated GUI. A shame, because there are a few little tweaks I would like to make...
Yes, with the GPL you are required to give back changes in many cases. With the BSDL you are never required to give them back. So Apple is either "being good people (at long last)", or "playing the PR game". TiVo is "walking the fine line guided by their lawyers".
I donno about switching OSes, but whatever OS you use you should definitly look at SPIN, a tool for modeling locking behaviour (and other things). It has found a large number of problems in real systems that "normal" debuggin had a hard time finding. Race conditions are hard to remove by inspection!
As for Java vs. C++, well Java isn't a bad language, and having threading built in rather then slapped on as a bag on the side makes it nicer (pop quiz: what C++ facet operations are thread safe?). On the other hand I feel a bit limited in Java, and I miss the STL. As far as I know SPIN will help Java coders as well.
I don't think Solaris x86 is a good idea. If you want Solaris, get a SPARC. Otherwise you are always behind the support curve, and the hardware support is far more limited then Linuxes. Besides the SPARC hardware is extreamly reliable (if not all that fast), and works great for lights-out operations.
It may be downtime but it is much less then if you
had to rebbot and wait for the BIOS, hardware detection etc.
Hopefully that is skipping the BIOSes hardware detection, not Linuxes. If it skips Linuxes then:
You can't add support for a new device because the old kernel didn't detect it (somewhat minor)
You might install a kernel that fails to recognise a device you need, but still can run it. A later reboot will fail to get you a working system. It could be many months and sever kernel upgrades before the problem shows up, making it extremly hard to track down (not at all so minor)
Both RCA and HP tried "SOS" chips, silicon-on-saphire, but the advantages didn't compensate for the much higher cost.
I think the silicon-on-saphire helps making circuits rad-hard. At least last time I skimed a rad-hard catalouge RCA had a 10Mhz MIPS R2000 clone done on SOS, and a lot of the other parts were SOS also.
Depends on how you propose to fix the problem. Maybe it might be possible to presume the cpu is an i386
with no floating point if there's not a full database match, but that might piss off a lot of people, or it might
not work at all anyway. I'm not sure how detailed the cpuid list is.
That sounds like a good idea (might be nice to print a warning as well). That way you can boot and make a new kernel that knows about the new CPU as long as the CPU maker has done their job and it works like the a 386! If you can't even boot, then you can't fix the problem unless you have a whole other computer, and the ability to make boot media for the first machine on it (which can be a pain if you are installing on something like a laptop that can have *either* a CD or a floppy....).
It's not really surprising. But if Intel knew a year ago what changes would need to be made to the cpuid list,
and didn't tell kernel developers well in advance of product release, it's their own fault. If it required a kernel
developer getting his or her hands on an actual P4, that's not the linux communities fault.
I admit Intel was (once again) lame. However lameness on their part does not excuse lameness on Linuxes part.
[...]
EEPROM's can be
expensive and may have long term reliability problems - you can read and write to them only so many times or cycles
before you degrade the ability of the memory to "remember".
I know EEPROMs (and FLASH!) have a limited number of write cycles. I was utterly unaware of a limit on the number of reads. Do you have any pointers to data sheets?
I've used (recently) some mid-80's CoinOp games (video and pinball) that used EEPROMs. They looked like the originals, but I have no idea. I suppose they also could copy the EEPROM contents to RAM, but I didn't see enough RAM on the boards for that (and I know when I worked for MP Games we executed code stright from the EEPROM, and I saw on of our games running um, maybe six months ago, so eight plus years from the build date). So I'm guessing either the number of reads is astronomicly high, or I'm misunderstanding you...
FYI FLASH can have a ton of write cycles (some AMD FLASH's in the mid 90's claimed 1,000,000 write cycles). So they make fine storage systems for code and (mostly) static data. Not so sure I would want to use one as a log disk or swap space though...
No power consumption on laptops... Imagine a laptop using this and an Amulet processor
Not no power consumption. No power consumption when not reading or writing data. And that isn't even 100% sure, it may need sense and positiong circuits powered up for any sort of acceptable memory access time. For all we know the actual power needed to read and write may be far more then DRAM (or far less).
We don't know what kind of memory this thing will actually replace until there is more info on operating power/speed/tempature, and storage tempature/duration, and density, and sheilding required (which is effectavly density).
This could be the next DRAM, or the next FLASH, or just the next Bubble Memory.
Not really the same thing. Sure you got to the OS prompt within a second of power on, but not to whatever you were doing when you turned it off (unless you left it at the command prompt with no loaded program...or were in the attract mode of a cartrage game with no high scores...).
This would be more like the PDP as the prior poster said where the last thing it was doing, it still is. Or a susspended laptop/Palm pilot, except they need to keep power to stay on (and most laptops take a long time to unsusspend!!).
Or like what I do at work. Use Unix, xlock, and turn the monitor off.:-)
BTW, your Visor uses FlashRAM, and MRAM is more efficient.
The Visor doesn't have FLASH, and has taken a lot of crap for it. The Palm (and as far as I know, the TRG Palm clone, and Sony Palm clone) all use Flash to store the OS, and with 3rd party software (er, TRG's software, which they bundle with the Pro) they can store some apps, and some read-only data in the FLASH as well.
However they all use RAM (DRAM, or SDRAM, or some kind of ram with a P in it) to store most user installed programs and data. They get multi-week run times on 2 AAA batts because they put the RAM into a low power refresh mode (the exact kind depends on the RAM, and the clone, and if you installed a patch, and...). There is no reason you can't do that with a desktop system, or laptop, but it does take some power. More power for the 64M and 128M desktops and laptops we are seeing now then for the little 8M palm tops.
MRAM would use no power to keep it's memory. If it can have a decent read speed and size and power use (oh, and price) it will kill the flash market. If it can't get good speed and power use, but can get gread prices then it will kill the disk drive market. If it gets great speed and fair power and great price it can kill the DRAM market. Other combinations may not impact any existing market, but may make new ones. Or just turn it into an also-ran.
P.S. FLASH uses no power while you are not reading or writing it (i.e. no power when merely storing data). So MRAM is no better in that respect. We don't know that it will be better in any other way when it finally gets to market, but we can hope!
P.P.S. it isn't 100% true that the Visor has no FLASH. It has no FLASH as shipped. Many 3rd party modules have (or pretty much are) FLASH, like the backup module, or the 8M FLASH module.
That looks a little like the stuff Canon used to shave a few pounds off of it's 400mm lens. Wish I could buy (either!) now. (it's the "Multi-Layer Diffractive Optical Element" thatlooks a bit similar to some of the GLV...)
So what? You cant type fast enough or have enough different program names to type for this to be an issue. The incidence of new programs is an incidence measured in slow plodding human time.
New programs are started infrequently in part because fork and exec is slow. Many things that would have been shell scripts have been done as small C/C++ programs, or perl scripts because "shell scripts are slow". Why are shell scripts slow? Because fork n' exec is slow.
Now fork isn't hugly slow, and vfork is pretty fast (where it isn't just fork), even if it is a glatic scale kludge.
exec , or execve is the slow one. Dog slow. Namei lookups, tons of MMU diddling, normally a lot of disk I/O. Oh, and we can't forget the cost of ld.so on a modern system. The dyanmic linking takes it's toll on process startup as well (of corse it can save time faulting in libc and libfoo, and it definitly helps memory starved systems).
Personally, I find most software doesnt need threads and that introducing threads raises program complexity and bugs. Threads are a *difficult* abstraction.
Same here. A lot of times select/pool/kevent, and sometimes an extra process or three are way simpler to debug. Most of the time even. But it is (many times) simpler to write threaded code then event loop code, but you can pay for it for a long time in debugging. Other times the threded code can run a whole whole whole lot faster.
Wow. I pretty much rely on everything being two's-complement these days, I guess I'm spoiled by only having one zero in my number system...
IEEE Floating Point has a negitave and positave zero.
I wish x86 had adopted auto-increment mode from the PDP; it would have made implementing C a lot cleaner. (C is portable, but it's biased too:)
Is that "fetch and incr address", or "incr address then fetch"? Incr first has it's downsides (mainly it is in a critical path). Not that many RISC's don't have it, or almost as complex immediate displacment (which doesn't need a register writeback port).
Nowadays, we've got x86 assembly, C++, and Java. I'm actually very happy that I managed to find the courses that still really teach C...
It's good to learn a (conventional) assembly, and stright C. It gives a much better feel for way you get low level memory smashing bugs, and how they manifest. It is also nice to learn higher level languages (Java/C++), in part because they are more likely to be what you'll see on the job, and in part because they let you do bigger class projects, and in part because it lets you see language design gone not-quite-really-bad.
Oops. I guess I didn't add a whole lot to the thread there then, did I?
(Or do you get a stack trace if you install Microsoft VisualMagicWizardDevInterStudio2K.NET with the all-singing, all-dancing debugger?)
In '90 whatever all-singing all-dancing app the University of Maryland had for the PC (I think it was a Microsoft product) let you trace a program and look at the stack. It had nothing like core files. In the ten years since then it, or a competing product (CodeWarrier?) may have grown it.
To tie that in with another thread, the UofMD's CS classes were mostly focused on datastructors/algos/proving-trivally-simple-progra ms-correct/vague-concepts/some-language-skill. Most the the classes used Unix, the two intro classes used a truly nasty-unplesent PC baised CF-Pascal, a few other classes (incl assembly) used the IBM 370s. In all a satisfyingly diverse set of boxes. I missed getting to use a ones complment box by a few years, or writing a PDP-11 OS by (about) a year.
In '97ish I tryed to pick up some Microsoft programming skill by getting the student/amature version of Code Warrier. It didn't do core dumps either. In fact the program under debug could crash the debugger (and OS)! Even if it was Java code! Later I tryed Symentac's java product, and it was just as screwed (but much faster). Then I gave up and went back to Unix.
You could even do a bit of debugging if there was no source (assembly level commands with synthetic labels, and some OS call decode). It looked unplesent, in part because I find x86 assembly unplesent (after being spoiled on the 680x0 and RISCs).
I'd personally be really interested to see where the blame for this lack of robustness lies: the applications, the MFC, or the Win32 API. Unfortunately, there's really no way to do that with such simple testing tools.
Sure there is. Fuzz generates the crash, looking at a stack dump and the source shows you the reason. That worked great for the Unix paper where many of the utilities were open source, and even (some of) the closed source authors agreed to allow the papers' authors to have a look.
That doesn't seem to be panning out as well under Windows, but who knows, maybe time will tell.
As far as the send/post message stuff goes, I think it is hard to blame the windows programs from getting a message with a pointer, and dereferenceing it. It is an inelegent API when only the OS can send events, a destabalisingone if only "trusted" programs can do it, and downright stupid if any program can do it.
Few Unix OS calls return pointers. sbrk, mmap, and kevent are the only ones I can think of. I expect when they are called the pointers are checked to see if they are one of the documented error values (normally NULL, sometimes -1 cast to a pointer). I try to make sure my programs do, and think of it as a failure if I forget. I don't expect programs to check to see if they got other "bad return" values, it is rather hard to do so (you can see if it is odd -- which isn't portable -- you can install a SEGV handler and probe the range). I don't do it, and many of my programs have stood the test of time in a hostle production enviroment (of corse I take a more aggressave stance about checking network packets...). I don't find it supprising that Windows programmers don't do much pointer validity checking either.
To sum up, 100% of Windows sucks, but only 45% of the Windows applications suck.:-)
As you point out, frame relay was delivered over a T1, making it functionally equivalent to a fractional T1, at least as far as ISPs went.
Actually at the ISP end they get a full T1 or T3 into the cloud and serve multiple customers with it (assuming there are multiple in that area, otherwise they would just get a fraction into the cloud).
That provides the ISP with a cost savings, a space savings, and somewhat less setup hassle as well.
And for internet service five years ago, a 56K link was a) hard to find, b) a pain to install, c) a worse deal than a fractional T1, and d) a stunningly awful deal compared to a dialup.
They were not hard to find. Were not all that painful to install (they had fewer line options then a T1 let alone ISDN - the only I rember were 2-wire vs. 4-wire). May have been a worse deal then a frac. T1. Almost certonally were a worse deal then a dialup, unless you couln't FX your dial up line into a local calling area and wanted to nail the call up 24hrs/day.
Now if you want painful to install, and cost ineffectave, look into 3002 circuts (leased voice lines - I think - I never installed any, my boss did both the first, and later the last ones that UUNET ever sold).
Five years ago I had a 56K Frame Relay which came over a phsycal 56K (and it was free, at least to me). It was pretty nice. I have a 256K Frame Relay now (over a fractional T1 -- unless they changed it without me noticing) which I like a lot more. Esp. as the price hasn't changed. However that means I can't recall how close to 56Kbit/sec modems were five years ago.
The same pretty much goes for ISDN; for 'high-speed' dialup, it was a good deal, but if you wanted a permanent connection from a fixed location, fractional T1s were also a better deal, at least under my RBOC
Definitly depends on the RBOC. Was not a good deal from Bell Atlantic unless you were online less then about 60hrs/month. Was a great deal from one of the lame RBOCs (US Worst? Amaritech?) because their billing system didn't make it easy to do metered usage, they did flat rate.
And I've never heard of anybody offering internet service via X.25. Did this ever happen? If so, what were they thinking?
Offer? I don't know. It has been sold though. UUNET use to sell it to one or two customers. I'm not 100% sure why, but I beleve the customers had lots of X.25 experiance, and didn't want anything else.
And the poster's point, which is that five years ago a small site pretty much had to get a T1, is still basically true. At the time we managed to talk an ISP into colocating a box, but at the time that was a pretty unusual thing.
Well there was web hosting (UUNET had it five years ago), and fractional T1's. The frac T1 (at least in Frame Relay form) may have been phsycally a T1, but cost wise it was a totally other animal. Totally. I mean for most RBOCs there isn't even a wire-mile charge!
Of course, its hard to justify a T1 for residential use, but 5 years ago, you had T1 and dialup and nothing in between.
Five years ago you could get 56K, ISDN and Frame Relay as steps between dialup and T1. Probbably X.25 some other random X.25 services as well. I'm pretty sure Frame Relay was available a lot longer ago then five years as well.
Of corse to be honest Frame Relay use to be delevered as a physical T1 (or 56K for small FR CIRs), but it was billed very diffrently, and had diffrent bandwidth (selectable, but lower) and latency (not so selectable, and higher) from a "raw" T1. I have heard Frame Relay is frequently done as a physical DSL line now, at least in some cases.
What happened to the good ole' days of ISPs? Back when you could get a _REAL_ IP connection to the net, not some proxied, port-filtered, DHCP line with no storage space and no shell access?
Well, everyone and his brother showed up wanting ten times the bandwidth for half the price.
Do ISPs not realize that maybe, just maybe, you might want to get files off your home box, and perhaps not want to set up an public FTP server that would waste all of the bandwidth you're paying for.. and since you're _PAYING FOR IT_, why should it matter to them if you're pegging the line refreshing cnn.com and slashdot all day long, or if you're serving legal MP3s to some friends, or distributing files to other machines/shell accounts..
Because when the prices were driven down the bandwidth overcommit was driven up. Sure you can get 768Kbit DSL for $30/month in some places, but they (probbably) have a 100 to 1 overcommit on the bandwidth. So they craft an acceptable use policy that limits the amount of bandwith that gets used, and most people (say 98%) are happy.
The people that arn't should probbably look into ISPs that have looser AUPs, but they should also realise that there is likely to be a larger price tag on "unlimited" serveces that really are unlimited.
Does it suck that you can't get real unlimited access for cheep/free? Sure. But it sucks that I can't fly unassisted either (well, it's actually that I can't make a good landing).
but why the hell has a residential internet line become equal to a castrated internet line?
Pretty much since the first offering of "unmetered access". It still cost the ISP to have you dialed in (even if it only cost a modem port and voice circuit that couldn't let me dial in while your on). So they started claming you can't run services, can't camp on the line, can't run ping scripts to keep the line up.
One was even pretty pissed at a friend of mine who ran NNTP to keep his clock in sync because it kept the line up. Of corse it didn't violate their AUP so they had to lump it (they did send threating email once a month and he sent his canned reply every month).
You can still buy dial-up accounts without that kind of restriction, but they cost per hour. Just like you can get leased lines without server restrictions (most have restrictions against wholesaling the bandwidth to others, but you can get even more expensave connections without that restriction).
Oh, it doesn't break the rules. But it is a joke. Watch the presdent's analist some time (a good movie). I wasn't involved with the naming, but I talked to the folks who did it. Hell, UUNET wan't a phone compony at the time, it was all that much more amusing to me then.
Its a very intreasting project
No, a quite dead project. But still intresting.
Er, unless this is a new use of TPC.INT, the original use was FAXing. Drat, now that I read your RFC that's not the one. Try RFC 1528, 1529, and 1530, and also www.tpc.int...whih of corse claims to be not currently dead. But the history section says it was dead in 1994, which is what I recall.
As a side note, the problem with inability to deal with squatting of ".com" (.net,.org) addresses has to do with several registrars handling these. Competition for domain name registration is Good, but no single TLD should be in the hands of more than one registrar. Why? Because they will compete for customers by lowering their prices - if one entity managed it they could actually increase the prices for registration based on the current shortage.
...
The price tag of $50000 for a TLD application filtered out common sense, and left only money left to speak. Bad idea.
Let me get this stright, charging a lot for a domain name is a good idea, but charging a lot for a TLD is a bad idea?
you never want a windows app that knows *nothing* about linux to load a module into your kernel. You're just asking for trouble if you do.
Oh, I agree with that. What I waned to know was the diffrence between "VXD's are a bad idea unique to Windows" and "KLM's are great, Linux has them, FreeBSD has them, Solaris has them...".
Is the diffrence really "Windows programmers are morons in it for only the money", and "Linux programers are frickin' briliant"? Or is there a real technical diffrence?
Windows allows programs to lobotomize its kernel on a whim via ring 0 VxD's. Linux ain't gonna do that. It's not that we're not actually able to, we're just not stupid enough to WANT to.
Apart from terminology how is a ring 0 VxD diffrent from a kernel loadable module? Sure you need to be root to load one, but it is putting code into the kernel that gets executed on the bare metal in ring 0...
Slashdot Mirror
Because IP has (about) 40 bytes of header on 0-1500 bytes of data (on most media - as little as 500ish bytes or as much as almost 64K on others), you want to use a 16 byte cell that is 33% header?
Did you know the really big ISPs are switcing away from ATM? Because nobody can make SARs fast enough? Not "they can't make enough SARs per month (which is a problem with lasers for OC48 or 192 now)", but "damm, we can't assemble packts fast enough!".
You are right that nobody wants to route IP thorough a whole big network. Older designs used Frame Relay or ATM to carry the traffic on most hops (making only a few routing choices). There is great hope that MPLS can be used in the future, with IP at the edges still of corse (MPLS is still variable sized packets, almost nobody advocates fixed size packets, the closest I have seen is an ATM like system with two sizes of packets (like 64 bytes and 512 bytes).
Most of your issues with IP are non-issues. Everything but the routed vs. switched, and there are hacks around that.
P.S. my ATM info is about a year old, it may have changed since then, but MPLS still seems to be the trend. Ask Juniper...
I won't claim to speek for the other amaricans, but I had GSM service for about two years, until Sprint changed the wasington area from GSM to CDMA. The switch was a botch from a customer relations point of view (bad choice of free replacment phones, accessory upgrade only if you took the free phone, tight deadlines, phone shortages; going to the local stores and talking nice seemed to help alot though).
The new CDMA service is slightly nicer then the old GSM-1900 service. It sounds a little better. It has somewhat better covrage, the phone was smaller and lighter (well, that would have been true if I had traded my old GSM phone for a new one). I lost the ability to send text messages from the phone (can still recieve them), but got the wireless web stuff... ...the wireless web stuff is just a cut above crap, but not by a lot.
So from my point of view it was a modest improvment, but an improvment none the less.
From their point of view it in thery lets them get more calls in the same bandwidth (I think original projections were for 40x analog usage while GSM is about 8x or 12x; I think the estimates have come down to far less then 40x, but still a bit above GSM's).
That doesn't really do much for me, unless a cellular price war forces prices down to close to costs (or if I had FON or AWE stock). Prices are coming down, so maybe that is happening.
When I had a GSM (at 1900Mhz) phone, Sprint didn't have roaming agreements with the UK. That was about the only place I went outside the USA, and no covrage from orange or vodaphone, or anyone. I was even willing to rent a phone for my SIMM, but no dice.
So I don't really miss GSM much. Maybe the visor phone will come out in a CDMA version. Who knows. I'm not sure I would want to pay $200 for it, my existing phone is pretty small...
More then required by the GPL and the binary module exception, yes.
My point wasn't that TiVo are bad guys (I don't think they are), but that what Apple is doing with BSD is pretty much the same thing TiVo is doing with Linux, so if one doesn't like what Apple is doing, don't think the GPL on Linux saves it from the same fate.
I do admit Apple could have done "worse", but that wasn't what the previous poster said. The were upset about OSX, and wanted to stick to GPL'ed things to prevent that.
Sure, and if they wanted to be jerks they would take a hard stance against hacking the TiVo and see if they could get all the bad press iOpener and CueCat got too. But they have the totally reasonable stance "if you open it and play with it that's cool, but if you break it don't call customer support for anything other then laughter".
A shame about that no-ethernet and no-firewire thing though.
As far as I know Apple has published the source to all the BSD stuff they have touched. The closed source parts of OS-X are things they wrote in house (like DisplayPostscript, er, DisplayPDF I mean, the OS 8 compatability box, and the candy coated GUI).
That is pretty much like the TiVo people giving back the few Linux kernel mods they did (I don't think they gave back the filesystem, since they use a kernel loadable module there, but I donno for sure). I know they don't give back their candy coated GUI. A shame, because there are a few little tweaks I would like to make...
Yes, with the GPL you are required to give back changes in many cases. With the BSDL you are never required to give them back. So Apple is either "being good people (at long last)", or "playing the PR game". TiVo is "walking the fine line guided by their lawyers".
Does the TiVo make you uncomftrable?
As for Java vs. C++, well Java isn't a bad language, and having threading built in rather then slapped on as a bag on the side makes it nicer (pop quiz: what C++ facet operations are thread safe?). On the other hand I feel a bit limited in Java, and I miss the STL. As far as I know SPIN will help Java coders as well.
I don't think Solaris x86 is a good idea. If you want Solaris, get a SPARC. Otherwise you are always behind the support curve, and the hardware support is far more limited then Linuxes. Besides the SPARC hardware is extreamly reliable (if not all that fast), and works great for lights-out operations.
Hopefully that is skipping the BIOSes hardware detection, not Linuxes. If it skips Linuxes then:
I think the silicon-on-saphire helps making circuits rad-hard. At least last time I skimed a rad-hard catalouge RCA had a 10Mhz MIPS R2000 clone done on SOS, and a lot of the other parts were SOS also.
That sounds like a good idea (might be nice to print a warning as well). That way you can boot and make a new kernel that knows about the new CPU as long as the CPU maker has done their job and it works like the a 386! If you can't even boot, then you can't fix the problem unless you have a whole other computer, and the ability to make boot media for the first machine on it (which can be a pain if you are installing on something like a laptop that can have *either* a CD or a floppy....).
I admit Intel was (once again) lame. However lameness on their part does not excuse lameness on Linuxes part.
I know EEPROMs (and FLASH!) have a limited number of write cycles. I was utterly unaware of a limit on the number of reads. Do you have any pointers to data sheets?
I've used (recently) some mid-80's CoinOp games (video and pinball) that used EEPROMs. They looked like the originals, but I have no idea. I suppose they also could copy the EEPROM contents to RAM, but I didn't see enough RAM on the boards for that (and I know when I worked for MP Games we executed code stright from the EEPROM, and I saw on of our games running um, maybe six months ago, so eight plus years from the build date). So I'm guessing either the number of reads is astronomicly high, or I'm misunderstanding you...
FYI FLASH can have a ton of write cycles (some AMD FLASH's in the mid 90's claimed 1,000,000 write cycles). So they make fine storage systems for code and (mostly) static data. Not so sure I would want to use one as a log disk or swap space though...
Not no power consumption. No power consumption when not reading or writing data. And that isn't even 100% sure, it may need sense and positiong circuits powered up for any sort of acceptable memory access time. For all we know the actual power needed to read and write may be far more then DRAM (or far less).
We don't know what kind of memory this thing will actually replace until there is more info on operating power/speed/tempature, and storage tempature/duration, and density, and sheilding required (which is effectavly density).
This could be the next DRAM, or the next FLASH, or just the next Bubble Memory.
Not really the same thing. Sure you got to the OS prompt within a second of power on, but not to whatever you were doing when you turned it off (unless you left it at the command prompt with no loaded program...or were in the attract mode of a cartrage game with no high scores...).
This would be more like the PDP as the prior poster said where the last thing it was doing, it still is. Or a susspended laptop/Palm pilot, except they need to keep power to stay on (and most laptops take a long time to unsusspend!!).
Or like what I do at work. Use Unix, xlock, and turn the monitor off. :-)
The Visor doesn't have FLASH, and has taken a lot of crap for it. The Palm (and as far as I know, the TRG Palm clone, and Sony Palm clone) all use Flash to store the OS, and with 3rd party software (er, TRG's software, which they bundle with the Pro) they can store some apps, and some read-only data in the FLASH as well.
However they all use RAM (DRAM, or SDRAM, or some kind of ram with a P in it) to store most user installed programs and data. They get multi-week run times on 2 AAA batts because they put the RAM into a low power refresh mode (the exact kind depends on the RAM, and the clone, and if you installed a patch, and...). There is no reason you can't do that with a desktop system, or laptop, but it does take some power. More power for the 64M and 128M desktops and laptops we are seeing now then for the little 8M palm tops.
MRAM would use no power to keep it's memory. If it can have a decent read speed and size and power use (oh, and price) it will kill the flash market. If it can't get good speed and power use, but can get gread prices then it will kill the disk drive market. If it gets great speed and fair power and great price it can kill the DRAM market. Other combinations may not impact any existing market, but may make new ones. Or just turn it into an also-ran.
P.S. FLASH uses no power while you are not reading or writing it (i.e. no power when merely storing data). So MRAM is no better in that respect. We don't know that it will be better in any other way when it finally gets to market, but we can hope!
P.P.S. it isn't 100% true that the Visor has no FLASH. It has no FLASH as shipped. Many 3rd party modules have (or pretty much are) FLASH, like the backup module, or the 8M FLASH module.
That looks a little like the stuff Canon used to shave a few pounds off of it's 400mm lens. Wish I could buy (either!) now. (it's the "Multi-Layer Diffractive Optical Element" thatlooks a bit similar to some of the GLV...)
New programs are started infrequently in part because fork and exec is slow. Many things that would have been shell scripts have been done as small C/C++ programs, or perl scripts because "shell scripts are slow". Why are shell scripts slow? Because fork n' exec is slow.
Now fork isn't hugly slow, and vfork is pretty fast (where it isn't just fork), even if it is a glatic scale kludge.
exec , or execve is the slow one. Dog slow. Namei lookups, tons of MMU diddling, normally a lot of disk I/O. Oh, and we can't forget the cost of ld.so on a modern system. The dyanmic linking takes it's toll on process startup as well (of corse it can save time faulting in libc and libfoo, and it definitly helps memory starved systems).
Same here. A lot of times select/pool/kevent, and sometimes an extra process or three are way simpler to debug. Most of the time even. But it is (many times) simpler to write threaded code then event loop code, but you can pay for it for a long time in debugging. Other times the threded code can run a whole whole whole lot faster.
IEEE Floating Point has a negitave and positave zero.
Is that "fetch and incr address", or "incr address then fetch"? Incr first has it's downsides (mainly it is in a critical path). Not that many RISC's don't have it, or almost as complex immediate displacment (which doesn't need a register writeback port).
It's good to learn a (conventional) assembly, and stright C. It gives a much better feel for way you get low level memory smashing bugs, and how they manifest. It is also nice to learn higher level languages (Java/C++), in part because they are more likely to be what you'll see on the job, and in part because they let you do bigger class projects, and in part because it lets you see language design gone not-quite-really-bad.
Oops. I guess I didn't add a whole lot to the thread there then, did I?
In '90 whatever all-singing all-dancing app the University of Maryland had for the PC (I think it was a Microsoft product) let you trace a program and look at the stack. It had nothing like core files. In the ten years since then it, or a competing product (CodeWarrier?) may have grown it.
To tie that in with another thread, the UofMD's CS classes were mostly focused on datastructors/algos/proving-trivally-simple-progra ms-correct/vague-concepts/some-language-skill. Most the the classes used Unix, the two intro classes used a truly nasty-unplesent PC baised CF-Pascal, a few other classes (incl assembly) used the IBM 370s. In all a satisfyingly diverse set of boxes. I missed getting to use a ones complment box by a few years, or writing a PDP-11 OS by (about) a year.
In '97ish I tryed to pick up some Microsoft programming skill by getting the student/amature version of Code Warrier. It didn't do core dumps either. In fact the program under debug could crash the debugger (and OS)! Even if it was Java code! Later I tryed Symentac's java product, and it was just as screwed (but much faster). Then I gave up and went back to Unix.
You could even do a bit of debugging if there was no source (assembly level commands with synthetic labels, and some OS call decode). It looked unplesent, in part because I find x86 assembly unplesent (after being spoiled on the 680x0 and RISCs).
Sure there is. Fuzz generates the crash, looking at a stack dump and the source shows you the reason. That worked great for the Unix paper where many of the utilities were open source, and even (some of) the closed source authors agreed to allow the papers' authors to have a look.
That doesn't seem to be panning out as well under Windows, but who knows, maybe time will tell.
As far as the send/post message stuff goes, I think it is hard to blame the windows programs from getting a message with a pointer, and dereferenceing it. It is an inelegent API when only the OS can send events, a destabalisingone if only "trusted" programs can do it, and downright stupid if any program can do it.
Few Unix OS calls return pointers. sbrk, mmap, and kevent are the only ones I can think of. I expect when they are called the pointers are checked to see if they are one of the documented error values (normally NULL, sometimes -1 cast to a pointer). I try to make sure my programs do, and think of it as a failure if I forget. I don't expect programs to check to see if they got other "bad return" values, it is rather hard to do so (you can see if it is odd -- which isn't portable -- you can install a SEGV handler and probe the range). I don't do it, and many of my programs have stood the test of time in a hostle production enviroment (of corse I take a more aggressave stance about checking network packets...). I don't find it supprising that Windows programmers don't do much pointer validity checking either.
To sum up, 100% of Windows sucks, but only 45% of the Windows applications suck. :-)
Actually at the ISP end they get a full T1 or T3 into the cloud and serve multiple customers with it (assuming there are multiple in that area, otherwise they would just get a fraction into the cloud).
That provides the ISP with a cost savings, a space savings, and somewhat less setup hassle as well.
They were not hard to find. Were not all that painful to install (they had fewer line options then a T1 let alone ISDN - the only I rember were 2-wire vs. 4-wire). May have been a worse deal then a frac. T1. Almost certonally were a worse deal then a dialup, unless you couln't FX your dial up line into a local calling area and wanted to nail the call up 24hrs/day.
Now if you want painful to install, and cost ineffectave, look into 3002 circuts (leased voice lines - I think - I never installed any, my boss did both the first, and later the last ones that UUNET ever sold).
Five years ago I had a 56K Frame Relay which came over a phsycal 56K (and it was free, at least to me). It was pretty nice. I have a 256K Frame Relay now (over a fractional T1 -- unless they changed it without me noticing) which I like a lot more. Esp. as the price hasn't changed. However that means I can't recall how close to 56Kbit/sec modems were five years ago.
Definitly depends on the RBOC. Was not a good deal from Bell Atlantic unless you were online less then about 60hrs/month. Was a great deal from one of the lame RBOCs (US Worst? Amaritech?) because their billing system didn't make it easy to do metered usage, they did flat rate.
Offer? I don't know. It has been sold though. UUNET use to sell it to one or two customers. I'm not 100% sure why, but I beleve the customers had lots of X.25 experiance, and didn't want anything else.
Well there was web hosting (UUNET had it five years ago), and fractional T1's. The frac T1 (at least in Frame Relay form) may have been phsycally a T1, but cost wise it was a totally other animal. Totally. I mean for most RBOCs there isn't even a wire-mile charge!
Five years ago you could get 56K, ISDN and Frame Relay as steps between dialup and T1. Probbably X.25 some other random X.25 services as well. I'm pretty sure Frame Relay was available a lot longer ago then five years as well.
Of corse to be honest Frame Relay use to be delevered as a physical T1 (or 56K for small FR CIRs), but it was billed very diffrently, and had diffrent bandwidth (selectable, but lower) and latency (not so selectable, and higher) from a "raw" T1. I have heard Frame Relay is frequently done as a physical DSL line now, at least in some cases.
Well, everyone and his brother showed up wanting ten times the bandwidth for half the price.
Because when the prices were driven down the bandwidth overcommit was driven up. Sure you can get 768Kbit DSL for $30/month in some places, but they (probbably) have a 100 to 1 overcommit on the bandwidth. So they craft an acceptable use policy that limits the amount of bandwith that gets used, and most people (say 98%) are happy.
The people that arn't should probbably look into ISPs that have looser AUPs, but they should also realise that there is likely to be a larger price tag on "unlimited" serveces that really are unlimited.
Does it suck that you can't get real unlimited access for cheep/free? Sure. But it sucks that I can't fly unassisted either (well, it's actually that I can't make a good landing).
Pretty much since the first offering of "unmetered access". It still cost the ISP to have you dialed in (even if it only cost a modem port and voice circuit that couldn't let me dial in while your on). So they started claming you can't run services, can't camp on the line, can't run ping scripts to keep the line up.
One was even pretty pissed at a friend of mine who ran NNTP to keep his clock in sync because it kept the line up. Of corse it didn't violate their AUP so they had to lump it (they did send threating email once a month and he sent his canned reply every month).
You can still buy dial-up accounts without that kind of restriction, but they cost per hour. Just like you can get leased lines without server restrictions (most have restrictions against wholesaling the bandwidth to others, but you can get even more expensave connections without that restriction).
Oh, it doesn't break the rules. But it is a joke. Watch the presdent's analist some time (a good movie). I wasn't involved with the naming, but I talked to the folks who did it. Hell, UUNET wan't a phone compony at the time, it was all that much more amusing to me then.
No, a quite dead project. But still intresting.
Er, unless this is a new use of TPC.INT, the original use was FAXing. Drat, now that I read your RFC that's not the one. Try RFC 1528, 1529, and 1530, and also www.tpc.int...whih of corse claims to be not currently dead. But the history section says it was dead in 1994, which is what I recall.
...
Let me get this stright, charging a lot for a domain name is a good idea, but charging a lot for a TLD is a bad idea?
TPC.INT anyone?
.ARPA our only hope...
Oh, I agree with that. What I waned to know was the diffrence between "VXD's are a bad idea unique to Windows" and "KLM's are great, Linux has them, FreeBSD has them, Solaris has them...".
Is the diffrence really "Windows programmers are morons in it for only the money", and "Linux programers are frickin' briliant"? Or is there a real technical diffrence?
Apart from terminology how is a ring 0 VxD diffrent from a kernel loadable module? Sure you need to be root to load one, but it is putting code into the kernel that gets executed on the bare metal in ring 0...