A couple of months later, if you need another server like this, perhaps for a different customer, you might end up with different versions of the tools even though you're running the same version of FreeBSD at both sites.
If you don't like that you can go to the first system and make packages out of the installed ports (literally type "make packages") and install them on the second system. There are more details in the article here.
not exactly true. MS can still evolve windows all it likes, but doing so for the sole intention of buggering competitors (WINE) wont be as simple as it was.
I said "reduces", and I ment it in general. In this alternate fantisy world where WINE matters big time if MS wants to add a new documented feature to the Windows API that makes people lives easier, but is a pain to implment under WINE for any reason (even just "it's a hard thing", not "MS picked something hard to do under WINE to screw people") then there will be resitance to using it.
Sort of like how Linx and FreeBSD both have a sendfile syscall, but many other Unixish OSes don't have one, so it tends to be "under used". Sure it may be the most efficent way to do the job, but because it isn't universal it doesn't get used everywhere it "should".
Not the worst thing in the world, but not a good thing either.
It means the emulator is getting better and better, so theres a good chance that more and more apps will work with it, which decreases MS's competitive advantage.
It also means large visible customers for some large visible apps are using WINE, so if the next version of that app fails to work under WINE there will be some pressure on the app vender to make it work (as well as the ever present pressure on the WINE project).
If that becomes common enough it will create a large disincentive to use any secret APIs MS may choose to share with a select few vendors because the venders will learn that using those APIs will upset a bunch of their customers and make getting those customers to upgrade (and pay them!) will be harder. That is very very good.
It may well pave the way for WINE to be one of the common test lab setups for Windows software venders. Maybe they may someday even start to list "Red Hat FOO WINE version BAR" as a "supported operations system". That would be good. Not as good as a non-Windows API version of the software though.
It will also create as (not as large) disincentive for venders to use new (documented) APIs that they aren't sure if WINE has implemented. That reduces MS's ability to evolve windows, and while that may make it easier for Linux (and other OSes) to "beat" Windows, it does so in a way that reduces the end user benefit. That's not so good.
t doesn't have to be free. McDonalds for instance has a WiFi system where you can order 15 minutes of access for a small fee with your meal. The register just prints a unique number that you put into the web frontend for the NAT system and it gives you a new DHCP lease which is good for 15 minutes.
Right, but it costs McD's more to sell you 15 minutes of access then to give it away. Since they sell it they need to find out if you bought it before they let you use it. So they need to somehow associate your WiFi card's MAC to the "small fee". I susspect they don't have you read off the 12 hex digits (48 bit address, right?) when you buy your big mac. They have to do something more complex. Like maybe provide DNS to everyone, and make a web proxy that sends any "we don't think you have payed the small fee" users to a page where they can enter in some number off of their reciept to get their 15 minutes. Doesn't sound too complex, but it is some work to design the software. Plus what if you didn't have a web browser up, you just wanted to check email? Well you can't until you use the web browser. What if your mail software needs to be kicked again after it gets turned down? And what if you aren;t a geek buy someone who has to be told how to do that the first time? Or what if McD's software crashes when it gets more customers then the contractor thought there would be and everyone has to re-enter the numbers? Or all manner of other minor problems? They all need some sort of customer support right? That's not free, and none of it would have been needed if they gave the access away.
So that "small fee" is definitly not pure profit compaired to giving the service away. It may not even pay for the cost of collecting itself. Of corse on the other hand it does keep someone who might live in "Super Cantenna" distance of a WiFi McD's from getting 24 hour free service which may well cost McD's a lot more then collecting small fees from everyone else...
So free, or small fee depends more on how worried you are about free riders, and about getting people to stay in the store longer.
What's the advantage compared to the current system where the library files have the version in their name, and the dynamic loader chooses the version most appropriate to the program? You know, with the right linker flags the programmer can even specify if they want the same exact version, or only a compatible one (ie the same major version, and the same or later minor version).
It would (I assume!) apply to files other then just library files. You know config files, executbles used by shell scripts, desktop theme sets, jpeg files, header files.
Also (from the site's text) since the dependency info is encoded somewhere the kernel can spot it something like a cron job can tell you which files are not used by any packages (I assume this would only be used for directories like/usr/local/lib, not people's home directories).
The proposed new messaging layer sounds really interesting and powerful. A little like Mach or QNX, perhaps? Many kernel methods and system calls will use messaging instead of traditional brittle techniques that often lead to API problems down the road.
It is intresting and powerful, but there is no good reason the existing API methods are any more fragile then the proposed messaging system.
I think one of Dragonfly's main arguments that messages are better is some API calls pass structs and when there is a need to chage the struct to add features old code breaks. I'm pretty sure stat is used as an example. Now I beleve it is true that compatability is broken from time to time because of this sort of issue, but I strongly beleve that it is needlessly broken.
If you need to change the stat structure (say file sizes change from 32 bits to 64 -- I know, it is already 64, but it's an example, work with me here!) there is a way to keep it compatable. You allocate a new syscall number to deal with the new stat struct and leave the old syscall number around for the old stat structure. Yes this bloats the kernal a tiny bit (esp if you handle 32 bit overflows by doing anythign smarter then just giving back the low 32 bits!), but it does work.
What the message passing method ends up doing is doing the same work in a kernel-protected (and I assume kernel loaded!) chunk of userland code. I'm not sure it is less bloat, even if it is more elligant.
I do think other aspects of message passing may be quite useful, but as a answer to the "brittle API problem", it seems like a huge amount of overkill.
you mean like VMS? I think the VMS filesystem did file versioning similar to this.
Nope, VMS did file versioning, and you could look at old versions of VMS files (as long as nobody deleted the "backups"), and it was useful. But that isn't what this is.
What is proposed for Dragonfly is when your application looks at/usr/local/lib it sees the libs it's package defined and no other files in/usr/local/lib.
VMS had one "file name space", Dragonfly has one per package (or at least might have a new one for any given package).
I'm not sure how this will interact with things like wanting to build a new program when there are multiple versions of GNOME installed with different versions of libgtk and diffrent include files. I guess you will "somehow" have to tell gcc (or the make that runs it, or the shell that runs the make that runs gcc) what file name space you want.
I'm also not so sure how that will inteact with other parts of the system that want to see everything, liek say tar or whatever you use for backups. I understand how they could see libfoo.so.4.7 and libfoo.so.4.8 in one directory, but I'm unclear on how it would see/usr/local/include/foo.h when there are two foo.h files there. Maybe the package system will insist they are installed in different places in the "real file name space" and just map them into the "same place" in the file name space for packages.
Anyway don't think "VMS Backups", think "Plan 9's per-process mountable filesystems" (I think also invented - or at least used - in BSD/OS for SCO compatability, and later in FreeBSD as part of the Linux compatability)
Indirecting through them is quite fast, copying them is much more costly then for normal pointers (because there is a reference count involved), but the total work is still quite tiny. Throwing them away again is much more costly (there is actually a real destructor, and it decrements a value as opposed to the normal "do absolutely nothing at all"). However in real use I have a program that used 2.7% of the CPU before using boost's implementation of them, and it went all the way up to 2.7% afterwards. So at least in my case it was unmesurable.
Anyway as it is just a library issue, and a freely re-distributable open source implementation is available now (I think boost uses a BSDL like license), why wait for C++0x?
Boost also has a lot of other useful stuff in it, and a lot of stuff I don't find useful. It is worth some time to poke through though.
Would someone care to explain the differences/similarities between this and the new Linux (2.5) threads implementation?
Linux has one kernel thread per thread-the-user-program-thinks-it-has ("apparent threads"). The old pthreads lib had one kernel level thread per process no matter how many apparent threads there are. The new KSE has some threads per process, but that can be far fewer then the number of apparent threads.
Having one kernel thread per apparent thread means you don't need non-blocking kernel interfaces for everything and you can have one thread running per CPU (at least if locking doesn't get in the way). It also means there is a lot more kernel overhead (non swappable structores and the like), and that the kernel has to make all the scheduling choices (does hitting a blocking lock spin, or switch contexts? if it switches, does it make sure the lock holder is running? or even switch to a thread in the same processs?)
Having one kernel thread per process has lower kernel overhead and can allow some intresting thread scheduling schemes. It also has many disadvantages: you need a non-blocking API for every single kernel resource, or you end up blocking potentally thousands of threads on the request of a single thread. If you only have one process you care about being fast addinf CPUs will never help because no matter how many apparent threads you have there is only one kernel thread per process.
The new KSE model has "some number" of kernel threads per apparent thread. If it is like scheduler activations it is actually more or less one kernel thread per CPU or the number of apparent threads, whichever is smaller. So kernel overhead is reduced (it only tracks say 4 threads for a process with 100 apparent threads). It doesn't need a blocking version of evey API because when an apparent thread blocks the KSE does something simalar to sending the process a signal and the KSE that was running the blocked thread now runs the user-level scheduler which picks an apparent thread that was blocked and switches to it. That also lets one have all the advantages of user level thread schedulers. About the only downside is you can't track the apparent threads that are blocked from outside the process.
There is also a 1:1 ("Linux like") threading model using the same kernel part of the KSE stuff.
Intel does not work on gcc for x86, they have their own compiler that is free to use proprietary techniques.
Intel appears to work on gcc, they have contributed patches in the past. I remember a large and prolonged argument erupting when they made a ton of machine dependent changes to the machene independent parts of gcc and expected the patches to just be accepted. The majority of the changes eventually got transformed into patches ot the machene dependent part of gcc, or in a few cases to more proper machene independent patches, and in a few cases supercieded by other compiler changes (like the new scheduler).
I do beleve they do more work on their propritary compiler, but then agian I expect IBM does more work on their propritary compiler then on gcc.
In the past more of Apple's gcc changes have not been PPC specific (pre-compiled headers, and ObjC support), but I don't follow the gcc mailing list as closely as I use to, so it may have changed.
Huh? The author can always do that. He isn't bound by the license terms under which he allows others to use his work.
You are right only if the original author doesn't accept patches (or is offered no patches), or all of the authors of the patches assign copyright to the original author.
The MPL has as a condition of use (or maybe as a condition of modification) that anyone who changes the code grants the original author the right to do binary only releases.
For example if you patch Linux's IP stack to...um...give user level programs more control over TCP retrys (so one could make a protocol with RADIUS' requirements, but running over TCP) and Linus accepts that patch back then Linus can't release a proprietary version of Linux that uses your patch. This is true even if your patch is far far far less then 1% of the code involved.
Now lets say you take Mozilla 1.4 and patch it to spam filter mail, use IPv6, edit movies, compose novels, and make jelly donuts then AOL can make a new commercial release of Mozilla including your patch, and they don't have to release the source code to their special commercial version.
Tell me, please, how the GPL differs here from any other free source license. With all of them, anybody can make changes. Whether GPL, BSD or public domain, you have allowed others to make changes to your code base. The only difference I see is that with the GPL, you get to see their changes. The others all hide it under the rug.
The MPL for example operates like the GPL except the original author gets additional rights. Namely to make a closed source version that they can sell to whomever they like under more or less whatever licence they like. (the original author would still have to compete with anyone who wants to make a product and release the source code though)
There are not a whole lotta things licenced under the MPL, but I thought it was a very intresting licence.
Unlike the G4, where the AltiVec unit is integrated rather nicely into the issue unit, and can issue several types of vector instructions in parallel, the 970 can only do a permute in parallel with another instruction. Hence, for some tasks, I would expect the G4 to be almost twice as fast as a similarly clocked 970.
The Ars review used the CPU documentation to decide the 970's Altivec was slow. It might have missed something, like maybe the G4's Altivec is always memory starved and thus runs a 25% of it's maximum speed while the 970 has lots of memory bandwidth and thus while in thery is only 50% as fast as the G4's, that manages to be 2x what the G4 really does.
Of corse it may well be slower (or merely "about the same"), because I'm not able to tell you how fast a CPU is from the pre-release docs either (I thought the TI SuperSPARC would be fast, and the P-II would be slow). Basically I'm saying "who can really tell here".
Only true of the newer BSD license: the original contains the "advertising clause", which is incompatible with the GPL. Alan Cox had a problem with this: he wanted to integrate a BSD IP stack (back before Linux had one), but at the time the BSD license wasn't GPL compatible.
That must have been a long time ago. The advertising clause went away not all that long after the USL vs. BSDI suit. Definitly before the last Linux TCP rewrite, and probbably before the one before that.
TCP stacks are hard and it's a shame Linux had to write another (at least 3 times!), but it is kind of nice to have a second reasonable quality implmentation that one can read through.
But remember that the Apple-supplied vi is really nvi, which already has multiple undo levels* and several other nice features. Buffer splitting isn't something I'd use much; whereas supporting CP1252 is a showstopper for me.
If you are saying nvi doesn't do split buffers, try:E,:E file,:N, or pretty much any "ex edit something new" command but in upper case. Once you do that control-W switches buffers, and you might want to look at:fg,:bg, and:resize
If you want to be a host, then you have to essentially replicate what the major OS vendors have done as far as driver support and such.[...]Then there is the issue of drivers.
These issues apply equally to USB and FireWire. If your FireWire video camera wants to be able to spool video to a FireWire disk drive it needs to have enough of an OS to find other FireWire devices, find the disk, and deal with filesystems on it. If you make a PDA that sync's over FW and you want to add printing support it needs drivers for diffrent kinds of printers... (the other issues FW is better for, except maybe price, and the 4pin/6pin thing)
Consumer grade DSL or cable connections are typically not fast enough to push the boundaries of what TCP is capable enough, so there probably wouldn't be much benefit from using Fast TCP there (a guess; I haven't looked at the Fast TCP specifics yet.) In other words, ordinary TCP is already capable of saturating a consumer grade DSL or cable connection. Where ordinary TCP has difficulties (well, one of the places it has difficulties) is saturating long-distance, high-bandwidth connections without using multiple streams.
Consumer grade connections may or may not see a gain from Fast TCP, but even if one thinks it won't, it is a very very good idea to make sure it doesn't see a loss. If you can verify it "isn't worse" you can lobby OS venders and router venders to start deploying it. Granted with "no gain" you are likely to only see it in the free OSes, and in whatever router vender supplies Internet2 with their backbone routers, but still... in the (possably unexpected) "it's better" case you could expect faster deployment...
One: start their own ISP. (Bad idea. Been done. Failed.)
At the time the iMac first came out "all" Earthlink (and many other ISPs) did was buy dial-up PPP service from UUNET and resell it to their customers, plus the hard work of advertising the service, signing people up, and handling tech-support for modem users.
It definitly was a faster way to get nation wide service then anything else (none of the other big ISPs that had their own modem banks managed to find an easy way to resell them until well after UUNET started), but I have no idea about cheaper (I wrote the software that did a lot of the work, but I didn't do any sales!)
So Apple could have been their own dial-up ISP pretty easally, they already know how to handle end-user support calls, and they could have gotten the same nation wide coverage as Earthlink had. Until dial-up went flat-rate it would have been easy for Apple to make money off selling dial-up.
Apple's story was just that they wanted to support an ISP that had been traditonally Mac-friendly. That may even be true. Or maybe there was something else to it.
Your thought was right, you get billed for all the purchases made in a day. I've not yet bought tunes on consecutive days to know if they'd lump two days together or not.
There is a 30 second comercial skip. If you do some more serious work (30 second skip is "press the right 3 magic buttons...possiabbly after searching for a show with the right magic name") you can get to the login shell on the TiVo & do all manner of stuff...including putting your own web or e-mail interface on the "record stuff" feature, or extracting video, or inserting it. It is a whole lot more work to do that though, way way more on anything other then the old series 1 stand alone models.
Jeff Hawkins (the fellow who essentially invented the Palm computer)
Hmmmmm. He seems to be the person who had the key insight to remove lots of features that were too expensive for what they could do in a palmtop computer in the mid-90s. Go, MagicCap, Zoom, and a dozen others were trying to do fancy learning handwriting recognition and failing because they didn't have enough CPU. Jeff made Grafitti and sold it on some other Palm sized computers (in fact a lot of software on my very old palmtop I bought on closeout form Price Club was from "Palm Software" (incl. Graffiti), but it predated the Palm Pilot by years)
I don't think he really invented it...he just slashed out features until the hardware could keep up. He had a similar approach at Handspring. I think it didn't work out so well because the expansion port that that phliophosphy created couldn't survive a transition from the CPU32 to the ARM (or pretty much any other CPU). Bad call when he already knew Palm was replaying the Macintosh history:-)
Yes, now that's probably the most likely example of a feature that will get dropped. Both companies have invested heavily in their respective add-on solutions. Futhermore, they would require extensive hardware modification to implement.
The SpringBoard was not the result of massave R&D. It was the raw CPU bus (driven whenever the CS2 aor CS3 lines were driven), some power lines, a mic line and the existing CF connector (I'm not even sure it was keyed diffrently).
Trvial to do on any CPU with the CPU32 bus. A giant pain on any other CPU. Basically it wouldn't be seen on an ARM baised Palm (and hell, USB would be better in most ways! CompactPCI would definitly be better -- at least with yet another form factor)
I think a "startup" nowadays needs to go ahead and have a sellable software product in hand before expecting to go anywhere, much as a startup free software product needs to have something that does usable work before it will attract a developer community.
Once a software startup has a sellable product, what do they need the IPO money for? Software has quite low production costs. If you are talking about a hardware product I can see having a working prototype and needing to go to VCs to get the money to get a production run built or something...or even for a software "service" where you need to buy a lot of server type machines and bandwidth...but for something like BitTorrent once you have the working version what do you need a ton of money for? Remember that ton of money basically costs you most of the ownership (and in many cases all of the effective control).
Slashdot Mirror
If you don't like that you can go to the first system and make packages out of the installed ports (literally type "make packages") and install them on the second system. There are more details in the article here.
I said "reduces", and I ment it in general. In this alternate fantisy world where WINE matters big time if MS wants to add a new documented feature to the Windows API that makes people lives easier, but is a pain to implment under WINE for any reason (even just "it's a hard thing", not "MS picked something hard to do under WINE to screw people") then there will be resitance to using it.
Sort of like how Linx and FreeBSD both have a sendfile syscall, but many other Unixish OSes don't have one, so it tends to be "under used". Sure it may be the most efficent way to do the job, but because it isn't universal it doesn't get used everywhere it "should".
Not the worst thing in the world, but not a good thing either.
It also means large visible customers for some large visible apps are using WINE, so if the next version of that app fails to work under WINE there will be some pressure on the app vender to make it work (as well as the ever present pressure on the WINE project).
If that becomes common enough it will create a large disincentive to use any secret APIs MS may choose to share with a select few vendors because the venders will learn that using those APIs will upset a bunch of their customers and make getting those customers to upgrade (and pay them!) will be harder. That is very very good.
It may well pave the way for WINE to be one of the common test lab setups for Windows software venders. Maybe they may someday even start to list "Red Hat FOO WINE version BAR" as a "supported operations system". That would be good. Not as good as a non-Windows API version of the software though.
It will also create as (not as large) disincentive for venders to use new (documented) APIs that they aren't sure if WINE has implemented. That reduces MS's ability to evolve windows, and while that may make it easier for Linux (and other OSes) to "beat" Windows, it does so in a way that reduces the end user benefit. That's not so good.
Right, but it costs McD's more to sell you 15 minutes of access then to give it away. Since they sell it they need to find out if you bought it before they let you use it. So they need to somehow associate your WiFi card's MAC to the "small fee". I susspect they don't have you read off the 12 hex digits (48 bit address, right?) when you buy your big mac. They have to do something more complex. Like maybe provide DNS to everyone, and make a web proxy that sends any "we don't think you have payed the small fee" users to a page where they can enter in some number off of their reciept to get their 15 minutes. Doesn't sound too complex, but it is some work to design the software. Plus what if you didn't have a web browser up, you just wanted to check email? Well you can't until you use the web browser. What if your mail software needs to be kicked again after it gets turned down? And what if you aren;t a geek buy someone who has to be told how to do that the first time? Or what if McD's software crashes when it gets more customers then the contractor thought there would be and everyone has to re-enter the numbers? Or all manner of other minor problems? They all need some sort of customer support right? That's not free, and none of it would have been needed if they gave the access away.
So that "small fee" is definitly not pure profit compaired to giving the service away. It may not even pay for the cost of collecting itself. Of corse on the other hand it does keep someone who might live in "Super Cantenna" distance of a WiFi McD's from getting 24 hour free service which may well cost McD's a lot more then collecting small fees from everyone else...
So free, or small fee depends more on how worried you are about free riders, and about getting people to stay in the store longer.
It would (I assume!) apply to files other then just library files. You know config files, executbles used by shell scripts, desktop theme sets, jpeg files, header files.
Also (from the site's text) since the dependency info is encoded somewhere the kernel can spot it something like a cron job can tell you which files are not used by any packages (I assume this would only be used for directories like /usr/local/lib, not people's home directories).
It is intresting and powerful, but there is no good reason the existing API methods are any more fragile then the proposed messaging system.
I think one of Dragonfly's main arguments that messages are better is some API calls pass structs and when there is a need to chage the struct to add features old code breaks. I'm pretty sure stat is used as an example. Now I beleve it is true that compatability is broken from time to time because of this sort of issue, but I strongly beleve that it is needlessly broken.
If you need to change the stat structure (say file sizes change from 32 bits to 64 -- I know, it is already 64, but it's an example, work with me here!) there is a way to keep it compatable. You allocate a new syscall number to deal with the new stat struct and leave the old syscall number around for the old stat structure. Yes this bloats the kernal a tiny bit (esp if you handle 32 bit overflows by doing anythign smarter then just giving back the low 32 bits!), but it does work.
What the message passing method ends up doing is doing the same work in a kernel-protected (and I assume kernel loaded!) chunk of userland code. I'm not sure it is less bloat, even if it is more elligant.
I do think other aspects of message passing may be quite useful, but as a answer to the "brittle API problem", it seems like a huge amount of overkill.
Nope, VMS did file versioning, and you could look at old versions of VMS files (as long as nobody deleted the "backups"), and it was useful. But that isn't what this is.
What is proposed for Dragonfly is when your application looks at /usr/local/lib it sees the libs it's package defined and no other files in /usr/local/lib.
VMS had one "file name space", Dragonfly has one per package (or at least might have a new one for any given package).
I'm not sure how this will interact with things like wanting to build a new program when there are multiple versions of GNOME installed with different versions of libgtk and diffrent include files. I guess you will "somehow" have to tell gcc (or the make that runs it, or the shell that runs the make that runs gcc) what file name space you want.
I'm also not so sure how that will inteact with other parts of the system that want to see everything, liek say tar or whatever you use for backups. I understand how they could see libfoo.so.4.7 and libfoo.so.4.8 in one directory, but I'm unclear on how it would see /usr/local/include/foo.h when there are two foo.h files there. Maybe the package system will insist they are installed in different places in the "real file name space" and just map them into the "same place" in the file name space for packages.
Anyway don't think "VMS Backups", think "Plan 9's per-process mountable filesystems" (I think also invented - or at least used - in BSD/OS for SCO compatability, and later in FreeBSD as part of the Linux compatability)
Indirecting through them is quite fast, copying them is much more costly then for normal pointers (because there is a reference count involved), but the total work is still quite tiny. Throwing them away again is much more costly (there is actually a real destructor, and it decrements a value as opposed to the normal "do absolutely nothing at all"). However in real use I have a program that used 2.7% of the CPU before using boost's implementation of them, and it went all the way up to 2.7% afterwards. So at least in my case it was unmesurable.
Anyway as it is just a library issue, and a freely re-distributable open source implementation is available now (I think boost uses a BSDL like license), why wait for C++0x?
Boost also has a lot of other useful stuff in it, and a lot of stuff I don't find useful. It is worth some time to poke through though.
Linux has one kernel thread per thread-the-user-program-thinks-it-has ("apparent threads"). The old pthreads lib had one kernel level thread per process no matter how many apparent threads there are. The new KSE has some threads per process, but that can be far fewer then the number of apparent threads.
Having one kernel thread per apparent thread means you don't need non-blocking kernel interfaces for everything and you can have one thread running per CPU (at least if locking doesn't get in the way). It also means there is a lot more kernel overhead (non swappable structores and the like), and that the kernel has to make all the scheduling choices (does hitting a blocking lock spin, or switch contexts? if it switches, does it make sure the lock holder is running? or even switch to a thread in the same processs?)
Having one kernel thread per process has lower kernel overhead and can allow some intresting thread scheduling schemes. It also has many disadvantages: you need a non-blocking API for every single kernel resource, or you end up blocking potentally thousands of threads on the request of a single thread. If you only have one process you care about being fast addinf CPUs will never help because no matter how many apparent threads you have there is only one kernel thread per process.
The new KSE model has "some number" of kernel threads per apparent thread. If it is like scheduler activations it is actually more or less one kernel thread per CPU or the number of apparent threads, whichever is smaller. So kernel overhead is reduced (it only tracks say 4 threads for a process with 100 apparent threads). It doesn't need a blocking version of evey API because when an apparent thread blocks the KSE does something simalar to sending the process a signal and the KSE that was running the blocked thread now runs the user-level scheduler which picks an apparent thread that was blocked and switches to it. That also lets one have all the advantages of user level thread schedulers. About the only downside is you can't track the apparent threads that are blocked from outside the process.
There is also a 1:1 ("Linux like") threading model using the same kernel part of the KSE stuff.
Intel appears to work on gcc, they have contributed patches in the past. I remember a large and prolonged argument erupting when they made a ton of machine dependent changes to the machene independent parts of gcc and expected the patches to just be accepted. The majority of the changes eventually got transformed into patches ot the machene dependent part of gcc, or in a few cases to more proper machene independent patches, and in a few cases supercieded by other compiler changes (like the new scheduler).
I do beleve they do more work on their propritary compiler, but then agian I expect IBM does more work on their propritary compiler then on gcc.
In the past more of Apple's gcc changes have not been PPC specific (pre-compiled headers, and ObjC support), but I don't follow the gcc mailing list as closely as I use to, so it may have changed.
You are right only if the original author doesn't accept patches (or is offered no patches), or all of the authors of the patches assign copyright to the original author.
The MPL has as a condition of use (or maybe as a condition of modification) that anyone who changes the code grants the original author the right to do binary only releases.
For example if you patch Linux's IP stack to...um...give user level programs more control over TCP retrys (so one could make a protocol with RADIUS' requirements, but running over TCP) and Linus accepts that patch back then Linus can't release a proprietary version of Linux that uses your patch. This is true even if your patch is far far far less then 1% of the code involved.
Now lets say you take Mozilla 1.4 and patch it to spam filter mail, use IPv6, edit movies, compose novels, and make jelly donuts then AOL can make a new commercial release of Mozilla including your patch, and they don't have to release the source code to their special commercial version.
Subtle but big difference.
The MPL for example operates like the GPL except the original author gets additional rights. Namely to make a closed source version that they can sell to whomever they like under more or less whatever licence they like. (the original author would still have to compete with anyone who wants to make a product and release the source code though)
There are not a whole lotta things licenced under the MPL, but I thought it was a very intresting licence.
The Ars review used the CPU documentation to decide the 970's Altivec was slow. It might have missed something, like maybe the G4's Altivec is always memory starved and thus runs a 25% of it's maximum speed while the 970 has lots of memory bandwidth and thus while in thery is only 50% as fast as the G4's, that manages to be 2x what the G4 really does.
Of corse it may well be slower (or merely "about the same"), because I'm not able to tell you how fast a CPU is from the pre-release docs either (I thought the TI SuperSPARC would be fast, and the P-II would be slow). Basically I'm saying "who can really tell here".
Doesn't Finland have lutefisk? I think that definitly qualifyes as a biological WMD.
That must have been a long time ago. The advertising clause went away not all that long after the USL vs. BSDI suit. Definitly before the last Linux TCP rewrite, and probbably before the one before that.
TCP stacks are hard and it's a shame Linux had to write another (at least 3 times!), but it is kind of nice to have a second reasonable quality implmentation that one can read through.
If you are saying nvi doesn't do split buffers, try :E, :E file, :N, or pretty much any "ex edit something new" command but in upper case. Once you do that control-W switches buffers, and you might want to look at :fg, :bg, and :resize
These issues apply equally to USB and FireWire. If your FireWire video camera wants to be able to spool video to a FireWire disk drive it needs to have enough of an OS to find other FireWire devices, find the disk, and deal with filesystems on it. If you make a PDA that sync's over FW and you want to add printing support it needs drivers for diffrent kinds of printers... (the other issues FW is better for, except maybe price, and the 4pin/6pin thing)
Consumer grade connections may or may not see a gain from Fast TCP, but even if one thinks it won't, it is a very very good idea to make sure it doesn't see a loss. If you can verify it "isn't worse" you can lobby OS venders and router venders to start deploying it. Granted with "no gain" you are likely to only see it in the free OSes, and in whatever router vender supplies Internet2 with their backbone routers, but still... in the (possably unexpected) "it's better" case you could expect faster deployment...
At the time the iMac first came out "all" Earthlink (and many other ISPs) did was buy dial-up PPP service from UUNET and resell it to their customers, plus the hard work of advertising the service, signing people up, and handling tech-support for modem users.
It definitly was a faster way to get nation wide service then anything else (none of the other big ISPs that had their own modem banks managed to find an easy way to resell them until well after UUNET started), but I have no idea about cheaper (I wrote the software that did a lot of the work, but I didn't do any sales!)
So Apple could have been their own dial-up ISP pretty easally, they already know how to handle end-user support calls, and they could have gotten the same nation wide coverage as Earthlink had. Until dial-up went flat-rate it would have been easy for Apple to make money off selling dial-up.
Apple's story was just that they wanted to support an ISP that had been traditonally Mac-friendly. That may even be true. Or maybe there was something else to it.
They tend to bundle charges made in 48 hour periods together.
There is a 30 second comercial skip. If you do some more serious work (30 second skip is "press the right 3 magic buttons...possiabbly after searching for a show with the right magic name") you can get to the login shell on the TiVo & do all manner of stuff...including putting your own web or e-mail interface on the "record stuff" feature, or extracting video, or inserting it. It is a whole lot more work to do that though, way way more on anything other then the old series 1 stand alone models.
Hmmmmm. He seems to be the person who had the key insight to remove lots of features that were too expensive for what they could do in a palmtop computer in the mid-90s. Go, MagicCap, Zoom, and a dozen others were trying to do fancy learning handwriting recognition and failing because they didn't have enough CPU. Jeff made Grafitti and sold it on some other Palm sized computers (in fact a lot of software on my very old palmtop I bought on closeout form Price Club was from "Palm Software" (incl. Graffiti), but it predated the Palm Pilot by years)
I don't think he really invented it...he just slashed out features until the hardware could keep up. He had a similar approach at Handspring. I think it didn't work out so well because the expansion port that that phliophosphy created couldn't survive a transition from the CPU32 to the ARM (or pretty much any other CPU). Bad call when he already knew Palm was replaying the Macintosh history :-)
I know some Palm's can back up over TCP/IP...
The SpringBoard was not the result of massave R&D. It was the raw CPU bus (driven whenever the CS2 aor CS3 lines were driven), some power lines, a mic line and the existing CF connector (I'm not even sure it was keyed diffrently).
Trvial to do on any CPU with the CPU32 bus. A giant pain on any other CPU. Basically it wouldn't be seen on an ARM baised Palm (and hell, USB would be better in most ways! CompactPCI would definitly be better -- at least with yet another form factor)
Once a software startup has a sellable product, what do they need the IPO money for? Software has quite low production costs. If you are talking about a hardware product I can see having a working prototype and needing to go to VCs to get the money to get a production run built or something...or even for a software "service" where you need to buy a lot of server type machines and bandwidth...but for something like BitTorrent once you have the working version what do you need a ton of money for? Remember that ton of money basically costs you most of the ownership (and in many cases all of the effective control).