The relevant part seems to be section 1008, which says...
In detail, it says:
Section 1008. Prohibition on certain infringement actions
No action may be brought under this title alleging infringement of copyright based on the manufacture, importation, or distribution of a digital audio recording device, a digital audio recording medium, an analog recording device, or an analog recording medium, or based on the noncommercial use by a consumer of such a device or medium for making digital musical recordings or analog musical recordings.
However, the act says earlier:
(3) A "digital audio recording device" is any machine or device of a type commonly distributed to individuals for use by individuals, whether or not included with or as part of some other machine or device, the digital recording function of which is designed or marketed for the primary purpose of, and that is capable of, making a digital audio copied recording for private use, except for--
(A) professional model products, and (B) dictation machines, answering machines, and other audio recording equipment that is designed and marketed primarily for the creation of sound recordings resulting from the fixation of nonmusical sounds.
The RIAA page in question seems to be asserting that a computer isn't a "digital audio recording device". One could, perhaps, argue that the computer isn't the "digital audio recording device", the program that's reading the CD and writing to a file is, and that it "is designed or marketed for the primary purpose of, and that is capable of, making a digital audio copied recording for private use".
Apparently Intel designed some Multics-like capabilities into
some (not all!) members of the IA-32 series.
The ring stuff, if that's what you're referring to, is, as far as I know, in all members of the IA-32 series, unless you count embedded versions that lack a full-blown IA-32 MMU, as those might not have it.
It may not be in all members of the IA-16 series (8086/8088, 80186/80188, 80286), but that's another matter.
Re:The best thing about Multics...
on
Multics Scheduler
·
· Score: 2
It had tons of weird and wonderful features, like mapping memory to the file system.
Memory-mapped files are now present in most if not all all modern UNIX-compatible OSes, as well as Windows 9x and Windows NT/2000 - but
at the time, it was a relatively uncommon feature (TENEX might have had it as well; did any other OSes have it, e.g. TSS/360?);
Multics used it as the fundamental file access mechanism, i.e. the equivalents of read()/ReadFile() and write()/WriteFile() were implemented by copying from or to a mapped region of the file (some modern UNIXes, and NT, may, in effect, implement those calls in that fashion inside the kernel, but they still don't have the model of "file access is memory mapping").
Actually, the PDP-11 did have 3 rings of protection.
More correctly, some PDP-11's with MMUs had three protection levels (Kernel, Supervisor, and User), but most operating systems, including but not limited to UNIX, used only two of them. (I think some Digital OSes, e.g. RSX-11M Plus?, may have eventually used Supervisor mode, on machines that had it, to provide an additional address space; I don't know whether they actually used it to provide finer-grained protection levels, however. Bell Labs's MERT used supervisor mode - it ran a low-level kernel in kernel mode, and ran a UNIX kernel-level environment atop it in supervisor mode, with that environment running user-mode code in user mode - i.e., it did use it to provide finer-grained protection levels. There may have been other OSes that did so as well - KSOS?)
VAXes had four levels, and VMS, as far as I know, used all of them (kernel code in kernel mode, RMS in executive mode(?), command interpreter in supervisor mode, and userland code in user mode); UNIX, however, used only kernel and user.
It has all three forms of history, !-history, fcedit and arrows/I-search.
Does it have all four forms of history, including the fourth, non-I-search (of the sort ksh has, i.e. type control-R - yes, I want EMACS-style commands - fill in the string for which to search, and then hit the Enter key)?
I don't
personally miss ! history or arrow keys, but others might.
...but I personally dislike I-search (interactive search or incremental search, whatever the "I" stands for), which is why I personally prefer ksh to bash (and to pdksh). Others may like I-search, in which case they might prefer bash or pdksh.
That's what I detest most about ksh for interactive use. I tolerate ksh, but I sure don't like it.
I assume you're referring to the lack of the items in your subject line; I have, in my.kshrc, pushd/popd shell functions written by Fletcher Mattox (at the University of Texas at Austin). I don't personally miss ! history or arrow keys, but others might.
I write my shell scripts for/bin/sh now.
...as do I, as there's no guarantee that another machine will have any shell other than/bin/sh.
yes, my employer, NetApp, proudly participated in the marketoonery in question.
"The marketoonery in question" being the dumping of advertisements into the "comments" section, not Polygraph itself. Marketoons - can't live with them, can't send them out the airlock without a suit....
Where the hell is Novell's BorderManger in this little test?
Novell's BorderManager? Dunno.
Novell's Internet Caching System? See the Vendor Comments page on the bakeoff site, where somebody from Dell says:
The Novell Internet Caching System - Powered By Dell (Dell ICS 130B) used in the Second IRCache Web Cache Bake-off tests, is currently available from Dell Computer.
There were other boxes running it as well, e.g. at least some, perhaps all, of the IBM boxes.
(The "Vendor Comments" section seems to be filled primarily with "Vendor Advertisements"; yes, my employer, NetApp, proudly participated in the marketoonery in question.)
You may, perhaps, be thinking of Peter Danzig, who is the VP of Technology at Akamai; his bio page at Akamai says:
His background in Internet information systems also includes work on the federally-funded Harvest Information Discovery System, or 'Harvest Project.' His collaboration on this project at the University of Southern California resulted in one of the earliest designs for caching Internet backbone traffic. Danzig led the Harvest Web cache and helped design the Harvest indexer projects from 1992-1995.
I think the Squid project was originally derived from the Harvest cache; the NetApp NetCache software was also originally Harvest-derived, although much, perhaps most, of it was done at Internet Middleware (a company founded by Peter and bought by NetApp) and NetApp. (I suspect much of Squid might also be non-Harvest code.)
Those who are reading are characteristically always forgetting to guard their own mother to grab it themselves. Ruler of creeper, mortal, and scallop, this is a machine is a kludge, after all, as "wanting." it is not generally understood by less advanced life forms, and they'll show a commercial for a while.
CPU designs have been efectively free for a long time now, and that hasn't changed much. Ross was the last company to seriously try to capitalize on this idea
Please can I request that the lovely instruction in a Pentium that does the n-bit shift in one clock cycle be in the core.
The instruction in question does so because, as another poster noted, the Pentium in question has a barrel shifter (or another circuit capable of shifting n bits in one clock cycle), not because the instruction is defined in the instruction set architecture to be a one-clock-cycle shift.
I.e., what you meant to say was "Please can I request that the core have a barrel shifter so that shift instructions can shift n bits in one clock cycle?"
What does anybody know where ELF format stands at in the GNU GPL scheme of things.
"Stands" in what sense? ELF was invented by AT&T, as the object file/executable file/shared library/core dump format for System V Release 4, and was published in various SVR4 manuals; I don't think they made any patent or other claims limiting implementations of it (or, if they did, they apparently didn't get too far, as the GNU toolchain supports it and Linux and the BSDs use it).
None of that would, as far as I know, preclude Ricoh from patenting an extension to it.
It was no more radical than Acorn's guys coming up with the ARM and RISC architecture, which completely blew the lid off the CISC market.
Did ARM antedate, say, MIPS and SPARC (which I think may have been the first commercial "merchant semiconductor" RISC microprocessors)? (I suspect it didn't antedate, say, the IBM 801 research machine, or the Stanford MIPS or Berkeley RISC projects.)
Acorn may have had one of the first, and perhaps the first, personal computer with a RISC processor, however.
And indeed, you don't. No matter _where_ it is, you can use your current browser to view it. True, launching the appropriate editor against it isn't quite that easy, but that's an implementation detail.
Precisely.
So what exactly was your objection to the "desktop has no edges" notion? Are you saying one should only have this transparency when using one's "current browser"?
Well, if multiple vendors independently implement the same protocol, they can use the name of that protocol for their implementation.
As I said in my previous message, these are two presumably independent implementations of the same protocol.
(Whether "NetBEUI" is the correct name for the protocol is another matter; the IBM spec that documents it calls it "the NetBIOS Frames Protocol", and Microsoft calls it "NetBEUI Frame" in the Windows NT Server Networking Guide document in the NT Server Resource Kit:
The NetBEUI protocol was one of the earliest protocols available for use on networks composed of personal computers. In 1985, IBM introduced NetBEUI to provide a protocol that could be used with software programs designed around the Network Basic Input/Output System (NetBIOS) interface.
...
Windows NT-based NetBEUI, also referred to as NBF because it uses NetBEUI Frame (NBF), implements the IBM NetBIOS Extended User Interface (NetBEUI) 3.0 specification. This protocol provides compatibility with existing LANs that use the NetBEUI protocol and is compatible with the NetBEUI protocol driver shipped with past Microsoft networking products.
but that's another matter.)
If this truly has nothing to do with WIndows NetBEUI
It is an independent implementation of the same protocol, so it does have something to do with it. It just doesn't share code with it.
Remember when Quake was open sourced? All kinds of new ways to cheat.. Remember.. alot of closed-source software today are considered secure thru their obscruity. Open the source up, and 9 out of 10 something has to be secured for real.. no?
This doesn't ipso facto mean that there will be any new security holes (besides, the protocol was documented), and doesn't ipso facto mean that Microsoft would have to "embrace Open Source" to deal with those, unless by "embrace Open Source" you mean something other than what is normally meant by "embrace Open Source", i.e. open-source their protocol implementation.
If protocols can't be "open-sourced".. how is it that NetBEUI is being open sourced by Procom?
Because what they're open-sourcing is their implementation of an existing, documented protocol. They are NOT "open-sourcing" the protocol itself - the protocol is already publicly documented. Given that, I think that it's incorrect to say that they're "open-sourcing NetBEUI", just as it's incorrect to say that Berkeley, for example, "open-sourced TCP"; it's correct to say that they're open-sourcing their implementation of the NetBEUI (or NetBEUI Frame, or whatever) protocol.
but really, now; do you _want_ to be unable to discern where that love note to your amor at work... or your HIV test results are; whether that file is on your zip disk, your hard drive, your office fileserver... or just 'out there on the web somewhere'?
So look at the URL when you need to know that. I do not necessarily want to have to think about where something is every time I look at it.
OpenEdition (one of the newer OS upgrades) has a unix shell and all of the same functionality as you would find on a unix platform.
...except for a native character set of ASCII or a superset thereof.:-)
I don't know to what extent the ASCII/EBCDIC problem gets in the way of using the UNIX environment on OS/390 (e.g., requiring that the code be checked to make sure it doesn't assume that "A" through "Z" form a contiguous set of character codes - and doesn't assume that the characters you get in from a TCP connection from an HTTP client are in the native character set of the C compiler and the file system and...), but if it gets in the way of Just Recompiling, perhaps that was some of the rationale.
Doesn't Procom get a royality per copy of windows sold?
No, because Microsoft doesn't use Procom's implementation.
Also.. WIth NetBEUI being open sourced.. what are the odds that ALL kinds of bugs are gonna be discovered with Windows Networkig (ie. New Security Issues)?
Discovered by reading the source code? Probably not many, as a lot of the code path for handling SMB is probably in the SMB code, not the NetBEUI code - and, as indicated, the code Procom is GPLing probably isn't the code Microsoft are using (unless they licensed it from Microsoft, which I think is extremely unlikely).
What are the odds that Microsoft will now HAVE to embrace Open Source to at the very least fix their New NetBEUI security holes?
What "New NetBEUI security holes"? And why would then then "HAVE to embrace Open Source" for this?
And if Microsoft had the source-code themselves as part of their agreement with Procom (Or did they somehow get NetBEUI by other means?)..
Yeah, they got it by other means, i.e. writing an implementation thereof.
How come they were too lazy to fix all the security issues within the formally closed-source protocol
A protocol isn't "open-source" or "closed-source", it's publicly-documented or secret, and NetBEUI falls into the former category; see this document under "The NetBIOS Frames protocol".
Better than a poke in the eye with a sharp stick, I guess, but more pleasant might be a combination of smbfs and an automounter that understood SMB (knew which SMB servers had announced themselves to the browser, knew how to query an SMB server to see what shares it was offering) - that would let you use the KDE 1 file manager, or the KDE 2 file manager, or GMC, or Nautilus, or ls, or... as SMB browsers.
I really don't remember the difference/relationship between NetBEUI and the Server Message Block protocol though.
SMB requests and replies are stuffed into the payload of NetBIOS-over-NetBEUI (or "NetBIOS Frame Protocol") packets, just as they're stuffed into the payload of NetBIOS-over-TCP Datagram Service and Session Service packets, etc.. SMB doesn't, by and large, need to know or care what protocol NetBIOS runs atop.
I spoke to an MSCE friend of mine, and he says it's a MS protocol.
It may be "a MS protocol" in the sense that Microsoft uses it, but that doesn't ipso facto mean that Microsoft invented it.
(It also doesn't mean it's necessarily some Secret Proprietary Protocol that Microsoft have only just now made public; it is, in fact, not such a protocol.)
Slashdot Mirror
In detail, it says:
However, the act says earlier:
The RIAA page in question seems to be asserting that a computer isn't a "digital audio recording device". One could, perhaps, argue that the computer isn't the "digital audio recording device", the program that's reading the CD and writing to a file is, and that it "is designed or marketed for the primary purpose of, and that is capable of, making a digital audio copied recording for private use".
But I'm not a lawyer, so I don't know whether
The ring stuff, if that's what you're referring to, is, as far as I know, in all members of the IA-32 series, unless you count embedded versions that lack a full-blown IA-32 MMU, as those might not have it.
It may not be in all members of the IA-16 series (8086/8088, 80186/80188, 80286), but that's another matter.
Memory-mapped files are now present in most if not all all modern UNIX-compatible OSes, as well as Windows 9x and Windows NT/2000 - but
More correctly, some PDP-11's with MMUs had three protection levels (Kernel, Supervisor, and User), but most operating systems, including but not limited to UNIX, used only two of them. (I think some Digital OSes, e.g. RSX-11M Plus?, may have eventually used Supervisor mode, on machines that had it, to provide an additional address space; I don't know whether they actually used it to provide finer-grained protection levels, however. Bell Labs's MERT used supervisor mode - it ran a low-level kernel in kernel mode, and ran a UNIX kernel-level environment atop it in supervisor mode, with that environment running user-mode code in user mode - i.e., it did use it to provide finer-grained protection levels. There may have been other OSes that did so as well - KSOS?)
VAXes had four levels, and VMS, as far as I know, used all of them (kernel code in kernel mode, RMS in executive mode(?), command interpreter in supervisor mode, and userland code in user mode); UNIX, however, used only kernel and user.
Does it have all four forms of history, including the fourth, non-I-search (of the sort ksh has, i.e. type control-R - yes, I want EMACS-style commands - fill in the string for which to search, and then hit the Enter key)?
I.e., it's just like |& in the C shell? (|& isn't a zsh invention.)
Given that, in the Bourne shell (and compatible shells such as ksh and bash), you send both the standard output and standard error somewhere by doing
or
it's not necessarily surprising that bash doesn't use (or need) |& and that ksh uses it for something else.
...but I personally dislike I-search (interactive search or incremental search, whatever the "I" stands for), which is why I personally prefer ksh to bash (and to pdksh). Others may like I-search, in which case they might prefer bash or pdksh.
I assume you're referring to the lack of the items in your subject line; I have, in my .kshrc, pushd/popd shell functions written by Fletcher Mattox (at the University of Texas at Austin). I don't personally miss ! history or arrow keys, but others might.
...as do I, as there's no guarantee that another machine will have any shell other than /bin/sh.
Or, rather, for FreeBSD plus whatever caching code iMimic runs atop it.
"The marketoonery in question" being the dumping of advertisements into the "comments" section, not Polygraph itself. Marketoons - can't live with them, can't send them out the airlock without a suit....
Novell's BorderManager? Dunno.
Novell's Internet Caching System? See the Vendor Comments page on the bakeoff site, where somebody from Dell says:
There were other boxes running it as well, e.g. at least some, perhaps all, of the IBM boxes.
(The "Vendor Comments" section seems to be filled primarily with "Vendor Advertisements"; yes, my employer, NetApp, proudly participated in the marketoonery in question.)
The CTO of Akamai is Daniel Lewin; his bio page at Akamai says nothing about Squid.
You may, perhaps, be thinking of Peter Danzig, who is the VP of Technology at Akamai; his bio page at Akamai says:
I think the Squid project was originally derived from the Harvest cache; the NetApp NetCache software was also originally Harvest-derived, although much, perhaps most, of it was done at Internet Middleware (a company founded by Peter and bought by NetApp) and NetApp. (I suspect much of Squid might also be non-Harvest code.)
Cool! Mark V. Shaney reads Slashdot!
"Capitalize on this idea" in what sense?
The instruction in question does so because, as another poster noted, the Pentium in question has a barrel shifter (or another circuit capable of shifting n bits in one clock cycle), not because the instruction is defined in the instruction set architecture to be a one-clock-cycle shift.
I.e., what you meant to say was "Please can I request that the core have a barrel shifter so that shift instructions can shift n bits in one clock cycle?"
"Stands" in what sense? ELF was invented by AT&T, as the object file/executable file/shared library/core dump format for System V Release 4, and was published in various SVR4 manuals; I don't think they made any patent or other claims limiting implementations of it (or, if they did, they apparently didn't get too far, as the GNU toolchain supports it and Linux and the BSDs use it).
None of that would, as far as I know, preclude Ricoh from patenting an extension to it.
Did ARM antedate, say, MIPS and SPARC (which I think may have been the first commercial "merchant semiconductor" RISC microprocessors)? (I suspect it didn't antedate, say, the IBM 801 research machine, or the Stanford MIPS or Berkeley RISC projects.)
Acorn may have had one of the first, and perhaps the first, personal computer with a RISC processor, however.
Precisely.
So what exactly was your objection to the "desktop has no edges" notion? Are you saying one should only have this transparency when using one's "current browser"?
Well, if multiple vendors independently implement the same protocol, they can use the name of that protocol for their implementation.
As I said in my previous message, these are two presumably independent implementations of the same protocol.
(Whether "NetBEUI" is the correct name for the protocol is another matter; the IBM spec that documents it calls it "the NetBIOS Frames Protocol", and Microsoft calls it "NetBEUI Frame" in the Windows NT Server Networking Guide document in the NT Server Resource Kit:
but that's another matter.)
It is an independent implementation of the same protocol, so it does have something to do with it. It just doesn't share code with it.
This doesn't ipso facto mean that there will be any new security holes (besides, the protocol was documented), and doesn't ipso facto mean that Microsoft would have to "embrace Open Source" to deal with those, unless by "embrace Open Source" you mean something other than what is normally meant by "embrace Open Source", i.e. open-source their protocol implementation.
Because what they're open-sourcing is their implementation of an existing, documented protocol. They are NOT "open-sourcing" the protocol itself - the protocol is already publicly documented. Given that, I think that it's incorrect to say that they're "open-sourcing NetBEUI", just as it's incorrect to say that Berkeley, for example, "open-sourced TCP"; it's correct to say that they're open-sourcing their implementation of the NetBEUI (or NetBEUI Frame, or whatever) protocol.
So look at the URL when you need to know that. I do not necessarily want to have to think about where something is every time I look at it.
...except for a native character set of ASCII or a superset thereof. :-)
I don't know to what extent the ASCII/EBCDIC problem gets in the way of using the UNIX environment on OS/390 (e.g., requiring that the code be checked to make sure it doesn't assume that "A" through "Z" form a contiguous set of character codes - and doesn't assume that the characters you get in from a TCP connection from an HTTP client are in the native character set of the C compiler and the file system and...), but if it gets in the way of Just Recompiling, perhaps that was some of the rationale.
No, because Microsoft doesn't use Procom's implementation.
Discovered by reading the source code? Probably not many, as a lot of the code path for handling SMB is probably in the SMB code, not the NetBEUI code - and, as indicated, the code Procom is GPLing probably isn't the code Microsoft are using (unless they licensed it from Microsoft, which I think is extremely unlikely).
What "New NetBEUI security holes"? And why would then then "HAVE to embrace Open Source" for this?
Yeah, they got it by other means, i.e. writing an implementation thereof.
A protocol isn't "open-source" or "closed-source", it's publicly-documented or secret, and NetBEUI falls into the former category; see this document under "The NetBIOS Frames protocol".
Better than a poke in the eye with a sharp stick, I guess, but more pleasant might be a combination of smbfs and an automounter that understood SMB (knew which SMB servers had announced themselves to the browser, knew how to query an SMB server to see what shares it was offering) - that would let you use the KDE 1 file manager, or the KDE 2 file manager, or GMC, or Nautilus, or ls, or... as SMB browsers.
SMB requests and replies are stuffed into the payload of NetBIOS-over-NetBEUI (or "NetBIOS Frame Protocol") packets, just as they're stuffed into the payload of NetBIOS-over-TCP Datagram Service and Session Service packets, etc.. SMB doesn't, by and large, need to know or care what protocol NetBIOS runs atop.
It may be "a MS protocol" in the sense that Microsoft uses it, but that doesn't ipso facto mean that Microsoft invented it.
(It also doesn't mean it's necessarily some Secret Proprietary Protocol that Microsoft have only just now made public; it is, in fact, not such a protocol.)