If the codebase can be traced back to AT&T then you can call it Unix
If you're speaking in the strict legal sense, then, once upon a time, AT&T did, as I remember, impose such a restriction on the use of the trademark - except that it was much stricter, i.e. you had to have made minimal changes to the source code, just enough to make it run on your hardware. (That's why "Sun UNIX 4.2BSD Release 3.x" became "SunOS 4.x" - Sun, and Berkeley, had made rather a lot of changes to the code base that had nothing to do with making it run on Suns, and we figured that'd keep AT&T from yelling at us.)
However, the UNIX trademark is now owned by The Open Group, and anything that passes one of the UNIX test suites (e.g., the current one, the UNIX 98 test suite) can, in theory, be called "UNIX" even if it lacks any AT&T code whatsoever.
If, however, you're thinking of the general "look and feel", I don't care whether the code is AT&T-derived or not - if it looks like a UNIX system when I use it or develop code for it, I'll call it UNIX (even if that upsets either The Open Group or the "Linux is not UNIX" crowd).
Binary compatabilty would be such a waste of system resources.
Depends on the type of "binary compatibility". Many UNIXes (or "UNIX-flavored OSes", for the benefit of those who piss and moan about thinking of Linux as a UNIX) include the ability to run binaries for other UNIXes running on the same instruction set architecture, and this capability can come in handy if some program is available only in binary form and you want to run it on an OS other than one for which its binaries are available.
The basic cause of the backspace problem is a different ASCII code for the key in DEC terminals (where it's 0x7F) and others such as Sun systems (where it's 0x08).
The original character used to "[delete] the character to the left of the cursor" in UNIX was...
...'#'.
Yup, '#'. It was what Multics used, just as Multics used '@' to erase the line, and UNIX from Bell Labs followed in its footsteps, the fact that Multics largely ran the terminals in mode where echoing of characters was done by the terminal (in fact, as I remember, you didn't have a choice about it on at least the IBM 2741 Selectric-typewriter-based terminal; the special option to allow the host to turn off echoing worked, as I remember, by the terminal mechanically blocking the Selectric typeball from hitting the ribbon and the paper) but UNIX ran the terminals in a mode where echoing was done by the host nonwithstanding.
DEL (0x7F) was typically the interrupt character, to send a SIGINT to the currently running program; on CRTs, people may have chosen BACKSPACE (0x08) as an erase character - at least it would be echoed as a backspace, even if it didn't actually remove the character from the display, or work well if you were erasing a TAB character.
Some folks made the tty driver more like those in DEC's operating systems, where DEL erased the most recently typed character and either erased it from the screen on a CRT or echoed the erased characters inside backslashes on printing terminals, control-U erased the line (possibly erasing the entire line from the screen), and control-C was the interrupt character; BSD did so, and that tended to make DEL the erase character (even on Suns; as I remember, on Sun keyboards until the Type 4 keyboard, the big key on the top row sent DEL, not BACKSPACE; the Type 4 went more PC-like in what I remember being in part an attempt to make the PC users they hoped would pick up on the Sun386i happier).
So the basic cause of the backspace problem, in the sense of BACKSPACE (0x08) not being the standard erase character, was that the AT&T folks emulated Multics and the Berkeley folks emulated DEC. The problem of the big key on the top row of the main keyboard not erasing the previous character is a result of it sending (or, on workstations/PCs, not being interpreted as) DEL on some terminals. (Digital tended to make it send DEL on their terminals because that's what their OSes used as the erase character; I forget what other older terminals did, but some later terminals may have made it send BACKSPACE either because, well, that's where the backspace key goes on a typewriter or because that's where it goes on a PC. I guess the PC has it as a BACKSPACE key because the original IBM Personal Computer was made by a company that also made typewriters:-))
As I remember, System/360 storage keys were associated with large (4K?) regions of memory; they weren't associated with individual words, as tags are on the Burroughs machines (and their successors) and on the PowerPC AS/400's. I tend to think of "tags" as applying to individual words; do storage keys protect down to the word level on S/390?
It had certain instructions that would only run in the lowest ring
...and, at least in the older processors only in a segment tagged as a segment whose code should run in "master mode"; even most of the ring 0 code couldn't execute privileged instructions - it could only call small routines in one of those segments (said segments were, presumably, inaccessible outside of ring 0). The entry for "privileged mode" in the Multics site (well, mirror site at Stratus, anyway) glossary says:
The GCOS versions of the Multics processors implemented a traditional one-bit hardware user/supervisor distinction: the CPU privileged mode ("master mode" on the 645) enabled system-control instructions, which were otherwise illegal. In Multics, privileged became a bit (see REWPUG) in the [Segment Descriptor Word], effectively ANDed with ring of execution being ring 0. Very few supervisor segments had this bit. Today, modern processors only have rings.
some of the kernel functionality was actually implemented in the processor's hardware and microcode
The 6180 processor was among the last of the great non-microcoded engines. Entirely asynchronous, its hundred-odd boards would send out requests, earmark the results for somebody else, swipe somebody else's signals or data, and backstab each other in all sorts of amusing ways which occasionally failed (the "op not complete" timer would go off and cause a fault). Unlike the PDP-10, there was no hint of an organized synchronization strategy: various "it's ready now", "ok, go", "take a cycle" pulses merely surged through the vast backpanel ANDed with appropriate state and goosed the next guy down. Not without its charms, this seemingly ad-hoc technology facilitated a substantial degree of overlap (see Operations Unit) as well as the "appending" (in the dictionary sense) of the Multics address mechanism to the extant 6000 architecture in an ingenious, modular, and surprising way (see Appending Unit). Modification and debugging of the processor, though, were no fun.
It's in the PowerPC AS/400's, at least according to Frank Soltis' Inside the AS/400 book - there are tag bits in the extended PowerPC architecture used in the AS/400's.
It's also presumably still in the the Unisys ClearPath LX and ClearPath NX series, which include processors that are presumably the latest generation of the line of machines that started with the Burroughs mainframes.
Yes, there was a paper by Butler Lampson on system design (it was in the proceedings of some conference, I think, published in an issue of some ACM SIG's journal; alas, I no longer have the journal issue in question) about that.
As I remember, this was on TENEX, and was an unintended consequence of a feature allowing an application to catch (or, at least, be notified of) page faults - or it may have been protection faults (e.g., SIGSEGV or SIGBUS on UNIX) - from userland.
Files, if I remember the paper correctly, could be protected with a password in TENEX, and you specified the password in the call to open the file.
Normally, you'd have to cycle each character of the password independently, in order to try a brute-force password search.
However, the code that did the password checking would, if I remember the paper correctly, fetch a character of the password, check it, and either fail immediately or continue on fetching the next character and checking it.
You could then try opening the file with an N-character password, with the second character placed so that the fault in question would occur if the system tried to fetch it (i.e., either on the next page, or not in the address space if the fault wasn't just a "page me in" fault). You'd start with the first legal character value for all characters.
If the attempt to open the file succeeded, you win.
If it fails without a fault, you know that it didn't bother trying to fetch the next character, and therefore you know that the first character wasn't the right one; you'd then replace it with the next character value, and try again.
If it fails with a fault, you know that it did try to fetch the next character, and therefore you know that the first character is the right one. You then set up a password with that character as the first character, and with the second character being the first legal character value, and with the third character being on the next page, and repeat the process with the second character.
But that's not necessarily what the poster to whom you're replying was asking for. He/she said:
What are the plans for ACL support? I mean the stuff that comes up when you do (in NT) Properties, that second tab, then the Permissions button and get the list of users and groups. Right now we can mess with the existing user and group, but adding people fails.
Said tab is the tab for the file's ACL.
He/she then said:
Will this tie in with the Linux patch to add POSIX ACLs, or will it happen above that layer in a file Samba maintains?
If it ties in with the Linux patch in question, that'd obviously be per-file ACLs (it'd also be difficult, given that NT ACL semantics, which is what clients will be expecting, aren't the same as POSIX ACL semantics), and if it's done "in a file Samba maintains", it could, in theory, be done with per-file ACLs (I think some commercial SMB-server-for-UNIX does that), although the problem then is that said ACLs don't apply to UNIX users, just to SMB clients, so if somebody grants or denies Joe Blow access by adding an ACL entry, that doesn't necessarily mean that if Joe Blow logs into the box running Samba, or a UNIX box that's NFS-mounted stuff from the Samba box, he will necessarily be granted or denied access.
translator.infoseek.com is blocked...Can anyone figure this out
Their rationale might be that if you can't get to a site through their filter, you can get to a (translated version of) it by handing the URL to the translator.
Of course, this means your kids (or whoever) can't use it to translate stuff that isn't blocked, either....
No. SMB's file model is similar to NFS's file model - "please give me N bytes from the file starting at an offset of X" or "please write the following N bytes to the file starting at an offset of X". Typically, the server doesn't care what the bytes are, it just reads them or writes them.
Some SMB and NFS servers might offer an option to translate between different text file formats if the file is a text file, but I don't know whether any do.
Can the Samba serve music/video files?
I've read music and video files from our (Network Appliance's) SMB servers; I would expect it to work reading from a Samba server as well (there's no reason why it shouldn't work).
There is the
option of enabling SMP support when you do a make xconfig, but enabling it doesn't actually do anything. There's even some experimental code in the source tree but if you look carefully, none of it is ever even called.
Are you asserting that none of the stuff under #ifdef __SMP__ is ever compiled in, e.g. because enabling SMP support doesn't cause it to be defined (I don't see any place in the 2.2.14 source where, say, defining CONFIG_SMP causes __SMP__ to be defined, but a kernel tree on a machine here has -D__SMP__ in the Makefile), or are you asserting that the code in question is "experimental code" and, even if __SMP__is defined, "none of it is ever even called"?
People must be celbrating St. Pat's day early because I've been hearing that I don't say SMP is in Linux all day. Folks, read the graph, next to the end of the first page. See how it says 2.4 will have improved SMP.
But Linux takes a back seat to NT on symmetric-multiprocessing (SMP) systems.
However, the next public edition of the operating system, Linux 2.4, due out this summer, will offer SMP support.
(emphasis mine).
The emphasized sentence is certainly a true statement - but so would be "However, the next public edition of the operating system, Linux 2.4, due out this summer, will run on x86-based PC's."
I.e., it's a true statement - but is also true of previous versions of the Linux kernel.
Perhaps you meant to say
However, the next public edition of the operating system, Linux 2.4, due out this summer, will offer
better SMP support.
which would also be a true statement and would speak of a difference between 2.4 and previous kernel releases.
No time soon will there be a monitor wide enough for two browser or text editing windows side-by-side. (I long ago gave up 72 or 80 column text for 120 columns.)
Define "text editing window". I have, right now, on my desktop, two 66x120 xterms, with about a 2cm empty space to the right of them. (I normally have 66x80 xterms, but I widened a couple to see whether you could have two 120 column windows on the screen.)
Of course, the monitor I have on my desktop is the 1600x1024 SGI 1600SW (which is why I pay no attention to people who talk about how c00l their video cards are; unless it does OpenLDI, so that I can plug my SGI flat panel into them, I Don't Care, especially given that I don't use my machine for games^H^H^H^H^H3D interactive multimedia applications. Hopefully the I128 driver will get ported from 3.x to 4.x in a future XFree86 4.x release; 4.0 doesn't support it, and hence doesn't support the Revolution IV-FP card that came with the monitor - does anybody know of any other video card that can drive the SGI monitor?).
It can't do two Netscape windows at the width I use for Netscape, but it can, at least, do two 120-column xterms (those being what I do my text editing in)....
The Intel Science Talent Search (STS) is in the business of making dreams come true and opening new doors for young scientists. This nationwide competition - America's oldest and most highly regarded pre-college science contest -- has for the last 58 years helped the nation find and encourage talented high school seniors to pursue careers in science, math, engineering and medicine. The competition was previously sponsored by Westinghouse Electric Corporation. For 57 years the Science Talent Search has been administered by Science Service, a non-profit organization based in Washington, D.C.
Second, the alternative to C++ for system programming is C, which is from the 1960's, even earlier.
Presumably you mean that its philosophy comes from the '60's, not that the language itself comes from the '60's, given that Dennis Ritchie indicates that this version of the original B Reference Manual is dated 1972, and C is a descendant of B, so C is from the '70's.
What I was referring to would be something a bit more like Debian, where things are quite so user-friendly and "windowsish". In other words, a distribution that would be more fun for developers to play around with.
"Fun" in what sense? I don't consider configuring and tweaking a machine anywhere near as much "fun" as developing software for it; I have no problem with a "user-friendly and 'windowsish'" desktop, say - one of the reasons I use KDE on my machine at home is that the environment it gives me is "good enough" that I need to spend a lot of time figuring out all the knobs and buttons I needed to tweak to make it "good enough" for me.
I'd rather be editing source code for Ethereal, say, than editing configuration files.... (And, when trying to look into a networking bug, I'd rather be looking at network traces with Ethereal, say, than pawing through raw hex dumps of packets; part of the reason I got involved with Ethereal in the first place was that neither snoop, nor tcpdump, nor Microsoft's Network Monitor could cope with NFS or SMB requests or replies that required more than one frame. Having had to pull apart an NFS READDIR reply by hand, I decided that it was the sort of work best done by a computer, rather than by a human....
Ethereal can't yet handle multiple-frame "packets", either, but it's something we want to do, and we have some ideas about how to do it.)
I'd rather use my brain cells doing software development than configuring software tools, tweaking my system so that it recognizes my PnP ISA sound card, blah blah blah.
(I also think that a system that doesn't need configuration is preferable to a system that offers a Nice Friendly GUI for configuration. If the system can figure something out for itself, e.g. what sort of peripherals it has, or what properties some peripheral has, it shouldn't oblige you to tell it that something, regardless of whether you do it by editing a configuration file or pushing buttons on a nice shiny GUI application.)
This release isn't quite as complete as we would have liked. The main missing pieces are a nice configuration tool and support for some of the hardware that 3.3.x supports. The first point means that configuring the server might be more painful than usual. The second means that your hardware might not be supported by 4.0, or it might be supported at a lesser level (conversely, some hardware is better supported in 4.0). We've attempted to provide some information about the second point in our
Driver Status document. Please check there first before trying 4.0. Unfortunately that document is still fairly basic, but it should at least give you an idea of whether you're likely to be able to use 4.0 at all or not.
which might (from the "as complete as we would have liked") indicate that support for the Number Nine cards, and other cards not supported in 4.0, may arrive in a later release.
It's also my opinion that Linux can't truly fragment because of the nature of the GPL.
Define "fragment". The GPL does mean that changes to the GPLed parts of the code that goes into a Linux distribution (including, but not limited to, the kernel) made by one distribution must be made available in source form, and thus must be available to other distributions.
However, this does not ipso facto mean that those distributions will pick up said code, so different distributions may have behavioral differences, and some of them may well cause pain to users, developers, etc.. (Not all differences are "this distribution is for secure firewalls and the like, this distribution is for embedding in client appliances, this distribution is for embedding in server appliances, this distribution is for home desktop users, this distribution is for corporate/government/institutional desktop users, this distribution is for big Web servers, etc. - some of them may be differences between distributions aimed at the same market.)
I suspect many claims of fragmentation of Linux may be overstated.
However, I think the claim:
The Linux world is not fragmented at all--one kernel source tree and one user-land source tree goes into every single Linux distribution out there.
is also overstated.
First of all, there's the issue of versions of software. Linux distributions are built from many pieces maintained by different people, so it is possible that a given release one distribution might have a 2.2.x kernel and a 2.1.y glibc and so on, whilst a given release of another distribution that has the same 2.2.x kernel might have a different version of glibc, or a different version of utility XXX, or whatever - meaning that different user-land source trees are going into those distributions. Perhaps the next release of the second distribution uses the same version of glibc as the release in question of the first distribution, but it might then have a different kernel, or a different version of utility XXX or YYY, or whatever.
In addition, some distributions may well add their own changes to some or all of the components they bundle into their distributions. For example, it is not the case that all Linux distributions have "standard" versions of libpcap - Red Hat 6.1 has a patched version that, whilst it has some improvements, changes the format of capture files written by applications that use the libpcap code to write capture files (e.g., tcpdump) and doesn't change the magic number on those files. This obliged Ethereal, which uses its own library to read capture files in order to handle capture files that are not libpcap-format capture files, to go through some pain in order to be able to read
standard libpcap capture files;
libpcap capture files with the changed format and unchanged magic number;
libpcap capture files with the changed format and a different magic number, as produced by a later version of the patch than was picked up by Red Hat 6.1;
transparently (which the patched libpcaps don't do - the later patch can read the original format with the standard magic number, and can read the changed format with the new magic number, but can't read the changed format from files that use the standard magic number and that format; I can sympathize with the patch's developer for not doing so, as the hack I put into Ethereal's capture-file-reading library is really a bit gross, but, for Ethereal, I wanted it to be able to Just Work - hand it a capture file, and it consumes it, without having to be told what it is, regardless of whether the libpcap file that comes with the system on which it's running is capable of doing so). (I filed a bug on this, as did several other people; apparently a future Red Hat release will pick up a later patch, so that the libpcap files with a different file format will have a different magic number, and files from unpatched versions of libpcap can be read by tcpdump, for example.)
And, of course, not all Linux distributions have the same configuration file setup - for example, not all of them use a System V-style init and rc files.
I suspect there are people out there who can cite other examples of being bitten by differences between distributions, so I consider it an error to assert that "one kernel source tree and one user-land source tree goes into every single Linux distribution out there", or even to assert that the differences between the source that goes into those distributions don't cause any problems.
None of this, however, indicates that
Linux is necessarily any more badly fragmented than the BSDs (I suspect that, on the whole, it's easier to move software between Linux distributions than it is to move them from one BSD system to another, although I suspect most software probably moves with relatively little pain between Linux distributions, between BSD systems, from Linux distribution XXX to BSD system YYY, from BSD system YYY to Solaris, from Solaris to HP-UX, etc. - although there are presumably examples of pain caused by all of those transitions);
SCSI cables are supposed to be in knots and CDROMS sitting on the floor.
Bletch. Having yanked my machine open and added a new disk drive, clipping cable ties, pulling SCSI cables up, screwing the drive into the drive bay, blah blah blah, all I can say is...
...fuck that. I've been working with UNIX, including doing kernel development, since 1978 or so, so I'm not even close to a newbie, and, frankly, I would love to have a better way to plug disk drives in.
The same applies to software. I'd rather use my brain cells doing software development than configuring software tools, tweaking my system so that it recognizes my PnP ISA sound card, blah blah blah.
I run OpenBSD / FreeBSD cuz they're still true to their roots.
And I run FreeBSD as my home desktop machine for a variety of reasons - one of which is that it was less work to get it to recognize my sound card than it was to stuff the PnP ISA patch into the 2.0.x kernel in Debian 2.1, and it looked as if it'd be less work than it was to configure isapnptools. (It looks as if the 2.4 kernel will do better here.)
A more convenient system could well make life even better even for 31337 h@x0rs - less time tweaking your box to be the way you want it to be, more time to hack software....
In better systems, such as Multics, the drivers and file system were outside the kernel, as they should be.
By "outside the kernel", in the Multics context, do you mean "outside of the master mode code" or "outside ring 0"?
(As I remember, only a very tiny bit of code, in the form of small routines to execute privileged instructions, ran in master mode; for the benefit of most in the audience, the GE 645 and its successors, as I remember, could designate a segment as containing master mode code, and all calls into it would switch you to the equivalent of kernel mode - returns to a segment not so designated would leave master mode - and presumably that segment was accessible only from ring 0, ring 0 not being the same as master mode - most code in the OS, including ring 0 code, ran in slave mode.)
Re:The best thing about Multics...
on
Multics Scheduler
·
· Score: 2
He's talking about mapping memory to files, not files to memory.
To what is he referring when he says "mapping memory to files", and how is this different from "mapping files to memory" (except in the order of the two words relative to "mapping" and "to")? (Or did he just decide to use the words in the reverse order in which they tend to be used when talking about mmap(), in which case we're both talking about the same thing....)
In Multics, you initiated a segment, which caused a file to appear in your address space; this is, to some extent, similar to opening a file and mmap()ing it, or doing the appropriate Win32 voodoo dance to get something to hand to MapViewOfFile() and then doing so.
(See the definition of "initiate":
Said of a segment. Also "to make a segment known" (to a process). To make the supervisor call (or as a side-effect of dynamic linking) that associates a segment number with a file in the file system by making an entry in a process's KST. From that point on, references to that segment number become references to that segment, the fundamental illusion of the Multics Virtual Memory. On Multics, instead of opening files, a user initiates segments, and all the rest is magic [BSG].
I.e., they both involve taking a file name (pathname in UNIX or Win32; pathname, or segment name to be searched for in a path, in Multics) and, after making various calls to low-layer OS code, eventually getting a pointer that can be dereferenced, causing page faults that are satisfied by fetching data from the file, and possibly allowing stores through that pointer, with dirty pages pushed back to the file.
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 doing so might bring such programs under Subchapter B, Copying Controls:
Subchapter B. Copying Controls
Section 1002. Incorporation of copying controls
(a) Prohibition on importation, manufacture, and distribution No person shall import, manufacture, or distribute any digital audio recording device or digital audio interface device that does not conform to-- (1) the Serial Copy Management System; (2) a system that has the same functional characteristics as the Serial Copy Management System and requires that copyright and generation status information be accurately sent, received, and acted upon between devices using the system's method of serial copying regulation and devices using the Serial Copy Management System; or (3) any other system certified by the Secretary of Commerce as prohibiting unauthorized serial copying.
Slashdot Mirror
If you're speaking in the strict legal sense, then, once upon a time, AT&T did, as I remember, impose such a restriction on the use of the trademark - except that it was much stricter, i.e. you had to have made minimal changes to the source code, just enough to make it run on your hardware. (That's why "Sun UNIX 4.2BSD Release 3.x" became "SunOS 4.x" - Sun, and Berkeley, had made rather a lot of changes to the code base that had nothing to do with making it run on Suns, and we figured that'd keep AT&T from yelling at us.)
However, the UNIX trademark is now owned by The Open Group, and anything that passes one of the UNIX test suites (e.g., the current one, the UNIX 98 test suite) can, in theory, be called "UNIX" even if it lacks any AT&T code whatsoever.
If, however, you're thinking of the general "look and feel", I don't care whether the code is AT&T-derived or not - if it looks like a UNIX system when I use it or develop code for it, I'll call it UNIX (even if that upsets either The Open Group or the "Linux is not UNIX" crowd).
Depends on the type of "binary compatibility". Many UNIXes (or "UNIX-flavored OSes", for the benefit of those who piss and moan about thinking of Linux as a UNIX) include the ability to run binaries for other UNIXes running on the same instruction set architecture, and this capability can come in handy if some program is available only in binary form and you want to run it on an OS other than one for which its binaries are available.
The original character used to "[delete] the character to the left of the cursor" in UNIX was...
...'#'.
Yup, '#'. It was what Multics used, just as Multics used '@' to erase the line, and UNIX from Bell Labs followed in its footsteps, the fact that Multics largely ran the terminals in mode where echoing of characters was done by the terminal (in fact, as I remember, you didn't have a choice about it on at least the IBM 2741 Selectric-typewriter-based terminal; the special option to allow the host to turn off echoing worked, as I remember, by the terminal mechanically blocking the Selectric typeball from hitting the ribbon and the paper) but UNIX ran the terminals in a mode where echoing was done by the host nonwithstanding.
DEL (0x7F) was typically the interrupt character, to send a SIGINT to the currently running program; on CRTs, people may have chosen BACKSPACE (0x08) as an erase character - at least it would be echoed as a backspace, even if it didn't actually remove the character from the display, or work well if you were erasing a TAB character.
Some folks made the tty driver more like those in DEC's operating systems, where DEL erased the most recently typed character and either erased it from the screen on a CRT or echoed the erased characters inside backslashes on printing terminals, control-U erased the line (possibly erasing the entire line from the screen), and control-C was the interrupt character; BSD did so, and that tended to make DEL the erase character (even on Suns; as I remember, on Sun keyboards until the Type 4 keyboard, the big key on the top row sent DEL, not BACKSPACE; the Type 4 went more PC-like in what I remember being in part an attempt to make the PC users they hoped would pick up on the Sun386i happier).
So the basic cause of the backspace problem, in the sense of BACKSPACE (0x08) not being the standard erase character, was that the AT&T folks emulated Multics and the Berkeley folks emulated DEC. The problem of the big key on the top row of the main keyboard not erasing the previous character is a result of it sending (or, on workstations/PCs, not being interpreted as) DEL on some terminals. (Digital tended to make it send DEL on their terminals because that's what their OSes used as the erase character; I forget what other older terminals did, but some later terminals may have made it send BACKSPACE either because, well, that's where the backspace key goes on a typewriter or because that's where it goes on a PC. I guess the PC has it as a BACKSPACE key because the original IBM Personal Computer was made by a company that also made typewriters :-))
...and you probably won't see them on a BSD box, either:
The /dev entries for devices are a DLPIism; they weren't in SunOS prior to 5.0, and there are a number of UNIXes that lack them.
As I remember, System/360 storage keys were associated with large (4K?) regions of memory; they weren't associated with individual words, as tags are on the Burroughs machines (and their successors) and on the PowerPC AS/400's. I tend to think of "tags" as applying to individual words; do storage keys protect down to the word level on S/390?
...and, at least in the older processors only in a segment tagged as a segment whose code should run in "master mode"; even most of the ring 0 code couldn't execute privileged instructions - it could only call small routines in one of those segments (said segments were, presumably, inaccessible outside of ring 0). The entry for "privileged mode" in the Multics site (well, mirror site at Stratus, anyway) glossary says:
Hardware and/or microcode - the GE 645 and 6180 had no microcode; the Multics site glossary entry for the 6180 says:
No, it didn't.
The poster to whom you're responding was mistaken; they didn't use XML, they used SGML.
(Or, as the banner on this site should perhaps read:
Slashdot
YHBT. YHL. HAND.)
It's in the PowerPC AS/400's, at least according to Frank Soltis' Inside the AS/400 book - there are tag bits in the extended PowerPC architecture used in the AS/400's.
It's also presumably still in the the Unisys ClearPath LX and ClearPath NX series, which include processors that are presumably the latest generation of the line of machines that started with the Burroughs mainframes.
Yes, there was a paper by Butler Lampson on system design (it was in the proceedings of some conference, I think, published in an issue of some ACM SIG's journal; alas, I no longer have the journal issue in question) about that.
As I remember, this was on TENEX, and was an unintended consequence of a feature allowing an application to catch (or, at least, be notified of) page faults - or it may have been protection faults (e.g., SIGSEGV or SIGBUS on UNIX) - from userland.
Files, if I remember the paper correctly, could be protected with a password in TENEX, and you specified the password in the call to open the file.
Normally, you'd have to cycle each character of the password independently, in order to try a brute-force password search.
However, the code that did the password checking would, if I remember the paper correctly, fetch a character of the password, check it, and either fail immediately or continue on fetching the next character and checking it.
You could then try opening the file with an N-character password, with the second character placed so that the fault in question would occur if the system tried to fetch it (i.e., either on the next page, or not in the address space if the fault wasn't just a "page me in" fault). You'd start with the first legal character value for all characters.
If the attempt to open the file succeeded, you win.
If it fails without a fault, you know that it didn't bother trying to fetch the next character, and therefore you know that the first character wasn't the right one; you'd then replace it with the next character value, and try again.
If it fails with a fault, you know that it did try to fetch the next character, and therefore you know that the first character is the right one. You then set up a password with that character as the first character, and with the second character being the first legal character value, and with the third character being on the next page, and repeat the process with the second character.
But that's not necessarily what the poster to whom you're replying was asking for. He/she said:
Said tab is the tab for the file's ACL.
He/she then said:
If it ties in with the Linux patch in question, that'd obviously be per-file ACLs (it'd also be difficult, given that NT ACL semantics, which is what clients will be expecting, aren't the same as POSIX ACL semantics), and if it's done "in a file Samba maintains", it could, in theory, be done with per-file ACLs (I think some commercial SMB-server-for-UNIX does that), although the problem then is that said ACLs don't apply to UNIX users, just to SMB clients, so if somebody grants or denies Joe Blow access by adding an ACL entry, that doesn't necessarily mean that if Joe Blow logs into the box running Samba, or a UNIX box that's NFS-mounted stuff from the Samba box, he will necessarily be granted or denied access.
Their rationale might be that if you can't get to a site through their filter, you can get to a (translated version of) it by handing the URL to the translator.
Of course, this means your kids (or whoever) can't use it to translate stuff that isn't blocked, either....
...or some flavor of ACL stuff, e.g. the stuff that was being worked on as a POSIX draft, or various implementations based on various POSIX drafts (Solaris and Digital UNIX both have POSIX-draft-like ACLs, and other UNIXes might as well - there's a project to implement them for Linux as well), or non-POSIX-style ACLs such as appear on HP-UX.
No. SMB's file model is similar to NFS's file model - "please give me N bytes from the file starting at an offset of X" or "please write the following N bytes to the file starting at an offset of X". Typically, the server doesn't care what the bytes are, it just reads them or writes them.
Some SMB and NFS servers might offer an option to translate between different text file formats if the file is a text file, but I don't know whether any do.
I've read music and video files from our (Network Appliance's) SMB servers; I would expect it to work reading from a Samba server as well (there's no reason why it shouldn't work).
Are you asserting that none of the stuff under #ifdef __SMP__ is ever compiled in, e.g. because enabling SMP support doesn't cause it to be defined (I don't see any place in the 2.2.14 source where, say, defining CONFIG_SMP causes __SMP__ to be defined, but a kernel tree on a machine here has -D__SMP__ in the Makefile), or are you asserting that the code in question is "experimental code" and, even if __SMP__ is defined, "none of it is ever even called"?
Yes, but on the very first page it says:
(emphasis mine).
The emphasized sentence is certainly a true statement - but so would be "However, the next public edition of the operating system, Linux 2.4, due out this summer, will run on x86-based PC's."
I.e., it's a true statement - but is also true of previous versions of the Linux kernel.
Perhaps you meant to say
which would also be a true statement and would speak of a difference between 2.4 and previous kernel releases.
Define "text editing window". I have, right now, on my desktop, two 66x120 xterms, with about a 2cm empty space to the right of them. (I normally have 66x80 xterms, but I widened a couple to see whether you could have two 120 column windows on the screen.)
Of course, the monitor I have on my desktop is the 1600x1024 SGI 1600SW (which is why I pay no attention to people who talk about how c00l their video cards are; unless it does OpenLDI, so that I can plug my SGI flat panel into them, I Don't Care, especially given that I don't use my machine for games^H^H^H^H^H3D interactive multimedia applications. Hopefully the I128 driver will get ported from 3.x to 4.x in a future XFree86 4.x release; 4.0 doesn't support it, and hence doesn't support the Revolution IV-FP card that came with the monitor - does anybody know of any other video card that can drive the SGI monitor?).
It can't do two Netscape windows at the width I use for Netscape, but it can, at least, do two 120-column xterms (those being what I do my text editing in)....
Nope, they're exactly the same age...
...because they're the same competition. Here's an Intel press release saying:
Presumably you mean that its philosophy comes from the '60's, not that the language itself comes from the '60's, given that Dennis Ritchie indicates that this version of the original B Reference Manual is dated 1972, and C is a descendant of B, so C is from the '70's.
"Fun" in what sense? I don't consider configuring and tweaking a machine anywhere near as much "fun" as developing software for it; I have no problem with a "user-friendly and 'windowsish'" desktop, say - one of the reasons I use KDE on my machine at home is that the environment it gives me is "good enough" that I need to spend a lot of time figuring out all the knobs and buttons I needed to tweak to make it "good enough" for me.
I'd rather be editing source code for Ethereal, say, than editing configuration files.... (And, when trying to look into a networking bug, I'd rather be looking at network traces with Ethereal, say, than pawing through raw hex dumps of packets; part of the reason I got involved with Ethereal in the first place was that neither snoop, nor tcpdump, nor Microsoft's Network Monitor could cope with NFS or SMB requests or replies that required more than one frame. Having had to pull apart an NFS READDIR reply by hand, I decided that it was the sort of work best done by a computer, rather than by a human....
Ethereal can't yet handle multiple-frame "packets", either, but it's something we want to do, and we have some ideas about how to do it.)
I.e., as I said in another comment in another thread:
(I also think that a system that doesn't need configuration is preferable to a system that offers a Nice Friendly GUI for configuration. If the system can figure something out for itself, e.g. what sort of peripherals it has, or what properties some peripheral has, it shouldn't oblige you to tell it that something, regardless of whether you do it by editing a configuration file or pushing buttons on a nice shiny GUI application.)
Unlikely, given that the Number Nine section of the driver status document says:
The release notes say:
which might (from the "as complete as we would have liked") indicate that support for the Number Nine cards, and other cards not supported in 4.0, may arrive in a later release.
Define "fragment". The GPL does mean that changes to the GPLed parts of the code that goes into a Linux distribution (including, but not limited to, the kernel) made by one distribution must be made available in source form, and thus must be available to other distributions.
However, this does not ipso facto mean that those distributions will pick up said code, so different distributions may have behavioral differences, and some of them may well cause pain to users, developers, etc.. (Not all differences are "this distribution is for secure firewalls and the like, this distribution is for embedding in client appliances, this distribution is for embedding in server appliances, this distribution is for home desktop users, this distribution is for corporate/government/institutional desktop users, this distribution is for big Web servers, etc. - some of them may be differences between distributions aimed at the same market.)
I suspect many claims of fragmentation of Linux may be overstated.
However, I think the claim:
is also overstated.
First of all, there's the issue of versions of software. Linux distributions are built from many pieces maintained by different people, so it is possible that a given release one distribution might have a 2.2.x kernel and a 2.1.y glibc and so on, whilst a given release of another distribution that has the same 2.2.x kernel might have a different version of glibc, or a different version of utility XXX, or whatever - meaning that different user-land source trees are going into those distributions. Perhaps the next release of the second distribution uses the same version of glibc as the release in question of the first distribution, but it might then have a different kernel, or a different version of utility XXX or YYY, or whatever.
In addition, some distributions may well add their own changes to some or all of the components they bundle into their distributions. For example, it is not the case that all Linux distributions have "standard" versions of libpcap - Red Hat 6.1 has a patched version that, whilst it has some improvements, changes the format of capture files written by applications that use the libpcap code to write capture files (e.g., tcpdump) and doesn't change the magic number on those files. This obliged Ethereal, which uses its own library to read capture files in order to handle capture files that are not libpcap-format capture files, to go through some pain in order to be able to read
transparently (which the patched libpcaps don't do - the later patch can read the original format with the standard magic number, and can read the changed format with the new magic number, but can't read the changed format from files that use the standard magic number and that format; I can sympathize with the patch's developer for not doing so, as the hack I put into Ethereal's capture-file-reading library is really a bit gross, but, for Ethereal, I wanted it to be able to Just Work - hand it a capture file, and it consumes it, without having to be told what it is, regardless of whether the libpcap file that comes with the system on which it's running is capable of doing so). (I filed a bug on this, as did several other people; apparently a future Red Hat release will pick up a later patch, so that the libpcap files with a different file format will have a different magic number, and files from unpatched versions of libpcap can be read by tcpdump, for example.)
And, of course, not all Linux distributions have the same configuration file setup - for example, not all of them use a System V-style init and rc files.
I suspect there are people out there who can cite other examples of being bitten by differences between distributions, so I consider it an error to assert that "one kernel source tree and one user-land source tree goes into every single Linux distribution out there", or even to assert that the differences between the source that goes into those distributions don't cause any problems.
None of this, however, indicates that
Bletch. Having yanked my machine open and added a new disk drive, clipping cable ties, pulling SCSI cables up, screwing the drive into the drive bay, blah blah blah, all I can say is...
...fuck that. I've been working with UNIX, including doing kernel development, since 1978 or so, so I'm not even close to a newbie, and, frankly, I would love to have a better way to plug disk drives in.
The same applies to software. I'd rather use my brain cells doing software development than configuring software tools, tweaking my system so that it recognizes my PnP ISA sound card, blah blah blah.
And I run FreeBSD as my home desktop machine for a variety of reasons - one of which is that it was less work to get it to recognize my sound card than it was to stuff the PnP ISA patch into the 2.0.x kernel in Debian 2.1, and it looked as if it'd be less work than it was to configure isapnptools. (It looks as if the 2.4 kernel will do better here.)
A more convenient system could well make life even better even for 31337 h@x0rs - less time tweaking your box to be the way you want it to be, more time to hack software....
By "outside the kernel", in the Multics context, do you mean "outside of the master mode code" or "outside ring 0"?
(As I remember, only a very tiny bit of code, in the form of small routines to execute privileged instructions, ran in master mode; for the benefit of most in the audience, the GE 645 and its successors, as I remember, could designate a segment as containing master mode code, and all calls into it would switch you to the equivalent of kernel mode - returns to a segment not so designated would leave master mode - and presumably that segment was accessible only from ring 0, ring 0 not being the same as master mode - most code in the OS, including ring 0 code, ran in slave mode.)
To what is he referring when he says "mapping memory to files", and how is this different from "mapping files to memory" (except in the order of the two words relative to "mapping" and "to")? (Or did he just decide to use the words in the reverse order in which they tend to be used when talking about mmap(), in which case we're both talking about the same thing....)
In Multics, you initiated a segment, which caused a file to appear in your address space; this is, to some extent, similar to opening a file and mmap()ing it, or doing the appropriate Win32 voodoo dance to get something to hand to MapViewOfFile() and then doing so.
(See the definition of "initiate":
in the "i" section of the Glossary on the Multicians.org site.)
I.e., they both involve taking a file name (pathname in UNIX or Win32; pathname, or segment name to be searched for in a path, in Multics) and, after making various calls to low-layer OS code, eventually getting a pointer that can be dereferenced, causing page faults that are satisfied by fetching data from the file, and possibly allowing stores through that pointer, with dirty pages pushed back to the file.
...but doing so might bring such programs under Subchapter B, Copying Controls: