I like configurability, I like free, I hate wizards, and I hate being coddled. But I also hate having to screw around and waste hours of my time installing a toy.
As do I, which is why the OS I'd like to have would be a free (as in speech) OS that lets me configure stuff and that doesn't require me to screw around and waste hours of my time installing stuff.
why does everyone seem to think that OS's are mutually exclusive?
...and why do people sometimes think "configurable"/"doesn't keep you from getting 'under the hood'" and "doesn't require you to screw around and waste hours of your time installing toys" are mutually exclusive?
That said, I think it's both more fun and more productive to A) expect to meet a computer halfway
Some find it "fun" to figure out things the computer should be able to figure out itself; others don't.
I've been working with computers and UNIX-flavored OSes for over 20 years, and have been doing OS code for over 20 years, and I fall into the latter category. For me, making some piece of software do something cool is fun; digging through documentation, or popping open the machine's case to figure out what hardware I have, may start out as fun, but it gets really old and tired after a while.
And, after all, isn't making software do something cool such as, well, figuring out what video card you have, and automatically setting up X to drive that video card, fun?
Or, as Alfred North Whitehead said:
Civilization advances by extending the number of important operations which we can perform without thinking about them. Operations of thought are cavalry charges in a battle - they are limited in number, they require fresh horses, and must only be made at decisive moments.
Do you really want to waste a cavalry charge figuring out what video card you have, if software running on that machine could find that out for itself? (I had the impression that on at least some modern X servers, etc. did, in fact, do that....)
(Yes, I have the source. Yes, I could probably add improvements to installation/autoconfiguration/etc. code in various pieces of software (but, in a lot of these cases, people already appear to be working on that). No, I'm not saying "dammit, it's inconvenient, fix it!", so don't even think of dragging out the tired old "don't whine, contribute!" line - I'm just saying that making a system easier for novices to use may make it easier for us to use, too. Would you rather spend time configuring your computer to make it do something it and the software it runs already supports, such as accepting input from your mouse, or writing code to make it do something it can't do at all yet?)
what would Transmeta do when Intel introduces a new opcode in their Pentium IV?
Add more code to their binary-to-binary translator software to handle that new instruction. The processor isn't doing the translation, except to the extent that it runs the translation software (see other postings of mine in this thread for the quote from the patent that speaks of "emulation software").
On a side note, why spend all of this effort to be x86 compatible when you have the source code?
Umm, because they don't have the source code to all the, say, x86-architecture programs they might want to run?
IMO open source software is going to make hardware architecture very competitive.
"Is going to make" isn't the same as "has made". Yes, typing make to get "native-Transmeta" machine code for your application may not require all the work that this patent involves, but it involves, instead, waiting for open source versions of the programs they're interested in showing up, and they may not be willing to wait for that.
i believe it even says somewhere in the patent that it is more software based than not
The patent says that "emulation software" would translate x86 or whatever code into "native Transmeta" code (see other postings of mine in this thread, many of which amount to "software translation, dammit, not hardware translation").
As such, I don't know why this need involve any FPGAs at all - the patent doesn't seem to describe a processor that can be configured at the hardware level to run arbitrary instruction sets, it appears to describe a processor that lets software (presumably running on that processor) translate other instruction sets into the native instruction set making optimistic assumptions about what the code being translated does, get exceptions if those assumptions are invalid (with the exception handler presumably doing more pessimistic translations and retrying with the new code), and not have to worry about irreversible state changes having been made by overly-optimistically-translated code.
From the comments I've been reading it seems like the patent is for a processor that would translate instructions for other processors into its own instruction set, make sure the translated instructions would work, and if so run them.
Read the patent, not the comments. Many people seem to think the processor would translate instructions itself, perhaps because the patent goes on about
a processing system having a host processor capable of executing a first instruction set to assist in running instructions of a different instruction set which is translated to the first instruction set by the host processor
but the patent later indicates that "the processor" does that translation by running translation software:
Typically, the target application is being designed for some target computer other than the host machine on which the emulator is being run. The emulator
software analyzes the target instructions, translates those instructions into instructions which may be run on the host machine, and caches those host instructions so that they may be reused.
what would it do if the translated instuction would cause an error?
Not bother storing the results of that instruction.
Would the processor just not carry the translated instructions out?
...or, at least, make it look as if it didn't.
If so, that would seem to be quite a flaw.
Why? The error could trap, and the trap handler (or code it invokes) could do whatever is necessary to simulate the what the processor being emulated would do in that error situation (although the "exceptions" they talk about aren't necessarily errors - I scrolled past one example of "native-Transmeta" code, generated from x86 code, that assumed that the code doesn't make unaligned memory references that cross a page boundary; if that happened, "either hardware or software alignment fix up" would detect this, and perhaps generate more pessimistic and slower code and restart the emulation running the new code).
They may even be planning a platform that does multi-arch emulation on a transparent hardware/microcode level, ala AS/400.
PowerPC-based AS/400's don't have microcode in the CPU, as far as I know. The older IMPI ones had two levels of what was called "microcode", but the Inside the AS/400 book by Frank Soltis (one of the architects of S/38 and AS/400) said the "vertical microcode" was just machine code and was called "microcode" for legal reasons (if it was software, IBM would have to unbundle it; it was "microcode", however, which meant they could bundle it with the hardware). The "horizontal microcode" was conventional microcode, used to implement the IMPI instruction set.
I.e., the emulation is done largely in software, by translation of the high-level "MI" instruction set into the native instruction set (IMPI or extended PowerPC), although that software was, at one point, called "microcode".
The processor described in the various Transmeta patents also appears to do that translation in software, not hardware; this patent says
Typically, the target application is being designed for some target computer other than the host machine on which the emulator is being run. The emulator
software analyzes the target instructions, translates those instructions into instructions which may be run on the host machine, and caches those host instructions so that they may be reused.
(if you dont know work out how you can add ppc to a AS400 and not recompile)
Much of the audience may not be familiar with AS/400's, so that's not necessarily much of a hint.
System/38 and AS/400 compilers generate code in a high-level pseudo instruction set; the low-level OS kernel, when told to run one of those programs, translates it into the native instruction set and runs that. (See Frank Soltis' Inside the AS/400; go to the 29th Street Press's home page and select "General Interest" under "*** ALL AS/400 TOPICS ***", and then look for that book, which they claim to have online - the URLs on that site look depressingly dynamically-generated, so I'm loath to make a direct link.)
This let them change the native instruction set from the apparently 360-flavored "IMPI" to an extended PowerPC instruction set without requiring people to recompile programs (unless they tossed out the pseudo instruction set code to save disk space).
From the various Transmeta patents, it sounds as if they're building a chip intended to be used in an environment making use of binary-to-binary translation, as the S/38 and AS/400 do, but it's not at all clear that they intend to use B2B translation in exactly the same fashion - they appear to be targeting existing low-level instruction sets, e.g. x86, rather than some high-level instruction set like the S/38 and AS/400 "MI".
That patent, plus one of the other patents (mentioned on Slashdot a while ago), seems to suggest that if what they end up building involves the patents they're filing (i.e., assuming those patents don't come from what they were working on at one time, but decided not to build), then it may be a processor with an instruction set different from that of other processors, plus something (quite possibly software, not necessarily hardware in the processor, as some appear to have inferred) that translates other instruction sets into the Transmeta instruction set, and does so "speculatively", in that it assumes that the translated code won't get a fault.
If the code does get a fault ("exception or error" - this could be an exception without being an error, e.g. a page fault), then anything that code did "speculatively" and that wouldn't have been done by the untranslated code had it gotten that exception hasn't made any permanent state change, so the fault cancels/backs out any uncommitted state changes and presumably traps to software that would do whatever is necessary to do what the untranslated code would have done.
I.e., sometimes a desktop machine with a big screen is the right answer, and sometimes a handheld device is the right answer?
Hmm. I seem to remember seeing a Slashdot thread referring to an article in which some expat Finn said, among other things
I believe in purpose-built devices. If you look, for instance, at the Nokia 9000 [Communicator], it is a cute thing, which I like, but it is not a good mobile phone and it is not a good PDA.
Perhaps he had a point? He didn't address "desktop vs. mobile", but I think that's another case where it's not necessarily the case that "convergence" is an unalloyed good - you don't necessarily want a single box that Does It All (I've read Slashdot with a Nokia 9000 whilst riding in a car - it works, but I'd rather read it on a nice big screen; I might, however, want to read some stuff "on the move", or order pizza, or whatever, on a mobile phone, or a Palm, or...).
Gary Chapman has an interesting take on the geekness-autism connection in his Digital Nation column in the Los Angeles Times: So what?...but he points at the opposing point of view: that the concerns of 'normal' people can be shallow and don't advance civilization. We need more Edisons, not more pop stars.
That's not Chapman's take, it's the take of, to use his phrase, "self-professed computer geeks":
A common reaction to the entire Asperger's debate,
among self-professed computer geeks, is a big "So what?" They typically view non-geeks as relentless self-promoters, obsessed with their own trivia such as fashion, style and money. The geeks of the world, they say, are moving society forward with new technologies, new ideas and a fierce commitment to free-thinking intelligence. The last thing we need, they say, is a "cure" for geekness, whatever its source. Even if Thomas Edison had Asperger's syndrome, we need more Edisons and not more pop stars, they argue. Maybe the geeks shall inherit the Earth.
(emphasis mine).
The emphasised parts indicate that the ones he's saying are claiming that "it's not a bug, it's a feature" are the "self-professed computer geeks"; about the only thing I see there that indicates that he might agree with them is "Maybe the geeks shall inherit the Earth", but he may just be saying that's what the "self-professed computer geeks" think.
My understanding of Interix is that it is not really an emulation layer (UNIX to Win32), but talks directly to the NT kernel (real enough?) independantly of the other subsystems.
This would allow shops with one or two older Unix network apps to running them on an NT box that's presumably capable of running other applications at the same time.
"Our acquisition of Softway?s assets is a demonstration of our commitment to provide interoperability for applications and other solutions between UNIX and Windows," said Keith White, Director of Marketing, Business and Enterprise Division at Microsoft. "While we recommend that customers migrate their software solutions to native 32-bit Windows, today's announcement allows certain customers to move rapidly to a Windows NT-based solution during that transition process."
so your comment
I have no idea how it would help you port to Win32 other than the convience of being able to run the POSIX app right there.
seems to sum up Microsoft's thinking - you don't have to port all your apps immediately, you can dump your UNIX boxes and still run your UNIX apps, and then convert them to Win32 over time.
To achieve this, they will use BSD code. (Unless what they bought already has a Linux mode...)
What Microsoft bought has no ability to run binaries for any UNIX-flavored OS; see the "Can I run any of my UNIX applications with INTERIX?" item in the INTERIX FAQ, which says:
INTERIX doesn't allow you to take UNIX binaries (Linux/BSD/SCO/AIX etc.) and run that binary on a Windows NT system. The INTERIX Software Development Kit is a source level tool that allows you to take existing open systems source code and recompile the source code into a native NT binary with little or no effort.
Surely these are the sort of questions which it should be asking!
...unless the application can be so designed as not to need those questions answered in the first place. (The easiest question to answer is the one that's not asked because its answer is irrelevant....)
On the other hand, the user should be able to choose to take fuller control and have the installation program ask more questions rather than making assumptions.
Yes, I was thinking that some way of saying "just install it" vs. "let me control" would be nice...
...although that question runs the risk of being one to which the answer might not be obvious to the novice (and it might not be obvious to them that, being novices, "just install it" is the right answer).
That's nice, but your simple command there doesn't give you any choice as to where Netscape is installed on your Linux box.
Just out of curiosity, what are the circumstances under which you wouldn't just hit the "Next" button on the install "wizard" at that point, and would, instead, specify a place to install it other than the default? I've always found that particular part of the installation process for Windows to be an irritant, but there're presumably users for whom it's a necessity (installing on a file server? Or something else?).
(The stuff that offers you various types of installations, including "Custom", is also sometimes a pain; I seem to remember not always getting a good idea from it of what the consequences of choosing different types of installations, or of choosing to or not to install some particular piece in a custom install, would be, other than "it'll take up this much disk space" - but I think I've seen the same thing installing, say, various UNIX-flavored OSes, so that's not unique to Windows.)
The debaters here have largely talked aboot software installation on Linux (as a proxy for UNIX-flavored systems in general, although others may do things differently) and Windows; how does, say, the MacOS software installation process differ?
...but perhaps also an irritating one; much nicer might be:
install_source tarball
where install_source is a script to do all of the above.
Yeah, I do that stuff by hand, but that's at least in part because I read the README and/or INSTALL first - which raises the point that it's not necessarily as simple as you describe.
Then again, a fair number of Windows programs installed with those Wonderful User-Friendly GUI Auto-Install Tools pester me with a bunch of questions about what directory I want to install the program in, blah blah blah, although at least there it offers me a default that's usually what I end up picking anyway.
Some of them also offer me different types of installs - Basic, Full, or Custom, and stuff such as that.
So not all Windows software is trivial to install, either, even with autoplay, etc.. (That stuff might, to some extent, be the equivalent of the details in a README or INSTALL file.)
So:
I think even *nix wizards might prefer a simplified installation process for software (cf. my comment about an N-step installation process that could perhaps be better automated);
Windows applications don't necessarily get it "right", either - their installation processes may have their own complications.
A better installation process than either the traditional UNIX one or the one I've seen with some Windows applications might be interesting. Is there any OS out there that's done it "right" or, at least, closer to "right"? Have some Windows applications managed to avoid an installation process that asks you lots of questions to which the answers might not be obvious? (Applications, that is, that aren't so simple as not to have to ask you questions. Or is that, perhaps, the way to simplify the installation process - Keep It [i.e, the product] Simple, Stupid?)
[from the qed/ed editor idiom g/re/p, where re stands for a regular expression, to Globally search for the Regular Expression and Print the lines containing matches to it, via Unix grep(1)]
Correct. The other answers aren't correct (especially not the one that mentioned "Gnu", given that grep existed long before the GNU project ever existed...).
Also, check out
www.getspeed.com to check out what's available and an estimate of how far you are from the Central Office.
...although note that when I gave it my ZIP code, address, and area code and exchange, it listed the SDSL services Flashcom offers, but not their cheaper ADSL services (one of which I have); the only ADSL services it listed were those from Pacific Bell Internet (who somehow managed not to get the rest of Pac Bell to tell them that I could get ADSL, unlike Flashcom, who did manage to get Pac Bell to do so).
...and he says that there won't be a single box that tries to be more than
just a digital TV and more than just an Internet access box.
If all this "Internet everywhere" talk isn't just noise, presumably nothing would be "just an Internet access box" - by and large, we don't have anything at home that's "just an electricity access box", various home appliances do various different things with the electrical power that comes into them. Your TV might get some or all of the audio/video programs it displays from the Internet, and your stereo or TV might get some or all of the audio programs it plays from the Internet; your CD player might get at a CD database over the Internet, your home computer(s) might get new software releases/distributions, financial information, e-mail, netnews, etc. over the Internet; and some or all of them might display Web pages fetched from over the Internet.
However, I don't think it's a given that there will be a single box that'll do all of them. If they all can put packets onto the Internet and get packets from the Internet, as well as putting packets onto and getting packets from an in-house LAN, there may not be any need to have a single box that Does It All.
Little, if any, of the above is original with me - it sounds like the standard Networks Everywhere noise that I seem to hear all around.
So, is the general all purpose device going to stay or will it be replaced by specific purpose devices?
Torvalds appears to be saying the latter - I don't see the contradiction in what he's saying; he says the Nokia 9000, which tries to be more general-purpose than just a cell phone or just a (wireless-connected) PDA, isn't as good as a mobile phone that's just a mobile phone or a PDA that's just a PDA, and he says that there won't be a single box that tries to be more than just a digital TV and more than just an Internet access box.
In the future the vcr, stereo, tv, computer, news paper... [insert any other information source here] will all be combined into one device.
I'm somewhat in Torvalds' camp here; I might have a single unit that serves as VCR, stereo, and TV, but I probably wouldn't want to use that unit to do all my Web access, mail reading, (on-line) newspaper reading - I might prefer, say, one of the "slates" (flat display and stylus, plus wireless connection to something) that have been popping up as prototypes (Cyrix's WebPad, that Norwegian device mentioned a short time ago on Slashdot, etc.) for much of the latter, and I might use my home computer for doing personal finance, document writing, e-mail, software development, and Internet access involved with those.
Some large, some small, but in the end , there all going to be general purpose computers.
I'm not sure I'd want or need them all to be general-purpose computers; it might be sufficient to allow a general-purpose computer to tell them stuff - or to tell a general-purpose computer stuff, e.g. letting the computer query a CD jukebox to see what CDs I own, or having the CD player, when I insert a CD, look up in my database of CDs I own to see if this is one of them and, if not, add it to the database (or not, if I tell it I've just borrowed it from somebody - and maybe another button lets me say "I like this one, remember it as one I should get").
I was under the impression that Flashcom was the CLEC here. According to your post, and from what I can understand, Flashcom is probably reselling Covad's services. Covad is the CLEC, not Flashcom.
Correct (although in my case, they're using the ILEC, Pac Bell, rather than any CLEC).
As far as I know, they're not just reselling Covad's services, though; I don't think Covad is doing the routing for them, I have the impression Covad just moves data from some ILEC's CO to Flashcom's routers.
As far as Pacbell's ATM net, they are probably referring to their own DSL service offering, which does not have anything to do with Covad, or Flashcom.
They're referring, as far as I know, to the pipe they provide between a subscriber and their ATM net, and to the ATM services they're providing to ISPs including but not limited to Pacific Bell Internet. See, for example, this diagram on Pac Bell's site, which shows the line to the CO, the DSLAM in the CO, and the ATM network - they run a PVC over that network to the ISP, or to a corporate LAN if the DSL circuit is being used for telecommuting to work rather than connecting to an ISP.
For CLECs, the picture is probably the same, except that the DSLAM belongs to the CLEC and is in the cage they rent from the ILEC, and, presumably, so does the ATM network - this page on Rhythms' Web site seems to imply that they have their own ATM network, independent of any ILEC's network.
They probably use a pots splitter
Yes, there's a splitter at my demarcation point, which sends stuff up to 4KHz, presumably, along one wire, into which my Plain Old Telephones plug, and stuff above 4KHz along another wire, into which my DSL box plugs. There's also a device at the CO that does the same; that's presumably the "Mux" in the aforementioned diagram on Pac Bell's Web site.
Which DSLAM (Pacbell's or Covad's or Rhythms' or ours hopefully some day) depends on who sends you your bill, and or who send them their bill.
Pac Bell puts a USD 39.95 item on my phone bill for DSL, so it's presumably their DSLAM. (I presume Flashcom will send me a USD 10.00 bill one of these days; they may offer "first month free", but it's been more than a month - I should call them to find out what the story is, as I don't want to have my Internet service cut off for non-payment of a bill that I never got in the first place....)
Hmm. So where exactly does Covad, say - who provide service to Flashcom, as per this item on Flashcom's site, which says
The pace at which ISPs and data CLECs are striking partnerships shows just how critical each camp is to the other's long-term prospects. The big draw for ISPs, of course, is that they get access to high-speed lines without incurring the expense of creating their own DSL networks.
"The biggest reason we don't do it ourselves is that it takes a lot of time," says Brad Sachs, president of Flashcom (www.flashcom.com), a national ISP that sells nothing but DSL services. "It's easy enough to get CLEC status. But then you have to go out and procure rights to enter the incumbent facilities. The central offices are supposed to be open, but in reality it takes a very good legal staff and a lot of patience to get access."
...
Though the CLECs say they can keep up, there are already signs of trouble. "We're all being crushed by demand," Sachs says, noting that Flashcom partners Covad and NorthPoint currently are trying to catch up on a backlog of circuit installations that numbers in the thousands. "I've got 3,000 people waiting for service today."
fit into this picture?
The impression I had was that my phone signal was split into voice and DSL portions at the CO, with the DSL portion going into Pac Bell's ATM network, running over that network to Flashcom, as per the comment
To deliver megabit speed over standard phone lines, your corporate LAN or Internet service provider will need to be connected to the Pacific Bell ATM network.
at the end of this Pac Bell page. Flashcom then routes my packets to sites elsewhere on the Internet and routes packets from those sites to me.
Pacbell does do DSL (unless they are still testing) service also, but maybe not in your area.
Pac Bell has provided Internet service (which I view as "routing packets to and from sites on the Internet, and possibly providing other services such as DNS lookup, mail service, netnews service, and the like"), and some amount of support for DSL for other ISPs, for several months now. They also , as far as I know, allow CLECs such as Covad into their COs as well.
The technology isn't nearly as important as the competition.
Which Garfinkel indicates at the end of the article:
... Ultimately, this battle will be won and lost on mundane issues like price and quality of service.
It's for these reasons, in fact, that I firmly believe companies like MediaOne should be forced to open up their cable networks to other providers. Gargantuan companies like Bell Atlantic ultimately will be able to compete against the cable modem providers: They'll just spend a lot of money to make their DSL offerings competitive with the cable systems....
He is comparing PacBell dsl (which sucks) to MediaOne's cable service.
Presumably you meant "Bell Atlantic DSL"; Garfinkel lives in Massachusetts, where Bell Atlantic is the local phone company. One reader of his wrote in from the Bay Area, but mainly spoke of bandwidth problems with cable modems out here (although, from what I can see, the biggest bandwidth problem with cable modems out here is that they have no bandwidth whatsoever to most of the Bay Area - TCI/@Home are only offering it in some areas so far).
So far, Pac Bell's service seems to have worked well for me; they're not my ISP (because, when I asked them about DSL, they gave me some line about being too far from the central office and about them lacking the facilities to provide it, and said it'd be available some time next year; when I called Flashcom, they somehow managed to get Pac Bell to get me a DSL pipe, which Pacific Bell Internet was unable to do), so I can't speak for that part of their service, but the pipe seems to stay up and to give me a pipe that's varied between 200Kbits/s and 1.5Mbits/s, with, I think, typically something between 300Kbits/s and 600Kbits/s, from their "384Kbits/s to 1.5Mbits/s in, 128Kbits/s out" service.
But, yes, Your Mileage May Vary depending on who your ISP is and who your cable company/DSL service provider (local exchange carrier, whatever) is. Garfinkel did mention that, in his article, saying, for example, about security:
The answers to these questions are, alas, quite technical and vary greatly between one cable system and another. Some of today's cable modem networks are quite secure, while others are wide open.
on the last page (and saying similar things about DSL providers), and saying, although perhaps less directly, the same thing about speed on the previous page:
That's not the end of the bandwidth story, of course. Two factors determine just how fast the Internet will seem to the average home user. The first factor is the connection between the subscriber's home computer and the ISP. But the second factor, the one that's frequently overlooked, is the connection between the ISP and the rest of the Net.
Slashdot Mirror
As do I, which is why the OS I'd like to have would be a free (as in speech) OS that lets me configure stuff and that doesn't require me to screw around and waste hours of my time installing stuff.
...and why do people sometimes think "configurable"/"doesn't keep you from getting 'under the hood'" and "doesn't require you to screw around and waste hours of your time installing toys" are mutually exclusive?
Some find it "fun" to figure out things the computer should be able to figure out itself; others don't.
I've been working with computers and UNIX-flavored OSes for over 20 years, and have been doing OS code for over 20 years, and I fall into the latter category. For me, making some piece of software do something cool is fun; digging through documentation, or popping open the machine's case to figure out what hardware I have, may start out as fun, but it gets really old and tired after a while.
And, after all, isn't making software do something cool such as, well, figuring out what video card you have, and automatically setting up X to drive that video card, fun?
Or, as Alfred North Whitehead said:
Do you really want to waste a cavalry charge figuring out what video card you have, if software running on that machine could find that out for itself? (I had the impression that on at least some modern X servers, etc. did, in fact, do that....)
(Yes, I have the source. Yes, I could probably add improvements to installation/autoconfiguration/etc. code in various pieces of software (but, in a lot of these cases, people already appear to be working on that). No, I'm not saying "dammit, it's inconvenient, fix it!", so don't even think of dragging out the tired old "don't whine, contribute!" line - I'm just saying that making a system easier for novices to use may make it easier for us to use, too. Would you rather spend time configuring your computer to make it do something it and the software it runs already supports, such as accepting input from your mouse, or writing code to make it do something it can't do at all yet?)
Add more code to their binary-to-binary translator software to handle that new instruction. The processor isn't doing the translation, except to the extent that it runs the translation software (see other postings of mine in this thread for the quote from the patent that speaks of "emulation software").
Umm, because they don't have the source code to all the, say, x86-architecture programs they might want to run?
"Is going to make" isn't the same as "has made". Yes, typing make to get "native-Transmeta" machine code for your application may not require all the work that this patent involves, but it involves, instead, waiting for open source versions of the programs they're interested in showing up, and they may not be willing to wait for that.
The patent says that "emulation software" would translate x86 or whatever code into "native Transmeta" code (see other postings of mine in this thread, many of which amount to "software translation, dammit, not hardware translation").
As such, I don't know why this need involve any FPGAs at all - the patent doesn't seem to describe a processor that can be configured at the hardware level to run arbitrary instruction sets, it appears to describe a processor that lets software (presumably running on that processor) translate other instruction sets into the native instruction set making optimistic assumptions about what the code being translated does, get exceptions if those assumptions are invalid (with the exception handler presumably doing more pessimistic translations and retrying with the new code), and not have to worry about irreversible state changes having been made by overly-optimistically-translated code.
Read the patent, not the comments. Many people seem to think the processor would translate instructions itself, perhaps because the patent goes on about
but the patent later indicates that "the processor" does that translation by running translation software:
Not bother storing the results of that instruction.
...or, at least, make it look as if it didn't.
Why? The error could trap, and the trap handler (or code it invokes) could do whatever is necessary to simulate the what the processor being emulated would do in that error situation (although the "exceptions" they talk about aren't necessarily errors - I scrolled past one example of "native-Transmeta" code, generated from x86 code, that assumed that the code doesn't make unaligned memory references that cross a page boundary; if that happened, "either hardware or software alignment fix up" would detect this, and perhaps generate more pessimistic and slower code and restart the emulation running the new code).
PowerPC-based AS/400's don't have microcode in the CPU, as far as I know. The older IMPI ones had two levels of what was called "microcode", but the Inside the AS/400 book by Frank Soltis (one of the architects of S/38 and AS/400) said the "vertical microcode" was just machine code and was called "microcode" for legal reasons (if it was software, IBM would have to unbundle it; it was "microcode", however, which meant they could bundle it with the hardware). The "horizontal microcode" was conventional microcode, used to implement the IMPI instruction set.
I.e., the emulation is done largely in software, by translation of the high-level "MI" instruction set into the native instruction set (IMPI or extended PowerPC), although that software was, at one point, called "microcode".
The processor described in the various Transmeta patents also appears to do that translation in software, not hardware; this patent says
(emphasis mine).
Much of the audience may not be familiar with AS/400's, so that's not necessarily much of a hint.
System/38 and AS/400 compilers generate code in a high-level pseudo instruction set; the low-level OS kernel, when told to run one of those programs, translates it into the native instruction set and runs that. (See Frank Soltis' Inside the AS/400; go to the 29th Street Press's home page and select "General Interest" under "*** ALL AS/400 TOPICS ***", and then look for that book, which they claim to have online - the URLs on that site look depressingly dynamically-generated, so I'm loath to make a direct link.)
This let them change the native instruction set from the apparently 360-flavored "IMPI" to an extended PowerPC instruction set without requiring people to recompile programs (unless they tossed out the pseudo instruction set code to save disk space).
From the various Transmeta patents, it sounds as if they're building a chip intended to be used in an environment making use of binary-to-binary translation, as the S/38 and AS/400 do, but it's not at all clear that they intend to use B2B translation in exactly the same fashion - they appear to be targeting existing low-level instruction sets, e.g. x86, rather than some high-level instruction set like the S/38 and AS/400 "MI".
If the code does get a fault ("exception or error" - this could be an exception without being an error, e.g. a page fault), then anything that code did "speculatively" and that wouldn't have been done by the untranslated code had it gotten that exception hasn't made any permanent state change, so the fault cancels/backs out any uncommitted state changes and presumably traps to software that would do whatever is necessary to do what the untranslated code would have done.
I.e., sometimes a desktop machine with a big screen is the right answer, and sometimes a handheld device is the right answer?
Hmm. I seem to remember seeing a Slashdot thread referring to an article in which some expat Finn said, among other things
Perhaps he had a point? He didn't address "desktop vs. mobile", but I think that's another case where it's not necessarily the case that "convergence" is an unalloyed good - you don't necessarily want a single box that Does It All (I've read Slashdot with a Nokia 9000 whilst riding in a car - it works, but I'd rather read it on a nice big screen; I might, however, want to read some stuff "on the move", or order pizza, or whatever, on a mobile phone, or a Palm, or...).
See also the "IBM Unveiling New Transcoder Technology" Slashdot article; some folks have commented that they don't necessarily want Full Frontal Slashdot on their mobile phone or PDA.
That's not Chapman's take, it's the take of, to use his phrase, "self-professed computer geeks":
(emphasis mine).
The emphasised parts indicate that the ones he's saying are claiming that "it's not a bug, it's a feature" are the "self-professed computer geeks"; about the only thing I see there that indicates that he might agree with them is "Maybe the geeks shall inherit the Earth", but he may just be saying that's what the "self-professed computer geeks" think.
Yup. See this white paper from Softway, and the diagram therein.
Yup. The press release on the acquisition says
so your comment
seems to sum up Microsoft's thinking - you don't have to port all your apps immediately, you can dump your UNIX boxes and still run your UNIX apps, and then convert them to Win32 over time.
What Microsoft bought has no ability to run binaries for any UNIX-flavored OS; see the "Can I run any of my UNIX applications with INTERIX?" item in the INTERIX FAQ, which says:
...unless the application can be so designed as not to need those questions answered in the first place. (The easiest question to answer is the one that's not asked because its answer is irrelevant....)
Yes, I was thinking that some way of saying "just install it" vs. "let me control" would be nice...
...although that question runs the risk of being one to which the answer might not be obvious to the novice (and it might not be obvious to them that, being novices, "just install it" is the right answer).
Just out of curiosity, what are the circumstances under which you wouldn't just hit the "Next" button on the install "wizard" at that point, and would, instead, specify a place to install it other than the default? I've always found that particular part of the installation process for Windows to be an irritant, but there're presumably users for whom it's a necessity (installing on a file server? Or something else?).
(The stuff that offers you various types of installations, including "Custom", is also sometimes a pain; I seem to remember not always getting a good idea from it of what the consequences of choosing different types of installations, or of choosing to or not to install some particular piece in a custom install, would be, other than "it'll take up this much disk space" - but I think I've seen the same thing installing, say, various UNIX-flavored OSes, so that's not unique to Windows.)
The debaters here have largely talked aboot software installation on Linux (as a proxy for UNIX-flavored systems in general, although others may do things differently) and Windows; how does, say, the MacOS software installation process differ?
...but perhaps also an irritating one; much nicer might be:
where install_source is a script to do all of the above.
Yeah, I do that stuff by hand, but that's at least in part because I read the README and/or INSTALL first - which raises the point that it's not necessarily as simple as you describe.
Then again, a fair number of Windows programs installed with those Wonderful User-Friendly GUI Auto-Install Tools pester me with a bunch of questions about what directory I want to install the program in, blah blah blah, although at least there it offers me a default that's usually what I end up picking anyway.
Some of them also offer me different types of installs - Basic, Full, or Custom, and stuff such as that.
So not all Windows software is trivial to install, either, even with autoplay, etc.. (That stuff might, to some extent, be the equivalent of the details in a README or INSTALL file.)
So:
A better installation process than either the traditional UNIX one or the one I've seen with some Windows applications might be interesting. Is there any OS out there that's done it "right" or, at least, closer to "right"? Have some Windows applications managed to avoid an installation process that asks you lots of questions to which the answers might not be obvious? (Applications, that is, that aren't so simple as not to have to ask you questions. Or is that, perhaps, the way to simplify the installation process - Keep It [i.e, the product] Simple, Stupid?)
Well, the other guy who said Global Regular Expression Print was right as well.
Correct. The other answers aren't correct (especially not the one that mentioned "Gnu", given that grep existed long before the GNU project ever existed...).
...although note that when I gave it my ZIP code, address, and area code and exchange, it listed the SDSL services Flashcom offers, but not their cheaper ADSL services (one of which I have); the only ADSL services it listed were those from Pacific Bell Internet (who somehow managed not to get the rest of Pac Bell to tell them that I could get ADSL, unlike Flashcom, who did manage to get Pac Bell to do so).
If all this "Internet everywhere" talk isn't just noise, presumably nothing would be "just an Internet access box" - by and large, we don't have anything at home that's "just an electricity access box", various home appliances do various different things with the electrical power that comes into them. Your TV might get some or all of the audio/video programs it displays from the Internet, and your stereo or TV might get some or all of the audio programs it plays from the Internet; your CD player might get at a CD database over the Internet, your home computer(s) might get new software releases/distributions, financial information, e-mail, netnews, etc. over the Internet; and some or all of them might display Web pages fetched from over the Internet.
However, I don't think it's a given that there will be a single box that'll do all of them. If they all can put packets onto the Internet and get packets from the Internet, as well as putting packets onto and getting packets from an in-house LAN, there may not be any need to have a single box that Does It All.
Little, if any, of the above is original with me - it sounds like the standard Networks Everywhere noise that I seem to hear all around.
Torvalds appears to be saying the latter - I don't see the contradiction in what he's saying; he says the Nokia 9000, which tries to be more general-purpose than just a cell phone or just a (wireless-connected) PDA, isn't as good as a mobile phone that's just a mobile phone or a PDA that's just a PDA, and he says that there won't be a single box that tries to be more than just a digital TV and more than just an Internet access box.
I'm somewhat in Torvalds' camp here; I might have a single unit that serves as VCR, stereo, and TV, but I probably wouldn't want to use that unit to do all my Web access, mail reading, (on-line) newspaper reading - I might prefer, say, one of the "slates" (flat display and stylus, plus wireless connection to something) that have been popping up as prototypes (Cyrix's WebPad, that Norwegian device mentioned a short time ago on Slashdot, etc.) for much of the latter, and I might use my home computer for doing personal finance, document writing, e-mail, software development, and Internet access involved with those.
I'm not sure I'd want or need them all to be general-purpose computers; it might be sufficient to allow a general-purpose computer to tell them stuff - or to tell a general-purpose computer stuff, e.g. letting the computer query a CD jukebox to see what CDs I own, or having the CD player, when I insert a CD, look up in my database of CDs I own to see if this is one of them and, if not, add it to the database (or not, if I tell it I've just borrowed it from somebody - and maybe another button lets me say "I like this one, remember it as one I should get").
Correct (although in my case, they're using the ILEC, Pac Bell, rather than any CLEC).
As far as I know, they're not just reselling Covad's services, though; I don't think Covad is doing the routing for them, I have the impression Covad just moves data from some ILEC's CO to Flashcom's routers.
They're referring, as far as I know, to the pipe they provide between a subscriber and their ATM net, and to the ATM services they're providing to ISPs including but not limited to Pacific Bell Internet. See, for example, this diagram on Pac Bell's site, which shows the line to the CO, the DSLAM in the CO, and the ATM network - they run a PVC over that network to the ISP, or to a corporate LAN if the DSL circuit is being used for telecommuting to work rather than connecting to an ISP.
For CLECs, the picture is probably the same, except that the DSLAM belongs to the CLEC and is in the cage they rent from the ILEC, and, presumably, so does the ATM network - this page on Rhythms' Web site seems to imply that they have their own ATM network, independent of any ILEC's network.
Yes, there's a splitter at my demarcation point, which sends stuff up to 4KHz, presumably, along one wire, into which my Plain Old Telephones plug, and stuff above 4KHz along another wire, into which my DSL box plugs. There's also a device at the CO that does the same; that's presumably the "Mux" in the aforementioned diagram on Pac Bell's Web site.
Pac Bell puts a USD 39.95 item on my phone bill for DSL, so it's presumably their DSLAM. (I presume Flashcom will send me a USD 10.00 bill one of these days; they may offer "first month free", but it's been more than a month - I should call them to find out what the story is, as I don't want to have my Internet service cut off for non-payment of a bill that I never got in the first place....)
Hmm. So where exactly does Covad, say - who provide service to Flashcom, as per this item on Flashcom's site, which says
fit into this picture?
The impression I had was that my phone signal was split into voice and DSL portions at the CO, with the DSL portion going into Pac Bell's ATM network, running over that network to Flashcom, as per the comment
at the end of this Pac Bell page. Flashcom then routes my packets to sites elsewhere on the Internet and routes packets from those sites to me.
Pac Bell has provided Internet service (which I view as "routing packets to and from sites on the Internet, and possibly providing other services such as DNS lookup, mail service, netnews service, and the like"), and some amount of support for DSL for other ISPs, for several months now. They also , as far as I know, allow CLECs such as Covad into their COs as well.
Which Garfinkel indicates at the end of the article:
Presumably you meant "Bell Atlantic DSL"; Garfinkel lives in Massachusetts, where Bell Atlantic is the local phone company. One reader of his wrote in from the Bay Area, but mainly spoke of bandwidth problems with cable modems out here (although, from what I can see, the biggest bandwidth problem with cable modems out here is that they have no bandwidth whatsoever to most of the Bay Area - TCI/@Home are only offering it in some areas so far).
So far, Pac Bell's service seems to have worked well for me; they're not my ISP (because, when I asked them about DSL, they gave me some line about being too far from the central office and about them lacking the facilities to provide it, and said it'd be available some time next year; when I called Flashcom, they somehow managed to get Pac Bell to get me a DSL pipe, which Pacific Bell Internet was unable to do), so I can't speak for that part of their service, but the pipe seems to stay up and to give me a pipe that's varied between 200Kbits/s and 1.5Mbits/s, with, I think, typically something between 300Kbits/s and 600Kbits/s, from their "384Kbits/s to 1.5Mbits/s in, 128Kbits/s out" service.
But, yes, Your Mileage May Vary depending on who your ISP is and who your cable company/DSL service provider (local exchange carrier, whatever) is. Garfinkel did mention that, in his article, saying, for example, about security:
on the last page (and saying similar things about DSL providers), and saying, although perhaps less directly, the same thing about speed on the previous page: