If it runs x86 code, and doesn't run IA-64 code, it's an x86. If you can't get at what's inside, then, from a programmer's standpoint, the only way in which the inside is relevant is its effect on performance (e.g. "do this, don't do that, if you want your code to run fast"). You can't write raw rops to feed to the guts of a P6, so a P6 is an x86; unless Intel lets you write raw rops to feed to the guts of a Willamette - and I really really really really really doubt they'll let you do that - it's an x86.
Merced is the code name for the first IA-64 (Itanium) chip, and McKinley is apparently the code name for its successor (Itanium II, or some other lame name?).
I guess "Hyper Pipelined Technology" is what you use when superpipelining just isn't enough; I'm waiting for UltraSuperHyperMegaDeathPipelining, myself....
This also makes higher clocking frequencies possible, however trading performance for it.
Well, ceteris paribus, higher clock frequencies do boost performance, but I guess the deeper the pipeline, the more pain you suffer if, say, you mispredict a branch and have to throw out a bunch of stuff you've sucked up into said pipeline. (The Willamette document in question speaks of better branch prediction by "effectively combining all current branch prediction schemes".)
There are an awful lot of one-off hacks that have no real internal consistancy.
Well, part of the problem is the lack of consistency between "UNIX-compatible" platforms. In particular, take a look at Motif; "Where's Motif" is a game somewhat like "Where's Waldo", except that it's not actually fun - OK, is it in/usr/dt, or/usr, or/usr/X11, or/usr/X11RN, or in some random location for third-party packages (although the "I installed package XXX in some random place" problem is generally handled in autoconf with a --with-XXX=YYY option)?
Note the quote at the beginning of the autoconf Info file:
A physicist, an engineer, and a computer scientist were discussing the nature of God. Surely a Physicist, said the physicist, because early in the Creation, God made Light; and you know, Maxwell's equations, the dual nature of electro-magnetic waves, the relativist consequences... An Engineer!, said the engineer, because before making Light, God split the Chaos into Land and Water; it takes a hell of an engineer to handle that big amount of mud, and orderly separation of solids from liquids... The computer scientist shouted: And the Chaos, where do you think it was coming from, hmm?
---Anonymous
autoconf is trying to cope with the chaos.
A complete "capabilities" API for UNIX-like systems. In other words, a programmatic way (from the language of choice) to determine how the local system compares to a set of metrics like "do I have gcc" or "is this Red Hat 6.1 or later" or "what is the standard include directory list for C++".
"Is this Red Hat 6.1 or later" isn't a capability; presumably the package cares because RH 6.1 or later behave differently from some other systems - but the package presumably cares about some particular difference, and that'd be the capability you'd want to check.
The API would, of course, have to be independent of the questions you ask it, so that arbitrary questions can be answered, perhaps with "I don't know" as an answer; the set of questions a package might need to ask about the system on which it's being built/installed is open-ended, so you can't just come up with a fixed set of questions that suffice for all packages.
Given that, either it would have to be able to somehow deduce the answers to those questions without the cooperation of the system - which means, in effect, reimplementing autoconf - or it'd have to assume that the OS and the third-party packages installed atop it would supply those answers, which would require that the OS know about this mechanism and come with answers and that third-party packages know about this mechanism and use some other API to supply answers.
(This would also require that programmers using third-party package X for their software be able to find all the questions to which third-party package X supplies answers - and hope that they don't need to ask a question about that package to which the third party in question failed to supply an answer.)
A configuration language (preferably built on something a little more powerful and flexibility than m4) which can be used to generate headers, Makefiles and other pre-processed items by using the above API.
Perhaps something along those lines (although not necessarily using an API of that sort) will come out of the Software Carpentry competition. (And, if so, it'll use Python, as per the rules of the competition.)
Realistically, your average project should not have to look like more than:
buildmode: gnome_coding_standard require: c(ansi,longlong), gtk build_lib: fizzle(fizzle.c) build: fazzle(fizzle, fazzle.c)
Unfortunately, many projects aren't necessarily "average". Ethereal, for example, doesn't "require" libpcap, it just disables packet capture if it's not present (and it has to go through some pain to try to find it); it doesn't "require" UCD or CMU SNMP, it just disables fancy dissection of SNMP packets if it doesn't find either of them, and it attempts to work with either of them; and it doesn't "require" libz, it just disables reading compressed capture files if it doesn't find it, and it requires not just libz, but a version of libz with particular functions in it, in order to support reading compressed capture files (as it doesn't just read the capture file sequentially).
Umm, the UNIX pasting thing needs to be a configurable option - personally I'm a Mac user, and I hate the "select equals copy" thing.
Does Mozilla do "select equals copy"? If so, that's irritating - what many UNIX applications do is "select equals select, and you can paste the current selection with the middle mouse button, but selecting leaves the clipboard alone - copy equals copy, and that copies to the clipboard".
I.e., if you select something, it becomes the primary selection, but does not automatically get copied to the clipboard; to copy to the clipboard, you have to do, say, control-C (or Alt-C, in Netscape Classic, sigh). The middle mouse button pastes the primary selection at the insertion point; paste, which is typically control-V (or Alt-V in Netscape Classic), pastes the clipboard at the insertion point, or replaces the current selection if there is a current selection.
(Qt, on UNIX/X, has the irritating habit of "copying" to the primary selection, rather than the clipboard, so this doesn't necessarily work correctly with Qt applications such as those that come with KDE.)
CSS is part of the DVD spec. If you make a player, it must be able to decode CSS. Also, you cannot make a player which does not verify the key in order to decode and play. Of course, you could make a player which only plays un-encrypted DVD content, but that would simply be a MPEG player.
What about a player that can decode CSS, does verify the key, but can also play un-encrypted DVD content?
The typical FreeBSD user has little need for sound support. I mean, it's normally used as a development workstation or a server.
And, of course, nobody ever uses their development workstation to play music while they're developing....:-)
One of the reasons why my home machine most often runs FreeBSD is that it looked like more work to beat the Linux on its Linux partition (Debian 2.1) into recognizing my PnP ISA sound card than was involved in getting FreeBSD 3.x to handle it (for x = 1, it involved turning PnP ISA support in the kernel, and setting it up to use Luigi's driver; that changed in 3.2 - the "turning PnP ISA support on in the kernel" step was no longer necessary...).
You know, someone ought to go back and do research on high-performance vector monitors...
I am very happy that neither my work nor my home desktop have a display that involves steering an electron beam (Hint: what do the initials "LCD" in the title of the story to which these comments are all attached refer to?).
I am unconvinced that going back to vector CRT monitors would make things better.
That way there would be no large chunks of bitmap graphics in the os
The display hardware is bitmapped anyway (I think it's harder to make a CRT that can steer the beam arbitrarily, as the old vector scopes did, than to make a raster CRT) - and intrinsically so if it's an LCD. There's going to be bitmapped graphics code somewhere at the bottom.
However, you can implement a resolution-independent layer above that, e.g. Display Postscript/NeWS or Display PDF.
Why would they write a separate filesystem for BeIA that has exactly the same features as BFS?
I'm inclined not to automatically assume people will do what one might assume to be the obvious thing; having not seen any explicit statement that it was BFS, I wasn't about to assume it must be BFS, even though I figured it was probably BFS.
the BeOS file system, as described in
Practical File System Design with the Be File System
The first chapter of said book seems to indicate that the file system in question is "the journaling file system" to which you refer, which replaced an older file system - but also speaks of the database in that older file system as "[existing] independently of the underlying hierarchical file system".
(The first chapter also says
The intent for the [the original BeBox with a Hobbit processor] was that it would be an information device that would be connected to a network, could answer your phone, and worked well with MIDI and other multimediat devices. In retrospect the original design was a mix of what we now call a "network computer" (NC) and a set-top box of sorts.
and speaks of the move to the PowerPC-based BeBox as moving into the realm of general-purpose computing; BeIA appears to move Be back to the world of "information devices".)
Another nice thing is the filesystem of BeIA, which will be database like, and allows the users to create their own file types with special attributes. This, and the ability to search for specifially search for these attributes, the system will be suited very well for technical/scientifical applications, says Heise.
That sounds somewhat like BFS, the BeOS file system, as described in Practical File System Design with the Be File System. The BeIA file system may be BFS, or a variant thereof (the Be press release says "At the foundation of BeIA are a core set of system functions, leveraged from BeOS, which talk directly to the individual hardware designs.")
Section 4.8 "Attributes" of that book says that a file (or can have) associated with it a directory (not part of the normal directory hierarchy; the only reference to it is, presumably, via the file's inode), and in that directory are files that correspond to the file's attributes, with the name of the attribute being the name of the file and the value of the attribute being the contents of the file. They later added a mechanism to store small attributes in the inode itself.
(ReiserFS might obviate the need for such a mechanism, although, from the stuff on ReiserFS, having a separate name space for attributes might be considered an anathema.)
BFS also supports indices of attributes, allowing searches for files with particular attributes.
If the Linux crowd can settle on a single standard for graphical interface and API (HOPEFULLY, the upcoming XFree86 4.0 will help this idea along)
I don't see any indication that it will - that's similar to expecting that a new x86 processor will cause the operating system world to settle on a single standard and API for all OSes that run on x86 processors.
XFree86 4.0 will not, as far as I know, come with any particular toolkit, or desktop environment built atop it blessed as the "single standard", so you'll still have KDE/Qt vs. GNOME/GTK+ vs. .
Look dude. I have seen many, many examples of sex outside of marriage.
How on earth could I avoid it in our culture? And I am adequately convinced that it is not a Good Thing.
I'm not adequately convinced. The plural of "anecdote" is not "data".
I'm also curious about examples in other Western cultures (and curious where they draw the censorship lines, what they do about Internet access in libraries, etc.; all too often, we Yanks tend to have an appallingly insular view of the world...).
Do you realize that couple having sex before marriage have something like 15 times the divorce rate of abstaining couples? Numbers.
Citation, please? I've no idea whether there are any selection effects in those numbers, for example, nor whether this is a case of "correlation is not causality".
You have to have seen some of the stuff I've seen.
Yes, there are probably Horrible Examples of Bad Things that have happened to people, possibly as a result of having had sex outside of marriage. There are also horrible examples of Bad Things that have happened to people in marriages, but I don't consider that sufficient evidence to condemn marriage....
Did I suggest banning gay community sites?
No, but all too many of the advocates of censorware would, I suspect.
you suggest that if we ban hard-core porn, we have to ban gay community.
No, I don't. I suggest that, if we need censorship, the lines need to be very carefully drawn, and that at least some of the advocates of censorship have an agenda, whether hidden or not, that involves drawing a rather wide circle around what they personally consider to be Bad Things.
Let's just say that I have had ample experience with "sex outside of heterosexual marriage" and leave it at that. (I have little desire to bare my soul to you so you can rip it to pieces).
Umm, if you're referring to your personal experience with sex outside of heterosexual marriage, then that's not the sort of exposure to which I'm referring - that's one data point. If one data point is good enough, then, well, there's a couple I know, who were together for ages before they married, who seem to have survived the experience just fine.
But one data point isn't good enough.
And you know what: you are a fool to suggest otherwise.
I wasn't suggesting anything about your personal experience. I was suggesting that one's experience with those in "sexual brokenness recovery ministries" is insufficient to draw a conclusion about whether "sex outside heterosexual marriage" is a Bad Thing; it's somewhat akin to concluding that eating raw food is always bad based on experience with those in the hospital due to food poisoning. As I said, there's more to "sex outside of heterosexual marriage" than Debbie Does Dallas or Marine Studs on Parade.
Bowever, I am deluded enough to think the average person doesn't really
want to see people getting shat upon.
I don't think the average person wants to see that, either.
I don't, however, want to see a crusade that involves keeping, say, gay kids from finding Web sites that tell them that they're not Sick, Weird, and All Alone (no, this is not equivalent to introducing them to pedophiles, say...).
I happen to believe, with considerable evidence (having been around sexual brokenness recovery ministries quite a bit),
Umm, there might be a slight selection effect here. How much of your exposure to folks who have had sex outside of heterosexual marriage took place outside "sexual brokenness recovery ministries"?
There's more to "sex outside of heterosexual marriage" than Debbie Does Dallas or Marine Studs on Parade.
Do you seriously think I should suppress my honestly held opinion that pornography is a serious problem because you happen to disagree with me?
No, but I think you should realize that merely asserting that belief isn't necessarily going to convince people, and that if somebody starts with different axioms, they're going to draw different conclusions, and they may be very unwilling to allow laws based on the conclusions drawn from your axioms to be put into force.
but you won't be able to run the latest-greatest-64-bit-only app
I don't expect many "latest-greatest-64-bit-only" applications of the sort most people would run on their laptops to come out for a while; I suspect that, for some amount of time, 64-bit apps will primarily be server apps and high-end workstation apps.
As such, doing a 64-bit lower-power processor now might not be the best use of Intel's large-but-finite funds.
Note that Willamette will be a 32-bit processor for desktops and servers as well; when they made the IA-64 announcement Intel indicated that this didn't mean the immediate end of the 32-bit x86 processors - they'd continue to develop them.
IA-64 may eventually replace x86/IA-32, including in the mobile general-purpose computer market, but I don't expect the arrival of Merced or even McKinley to instantly kill x86 (and suspect that 32-bit processors - or even 64-bit processors, e.g. various MIPS processors, running in a fashion that doesn't make much use of the 64-bitness of the processor - will be around for a while in the "embedded" marketplace, including client "appliances").
It's a code name, and Intel have been using river names from Northern California and Oregon as product code names for a while (Klamath, for the first Pentium II; Deschutes, for the first PII rev after that; Merced, which I find less of a pretentious name than "Itanium"; and probably others. I don't know whether they've branched out from Northern California and Oregion, and named "Coppermine" after the river in Nunavut, or not.)
Re:What's up with the piss-poor reporting?
on
BSD Quickies
·
· Score: 2
NEW YORK, NY -- February 2, 2000 -- Sun Microsystems Inc. today made three important announcements as part of its ongoing efforts to advance the Internet through open standards:
it is releasing the source code for a key component of the Network File System (NFS) protocol under the new Sun Industry Standards Source License; it will double the level of funding it began last year for a University of Michigan project to develop a Linux implementation of NFS version 4; and, finally, it will release its rights to the NFS trademark.
The Network File Sharing System (NFS) file access protocol - originally introduced by engineers at Sun Microsystems in 1985 - allows users the convenience of accessing and sharing remote files across the network. The key component of NFS that Sun is releasing to the open source community today is known as Transport Independent Remote Procedure Call protocol, or TI-RPC. TI-RPC is one of the foundations of NFS, and a key component of the security advancements in version 4. TI-RPC provides technology that allows developers to create efficient, network-scalable client-server applications.
(emphasis mine).
Now, they have, in fact, released pre-TI-RPC source, and older versions of the TI-RPC source, under a rather unrestrictive license; one of those is used in FreeBSD (and probably the other BSDs; I don't have 4.4-Lite source handy at home to check whether it had that source, but I think it did) for userland ONC RPC support. I don't know whether glibc has its own independent ONC RPC implementation for stuff such as NIS.
I suspect that one reason they're releasing the current version of TI-RPC is that it will presumably include an implementation of GSSAPI authentication and of the Kerberos V5 flavor of same, to use as a sample implementation, given the comments about TI-RPC being "a key component of the security advancements in version 4" (which I think might refer to stronger authentication than AUTH_UNIX a/k/a AUTH_SYS being required).
Re:Who is getting this money?
on
BSD Quickies
·
· Score: 2
And consider this: is every Linux distribution you can buy on CD made by a company that did an IPO? Who do you think released Red Hat 5.2? That was way before the Red Hat IPO. IPO has nothing to do with it, as far as I can see.
Red Hat, hell, think Debian if you're looking for an analogy to the free-software BSDs.
Some vendors allow customers to pay extra money and donate this to Debian. Others contribute a portion of sales of Debian CDs back to Debian. This is denoted under the entry 'Allows Contribution to Debian.' We hope that you will consider making a donation to Debian.
(It also says
Debian does not manufacture its own CDs, but relies on 3rd party vendors.
which is again similar to FreeBSD, at least, and perhaps the other free-software BSDs.)
Even if the Crusoe could emulate all x86 instructions, it will still be prevented from running more than one type of filesystem.
Crusoe runs whatever file systems the developers of the operating system it's running (and developers of "third-party" file systems - which, on free-software OSes, could be thought of as "file systems not in the official code base", e.g. ReiserFS for Linux) tell it to run.
Unless the code morphing includes translations from all types of filesystems to one generic filesystem
It doesn't, but many OSes (dating back at least as far as SunOS 2.0, in the mid '80's) have a "virtual file system" or "installable file system" mechanism that allows more than one file system type to run on that OS; code above the file system makes generic "read file", "write file", "remove file", etc. calls, which turn into calls to the "read file", "write file", etc. functions for the OS in question.
That's how UNIXes these days support their default on-disk file system, and the ISO 9660 file system on CD-ROMs, and remote file systems such as NFS (and SMB/CIFS, at least on Linux, with smbfs); that's how Windows NT supports the Windows 9x version of the DOS file system, and NTFS, and the ISO 9660 file system, and remote file systems such as SMB/CIFS (and NFS, with third-party add-ons); and so on.
MacOS X has, as far as I know, such a mechanism (it may or may not be the VFS mechanism in current BSDs).
But I'm not sure how this is at all relevant to Crusoe. Most OSes Crusoe is likely to run have such a "virtual file system" mechanism, but most if not all OSes Crusoe is likely to run will think they're just running on an x86 processor, and the VFS mechanism will work Just Fine on any x86 (or SPARC, or Alpha, or PowerPC, or...) processor - it doesn't require special CPU magic.
From linux-2.3.35/include/asm-ia64/ptrace.h it's obvious that IA64 has 31 general purpose regs and 31 general FPU regs!
And it's obvious from this page from a document that's been out for quite a while that it has 128 general-purpose regs and 128 floating-point regs, although it uses a register window scheme so you may have to shuffle windows to get at more than the 32 global registers and the 32 registers in the current window (at least for the general registers).
Slashdot Mirror
If it runs x86 code, and doesn't run IA-64 code, it's an x86. If you can't get at what's inside, then, from a programmer's standpoint, the only way in which the inside is relevant is its effect on performance (e.g. "do this, don't do that, if you want your code to run fast"). You can't write raw rops to feed to the guts of a P6, so a P6 is an x86; unless Intel lets you write raw rops to feed to the guts of a Willamette - and I really really really really really doubt they'll let you do that - it's an x86.
Well, you're not correct; see the Willamette Processor Software Developer's Guide, which says "Willamette is the code name for the next generation of 32-bit Intel® Intel Architecture (IA-32) processors".
Merced is the code name for the first IA-64 (Itanium) chip, and McKinley is apparently the code name for its successor (Itanium II, or some other lame name?).
That must be the "Hyper Pipelined Technology" to which the Willamette Processor Software Developer's Guide refers.
I guess "Hyper Pipelined Technology" is what you use when superpipelining just isn't enough; I'm waiting for UltraSuperHyperMegaDeathPipelining, myself....
Well, ceteris paribus, higher clock frequencies do boost performance, but I guess the deeper the pipeline, the more pain you suffer if, say, you mispredict a branch and have to throw out a bunch of stuff you've sucked up into said pipeline. (The Willamette document in question speaks of better branch prediction by "effectively combining all current branch prediction schemes".)
Well, part of the problem is the lack of consistency between "UNIX-compatible" platforms. In particular, take a look at Motif; "Where's Motif" is a game somewhat like "Where's Waldo", except that it's not actually fun - OK, is it in /usr/dt, or /usr, or /usr/X11, or /usr/X11R N, or in some random location for third-party packages (although the "I installed package XXX in some random place" problem is generally handled in autoconf with a --with-XXX= YYY option)?
Note the quote at the beginning of the autoconf Info file:
autoconf is trying to cope with the chaos.
"Is this Red Hat 6.1 or later" isn't a capability; presumably the package cares because RH 6.1 or later behave differently from some other systems - but the package presumably cares about some particular difference, and that'd be the capability you'd want to check.
The API would, of course, have to be independent of the questions you ask it, so that arbitrary questions can be answered, perhaps with "I don't know" as an answer; the set of questions a package might need to ask about the system on which it's being built/installed is open-ended, so you can't just come up with a fixed set of questions that suffice for all packages.
Given that, either it would have to be able to somehow deduce the answers to those questions without the cooperation of the system - which means, in effect, reimplementing autoconf - or it'd have to assume that the OS and the third-party packages installed atop it would supply those answers, which would require that the OS know about this mechanism and come with answers and that third-party packages know about this mechanism and use some other API to supply answers.
(This would also require that programmers using third-party package X for their software be able to find all the questions to which third-party package X supplies answers - and hope that they don't need to ask a question about that package to which the third party in question failed to supply an answer.)
Perhaps something along those lines (although not necessarily using an API of that sort) will come out of the Software Carpentry competition. (And, if so, it'll use Python, as per the rules of the competition.)
Unfortunately, many projects aren't necessarily "average". Ethereal, for example, doesn't "require" libpcap, it just disables packet capture if it's not present (and it has to go through some pain to try to find it); it doesn't "require" UCD or CMU SNMP, it just disables fancy dissection of SNMP packets if it doesn't find either of them, and it attempts to work with either of them; and it doesn't "require" libz, it just disables reading compressed capture files if it doesn't find it, and it requires not just libz, but a version of libz with particular functions in it, in order to support reading compressed capture files (as it doesn't just read the capture file sequentially).
Does Mozilla do "select equals copy"? If so, that's irritating - what many UNIX applications do is "select equals select, and you can paste the current selection with the middle mouse button, but selecting leaves the clipboard alone - copy equals copy, and that copies to the clipboard".
I.e., if you select something, it becomes the primary selection, but does not automatically get copied to the clipboard; to copy to the clipboard, you have to do, say, control-C (or Alt-C, in Netscape Classic, sigh). The middle mouse button pastes the primary selection at the insertion point; paste, which is typically control-V (or Alt-V in Netscape Classic), pastes the clipboard at the insertion point, or replaces the current selection if there is a current selection.
(Qt, on UNIX/X, has the irritating habit of "copying" to the primary selection, rather than the clipboard, so this doesn't necessarily work correctly with Qt applications such as those that come with KDE.)
What about a player that can decode CSS, does verify the key, but can also play un-encrypted DVD content?
And, of course, nobody ever uses their development workstation to play music while they're developing.... :-)
One of the reasons why my home machine most often runs FreeBSD is that it looked like more work to beat the Linux on its Linux partition (Debian 2.1) into recognizing my PnP ISA sound card than was involved in getting FreeBSD 3.x to handle it (for x = 1, it involved turning PnP ISA support in the kernel, and setting it up to use Luigi's driver; that changed in 3.2 - the "turning PnP ISA support on in the kernel" step was no longer necessary...).
I am very happy that neither my work nor my home desktop have a display that involves steering an electron beam (Hint: what do the initials "LCD" in the title of the story to which these comments are all attached refer to?).
I am unconvinced that going back to vector CRT monitors would make things better.
The display hardware is bitmapped anyway (I think it's harder to make a CRT that can steer the beam arbitrarily, as the old vector scopes did, than to make a raster CRT) - and intrinsically so if it's an LCD. There's going to be bitmapped graphics code somewhere at the bottom.
However, you can implement a resolution-independent layer above that, e.g. Display Postscript/NeWS or Display PDF.
I'm inclined not to automatically assume people will do what one might assume to be the obvious thing; having not seen any explicit statement that it was BFS, I wasn't about to assume it must be BFS, even though I figured it was probably BFS.
To quote the person to whom you're responding,
The first chapter of said book seems to indicate that the file system in question is "the journaling file system" to which you refer, which replaced an older file system - but also speaks of the database in that older file system as "[existing] independently of the underlying hierarchical file system".
(The first chapter also says
and speaks of the move to the PowerPC-based BeBox as moving into the realm of general-purpose computing; BeIA appears to move Be back to the world of "information devices".)
That sounds somewhat like BFS, the BeOS file system, as described in Practical File System Design with the Be File System. The BeIA file system may be BFS, or a variant thereof (the Be press release says "At the foundation of BeIA are a core set of system functions, leveraged from BeOS, which talk directly to the individual hardware designs.")
Section 4.8 "Attributes" of that book says that a file (or can have) associated with it a directory (not part of the normal directory hierarchy; the only reference to it is, presumably, via the file's inode), and in that directory are files that correspond to the file's attributes, with the name of the attribute being the name of the file and the value of the attribute being the contents of the file. They later added a mechanism to store small attributes in the inode itself.
(ReiserFS might obviate the need for such a mechanism, although, from the stuff on ReiserFS, having a separate name space for attributes might be considered an anathema.)
BFS also supports indices of attributes, allowing searches for files with particular attributes.
I don't see any indication that it will - that's similar to expecting that a new x86 processor will cause the operating system world to settle on a single standard and API for all OSes that run on x86 processors.
XFree86 4.0 will not, as far as I know, come with any particular toolkit, or desktop environment built atop it blessed as the "single standard", so you'll still have KDE/Qt vs. GNOME/GTK+ vs. .
I'm not adequately convinced. The plural of "anecdote" is not "data".
I'm also curious about examples in other Western cultures (and curious where they draw the censorship lines, what they do about Internet access in libraries, etc.; all too often, we Yanks tend to have an appallingly insular view of the world...).
Citation, please? I've no idea whether there are any selection effects in those numbers, for example, nor whether this is a case of "correlation is not causality".
Yes, there are probably Horrible Examples of Bad Things that have happened to people, possibly as a result of having had sex outside of marriage. There are also horrible examples of Bad Things that have happened to people in marriages, but I don't consider that sufficient evidence to condemn marriage....
No, but all too many of the advocates of censorware would, I suspect.
No, I don't. I suggest that, if we need censorship, the lines need to be very carefully drawn, and that at least some of the advocates of censorship have an agenda, whether hidden or not, that involves drawing a rather wide circle around what they personally consider to be Bad Things.
Umm, if you're referring to your personal experience with sex outside of heterosexual marriage, then that's not the sort of exposure to which I'm referring - that's one data point. If one data point is good enough, then, well, there's a couple I know, who were together for ages before they married, who seem to have survived the experience just fine.
But one data point isn't good enough.
I wasn't suggesting anything about your personal experience. I was suggesting that one's experience with those in "sexual brokenness recovery ministries" is insufficient to draw a conclusion about whether "sex outside heterosexual marriage" is a Bad Thing; it's somewhat akin to concluding that eating raw food is always bad based on experience with those in the hospital due to food poisoning. As I said, there's more to "sex outside of heterosexual marriage" than Debbie Does Dallas or Marine Studs on Parade.
I don't think the average person wants to see that, either.
I don't, however, want to see a crusade that involves keeping, say, gay kids from finding Web sites that tell them that they're not Sick, Weird, and All Alone (no, this is not equivalent to introducing them to pedophiles, say...).
Umm, there might be a slight selection effect here. How much of your exposure to folks who have had sex outside of heterosexual marriage took place outside "sexual brokenness recovery ministries"?
There's more to "sex outside of heterosexual marriage" than Debbie Does Dallas or Marine Studs on Parade.
No, but I think you should realize that merely asserting that belief isn't necessarily going to convince people, and that if somebody starts with different axioms, they're going to draw different conclusions, and they may be very unwilling to allow laws based on the conclusions drawn from your axioms to be put into force.
...and API routines not typically implemented in the kernel.
Yes, I know, that's why I mentioned it.
That's why I said "in Nunavut" and "branched out from California and Oregon"....
I don't expect many "latest-greatest-64-bit-only" applications of the sort most people would run on their laptops to come out for a while; I suspect that, for some amount of time, 64-bit apps will primarily be server apps and high-end workstation apps.
As such, doing a 64-bit lower-power processor now might not be the best use of Intel's large-but-finite funds.
Note that Willamette will be a 32-bit processor for desktops and servers as well; when they made the IA-64 announcement Intel indicated that this didn't mean the immediate end of the 32-bit x86 processors - they'd continue to develop them.
IA-64 may eventually replace x86/IA-32, including in the mobile general-purpose computer market, but I don't expect the arrival of Merced or even McKinley to instantly kill x86 (and suspect that 32-bit processors - or even 64-bit processors, e.g. various MIPS processors, running in a fashion that doesn't make much use of the 64-bitness of the processor - will be around for a while in the "embedded" marketplace, including client "appliances").
It's a code name, and Intel have been using river names from Northern California and Oregon as product code names for a while (Klamath, for the first Pentium II; Deschutes, for the first PII rev after that; Merced, which I find less of a pretentious name than "Itanium"; and probably others. I don't know whether they've branched out from Northern California and Oregion, and named "Coppermine" after the river in Nunavut, or not.)
Yes, they are. Sun's announcement says:
(emphasis mine).
Now, they have, in fact, released pre-TI-RPC source, and older versions of the TI-RPC source, under a rather unrestrictive license; one of those is used in FreeBSD (and probably the other BSDs; I don't have 4.4-Lite source handy at home to check whether it had that source, but I think it did) for userland ONC RPC support. I don't know whether glibc has its own independent ONC RPC implementation for stuff such as NIS.
I suspect that one reason they're releasing the current version of TI-RPC is that it will presumably include an implementation of GSSAPI authentication and of the Kerberos V5 flavor of same, to use as a sample implementation, given the comments about TI-RPC being "a key component of the security advancements in version 4" (which I think might refer to stronger authentication than AUTH_UNIX a/k/a AUTH_SYS being required).
"Releasing" in what sense? The NFS V2 spec and the NFS V3 spec (along with the ONC RPC spec, the XDR spec, the portmapper/RPCBIND spec, the specs for the DES and Kerberos (V4) authentication mechanisms for ONC RPC, the spec for the GSSAPI authentication mechanism in ONC RPC, and information on using Kerberos V5 as a GSSAPI flavor in ONC RPC) have been publicly available for a while. (The NFS specs also include the specs for the corresponding versions of the mount protocol, although they don't cover the small change Larry McVoy made to create V2 of the mount protocol; Sun screwed up and didn't put the lock manager protocol into the V2 spec, and the V3 spec only lists what changed between earlier versions and the lock manager V4 that goes with NFS V3, so for a while it was only available as part of an expensive X/Open document, but the "XNFS" document with it is now available online.)
Red Hat, hell, think Debian if you're looking for an analogy to the free-software BSDs.
The page on the Debian site listing vendors of CDs says:
(It also says
which is again similar to FreeBSD, at least, and perhaps the other free-software BSDs.)
Crusoe runs whatever file systems the developers of the operating system it's running (and developers of "third-party" file systems - which, on free-software OSes, could be thought of as "file systems not in the official code base", e.g. ReiserFS for Linux) tell it to run.
It doesn't, but many OSes (dating back at least as far as SunOS 2.0, in the mid '80's) have a "virtual file system" or "installable file system" mechanism that allows more than one file system type to run on that OS; code above the file system makes generic "read file", "write file", "remove file", etc. calls, which turn into calls to the "read file", "write file", etc. functions for the OS in question.
That's how UNIXes these days support their default on-disk file system, and the ISO 9660 file system on CD-ROMs, and remote file systems such as NFS (and SMB/CIFS, at least on Linux, with smbfs); that's how Windows NT supports the Windows 9x version of the DOS file system, and NTFS, and the ISO 9660 file system, and remote file systems such as SMB/CIFS (and NFS, with third-party add-ons); and so on.
MacOS X has, as far as I know, such a mechanism (it may or may not be the VFS mechanism in current BSDs).
But I'm not sure how this is at all relevant to Crusoe. Most OSes Crusoe is likely to run have such a "virtual file system" mechanism, but most if not all OSes Crusoe is likely to run will think they're just running on an x86 processor, and the VFS mechanism will work Just Fine on any x86 (or SPARC, or Alpha, or PowerPC, or...) processor - it doesn't require special CPU magic.
And it's obvious from this page from a document that's been out for quite a while that it has 128 general-purpose regs and 128 floating-point regs, although it uses a register window scheme so you may have to shuffle windows to get at more than the 32 global registers and the 32 registers in the current window (at least for the general registers).
Documentation for the user-mode side of IA-64 has been available for a while; take your choice of Intel's PDF version, HP's PDF version, or HP's HTML version.
(There's some other IA-64 documentation on the HP site, e.g. the IA-64 Software Conventions and Runtime Architecture manual and, if a link to it hasn't already been posted, (an old - August 1999) paper on "The Making of Linux/ia64".