Do your part in helping bankrupt the big telcos - got IP telephony
Hah! That's not going to do anything, since all of the big telcos are internet providers in one way or another. In fact, AT&T owns your cable company, MediaOne. They'll get your money one way or the other. --
The Internet phonejack is a card (available in ISA or PCI versions) which lets you hook up a regular phone to your PC; the card then routes your calls over your internet connection to net2phone or similar services, so you can bypass your local phone company altogether for outgoing calls (incoming calls, however, are another issue). Get a two-line phone, hook one line to the internet phonejack, the other to your regular phone line and you're set.
There won't be any hacks out "shortly after it came out"... what they are proposing would all be done in hardware, and from the looks of it, with encryption (as opposed to the current macrovision scheme). It would take a hardware device capable of decoding the data then outputting an unencrypted video data stream to the VCR or other device, unless you can re-program you VCR, which seems unlikely at best.
This differs significantly from Macrovision-type copy protections, which insert an anomoly into the analog video signal (usually a pulsing pure white signal outside of the visible screen area or else a munged colorburst) - TVs are able to display the picture fine, but the anomoly screws up the VCR and the signal that gets recorded either exhibits a large pulsing of the brightness value or else has a rainbow-type artifact smeared across it; either way, its pretty un-viewable. This scheme wouldn't let the TV display anything unless it had the decoding circuitry built in (read the article about how it potentially renders current HDTV equipment useless). This cicuitry would never be put into VCRs, which means they'll never be able to record this stuff. The MPAA and its thugs won't allow the construction of external set-top boxes to decode this data, either, since the output could easily be diverted to a recording device.
It is possible that someone will be able to write a DeCSS-type program for this scheme, but the MPAA et al have probably learned their lesson and won't make it so easy this time. --
A google search for "+iphone operating system" reveals this page that says the CIDCO iPhone uses JavaOS. It doesn't specifically talk about the InfoGear phone, but they use the same trademarked name. The InfoGear phone appears to be an updated version of the CIDCO product, and both are compared on the specifications page. --
Bus Mastering IDE technology implements logic circuitry on your motherboard to reduce CPU's work of retrieving and storing data on your hard disk drive. This technology can potentially "free up the CPU" to do other tasks in a multitasking operating system environment such as Windows* 95, Windows NT*, OS/2* etc.
You say its about making a "very standardised (sic) PC" but all of your feature requests (being able to plug-in "whatever the hell you want into it", upgradable CPU, GPU, and RAM) make the thing just as un-standardized as a regular PC. Not to mention the fact that the mere act of making it "upgradable" raises the costs considerably - all those extra sockets and connectors instead of hard-soldering components... --
And time zones, elsewhere time zones are expressed as GMT +- offset, which would make east coast USA GMT-6, but most US software expresses time zones as the offset to be added to local time to get GMT, thus making the good ol' US of A in the positives.
While I appreciate the rest of your post, I think you're confused about this point. The time zone plan you mention is part of POSIX, which is an IEEE standard - the "I" is for "International" - so it isn't a US problem.
Of course, you probably knew that and just used it to make your point... which was a good one:) --
What kind of latency could we expect from an upload / download connection?
Short answer: Its rilly, rilly bad.
Think about it. That satellite is a long way away - geosynchronous orbit is 22,236 miles up - and your packets have to up to the satillite and back down to the ground station - thats 44,472 miles one-way. The speed of light is 186,000 miles per second, so in optimal conditions, you're looking at almost 500 milliseconds for a ping to your ISP.
Games are pretty much unplayable. Large transfers are fast, as long as you don't drop any packets. Filling that pipe is a bitch! --
Whatever, crackhead... I can't belive I'm even going to dignify this crap with a response. You never backed-up your original claim that it is compliant. Your pedantic logical-jumping-through-hoops does nothing to refute my claim that it aims to be compliant - and as for my statement that you were "wrong," well, you are wrong to make unproven claims with no evidence, then trash someone else for calling you on it by saying that they didn't offer any evidence. --
Linux has been POSIX compliant since it was a hack project in Minix. But compliant and Has-Paid-Us-Lots-Of-Fees-And-Is-Certified compliant are two very different things.
Wrong. Linux has aimed to be POSIX compliant. It's close enough that most people won't notice, but until someone has poured over it, you can't be sure. Have you seen the hard copy POSIX specs? They're frikkin HUGE. Just saying "we're POSIX compliant" doesn't mean jack, despite your implication to the contrary that Linux is and "has been POSIX compliant" since day one. --
While this is not exactly a 'standard compliant' required feature, it is a feature that I would expect in any modern browser -- even a trimmed down one like this is.
Exactly. And I'm not underinformed, which is why I put "standards" in quotes. Users are more concerned with functionality than arbitrary HTML "standards", which is why IE 5.x has been so wildly successful despite the bitchings of HTML standards purists. --
Your fingers are *much* faster than your feet at operating switches, so doing this would be (no pun intended) shooting yourself in the foot. Incidentally, you fingers are also significantly faster than your thumb; a lot of Jeopardy players use their index finger rather than thumb to operate the buzzer. --
Typing in the air or on a table with some kind of gloves instead of a keyboard would take some getting used to, but would be a lot faster when you are used to it.
Uh, *why* would typing on air or a table be faster? Someone has already mentioned tactile feedback and the need for the "spring-back" effect to reduce fatigue (and think about how much your fingers would hurt if you typed on a *table*), but there is also the question of how *your* perception of the difference between the "k" and "l" keys would compared to *the computer's* ideas. Another factor in fatigue is the dreaded "gorilla arm" syndrome, which pretty much doomed touchscreens for most applications.
If you're wanting to go with a "virtual" interface, why stick with limiting concepts like a mouse and keyboard? --
OSF was supposed to use the Mach microkernel, but OSF/1 (the only commercially released adaptation of OSF) never really used it (though DEC's marketing would have you belive otherwise). You're confusing OSF (the specification) with OSF/1 (an implementation). --
IBM's multifaceted moves to Linux go a long way toward opening up the company's commercial code base. This is a far cry from the IBM of old, which once teamed up with Hewlett-Packard and Digital Equipment Corp. to create the Open Software Foundation (OSF), whose sole purpose was to splinter Unix and protect its members' respective proprietary OSes.
Bullshit. The purpose of OSF was to unify against the looming threat of SunOS/AT&T SysV integration - it would do excatly the opposite of protecting "its members' respective proprietary OSes." Sun eventually parted ways with AT&T, and OSF withered. DEC was the only company to actually release OSF for its hardware. IBM and HP eventually went with a SysV strategy anyway; Digital/Tru64 unix remains the only commercial unix that is largely based on the BSD code. --
Massive multi-CPU machines like the IBM Blue Gene you reference are never SMP. SMP machines generally have multiple CPUs sharing bus, RAM and I/O, as well as everything else a uniprocessor machine has, and therefore encounter all kinds of inefficencies as you scale up. In practice, 4 CPUs seems to be the "sweet spot" for SMP - after this you start running into the law of diminishing returns hard. You can, to an extent, code around this, by doing things like making the locks in your kernel more and more fine-grained, but this adds a lot of unnecessary overhead for machines with small numbers of CPUs and also makes the code orders-of-magnatude more complex (and hence unmanagable). "Supercomputers" generally are built with large numbers of nodes (generally with 1-4 CPUs each) that could (in theory) operate independently, with a very high speed, low latency interconnect lashing them toghether (really they are glorified clusters). This seems to be the future for high-end Unix machines: both Compaq's Wildfire (now shipping) and IBM's Regatta (coming soon) systems will feature a "cluster in a single box" type of archetecture. --
why is it that all the "interesting" stories aren't linked to from the front page? I thought I might have some categories excluded, but I don't. It isn't just me, as these "hidden" stories have almost no trolls, and hardly any comments... --
Blood type "null" already exists
on
Blood Type: NULL
·
· Score: 1
O negative blood is already "null" in that it doesn't carry the antibodies that A, B, and + (Rh) signify. --
Compaq has an excellent line of rackmount Alphaservers, from the 1U single EV6 DS10L, up to the massive 4-CPU ES40. All of them run both Tru64 Unix and Linux (as well as VMS). The DS10 is fairly cheap and extremely reliable.
Slashdot Mirror
Hah! That's not going to do anything, since all of the big telcos are internet providers in one way or another. In fact, AT&T owns your cable company, MediaOne. They'll get your money one way or the other.
--
$159
--
There won't be any hacks out "shortly after it came out"... what they are proposing would all be done in hardware, and from the looks of it, with encryption (as opposed to the current macrovision scheme). It would take a hardware device capable of decoding the data then outputting an unencrypted video data stream to the VCR or other device, unless you can re-program you VCR, which seems unlikely at best.
This differs significantly from Macrovision-type copy protections, which insert an anomoly into the analog video signal (usually a pulsing pure white signal outside of the visible screen area or else a munged colorburst) - TVs are able to display the picture fine, but the anomoly screws up the VCR and the signal that gets recorded either exhibits a large pulsing of the brightness value or else has a rainbow-type artifact smeared across it; either way, its pretty un-viewable. This scheme wouldn't let the TV display anything unless it had the decoding circuitry built in (read the article about how it potentially renders current HDTV equipment useless). This cicuitry would never be put into VCRs, which means they'll never be able to record this stuff. The MPAA and its thugs won't allow the construction of external set-top boxes to decode this data, either, since the output could easily be diverted to a recording device.
It is possible that someone will be able to write a DeCSS-type program for this scheme, but the MPAA et al have probably learned their lesson and won't make it so easy this time.
--
A google search for "+iphone operating system" reveals this page that says the CIDCO iPhone uses JavaOS. It doesn't specifically talk about the InfoGear phone, but they use the same trademarked name. The InfoGear phone appears to be an updated version of the CIDCO product, and both are compared on the specifications page.
--
You mean something like this SCSI-to-IDE bridge?
--
Bus Master IDE FAQ
--
You say its about making a "very standardised (sic) PC" but all of your feature requests (being able to plug-in "whatever the hell you want into it", upgradable CPU, GPU, and RAM) make the thing just as un-standardized as a regular PC. Not to mention the fact that the mere act of making it "upgradable" raises the costs considerably - all those extra sockets and connectors instead of hard-soldering components...
--
While I appreciate the rest of your post, I think you're confused about this point. The time zone plan you mention is part of POSIX, which is an IEEE standard - the "I" is for "International" - so it isn't a US problem.
Of course, you probably knew that and just used it to make your point... which was a good one
--
right... a ping has to come back to you also, so thats 2 round trips.
--
Short answer: Its rilly, rilly bad.
Think about it. That satellite is a long way away - geosynchronous orbit is 22,236 miles up - and your packets have to up to the satillite and back down to the ground station - thats 44,472 miles one-way. The speed of light is 186,000 miles per second, so in optimal conditions, you're looking at almost 500 milliseconds for a ping to your ISP.
Games are pretty much unplayable. Large transfers are fast, as long as you don't drop any packets. Filling that pipe is a bitch!
--
The plural of "anecdotal evidence" is not "data."
--
Whatever, crackhead... I can't belive I'm even going to dignify this crap with a response. You never backed-up your original claim that it is compliant. Your pedantic logical-jumping-through-hoops does nothing to refute my claim that it aims to be compliant - and as for my statement that you were "wrong," well, you are wrong to make unproven claims with no evidence, then trash someone else for calling you on it by saying that they didn't offer any evidence.
--
Wrong. Linux has aimed to be POSIX compliant. It's close enough that most people won't notice, but until someone has poured over it, you can't be sure. Have you seen the hard copy POSIX specs? They're frikkin HUGE. Just saying "we're POSIX compliant" doesn't mean jack, despite your implication to the contrary that Linux is and "has been POSIX compliant" since day one.
--
Um, you already mentioned it. It "can stay open for more than 15 minutes without crashing." It works. Which was my whole point in the first place.
--
Exactly. And I'm not underinformed, which is why I put "standards" in quotes. Users are more concerned with functionality than arbitrary HTML "standards", which is why IE 5.x has been so wildly successful despite the bitchings of HTML standards purists.
--
Your fingers are *much* faster than your feet at operating switches, so doing this would be (no pun intended) shooting yourself in the foot. Incidentally, you fingers are also significantly faster than your thumb; a lot of Jeopardy players use their index finger rather than thumb to operate the buzzer.
--
Uh, *why* would typing on air or a table be faster? Someone has already mentioned tactile feedback and the need for the "spring-back" effect to reduce fatigue (and think about how much your fingers would hurt if you typed on a *table*), but there is also the question of how *your* perception of the difference between the "k" and "l" keys would compared to *the computer's* ideas. Another factor in fatigue is the dreaded "gorilla arm" syndrome, which pretty much doomed touchscreens for most applications.
If you're wanting to go with a "virtual" interface, why stick with limiting concepts like a mouse and keyboard?
--
OSF was supposed to use the Mach microkernel, but OSF/1 (the only commercially released adaptation of OSF) never really used it (though DEC's marketing would have you belive otherwise). You're confusing OSF (the specification) with OSF/1 (an implementation).
--
Yeah, Ultrix was also DEC's, and was replaced by OSF/1 when DEC moved from MIPS to Alpha.
--
Bullshit. The purpose of OSF was to unify against the looming threat of SunOS/AT&T SysV integration - it would do excatly the opposite of protecting "its members' respective proprietary OSes." Sun eventually parted ways with AT&T, and OSF withered. DEC was the only company to actually release OSF for its hardware. IBM and HP eventually went with a SysV strategy anyway; Digital/Tru64 unix remains the only commercial unix that is largely based on the BSD code.
--
Massive multi-CPU machines like the IBM Blue Gene you reference are never SMP. SMP machines generally have multiple CPUs sharing bus, RAM and I/O, as well as everything else a uniprocessor machine has, and therefore encounter all kinds of inefficencies as you scale up. In practice, 4 CPUs seems to be the "sweet spot" for SMP - after this you start running into the law of diminishing returns hard. You can, to an extent, code around this, by doing things like making the locks in your kernel more and more fine-grained, but this adds a lot of unnecessary overhead for machines with small numbers of CPUs and also makes the code orders-of-magnatude more complex (and hence unmanagable). "Supercomputers" generally are built with large numbers of nodes (generally with 1-4 CPUs each) that could (in theory) operate independently, with a very high speed, low latency interconnect lashing them toghether (really they are glorified clusters). This seems to be the future for high-end Unix machines: both Compaq's Wildfire (now shipping) and IBM's Regatta (coming soon) systems will feature a "cluster in a single box" type of archetecture.
--
--
why is it that all the "interesting" stories aren't linked to from the front page? I thought I might have some categories excluded, but I don't. It isn't just me, as these "hidden" stories have almost no trolls, and hardly any comments...
--
O negative blood is already "null" in that it doesn't carry the antibodies that A, B, and + (Rh) signify.
--
Compaq has an excellent line of rackmount Alphaservers, from the 1U single EV6 DS10L, up to the massive 4-CPU ES40. All of them run both Tru64 Unix and Linux (as well as VMS). The DS10 is fairly cheap and extremely reliable.
OT: why isn't this story on the front page?
--