Setting the permissions on a per directory basis. So that if I put a file in my www_docs, it'll be 644, if I put it in a directory where several people help editing web pages, then it gets 664, my personal stuff is 600, and so on.
Some file systems that support access control lists (NTFS and the Solaris version of the BSD file system, I think) give directories a second access control list which is the ACL to give to files created in that directory. (I seem to remember that Multics had this - I think it originally had "common ACLs" for directories, which were combined with the ACLs of files in the directories to give the ACL that gives permissions for access to those files, and that those were replaced with an "initial ACL" of that sort.)
It is true that disks themselves have caches, and I'm not sure what guarantees the hardware makes about those, but I believe that the idea is that if the os block driver asks for a write of a single block, the drive is pretty much guranteed to have enough power to finish that write. I'm not totally sure on this, though.
Probably a wise decision - I'm not sure I'd trust write-caching disk drives not to lose data on power failures. I suspect many OSes simply tell the drives not to do their own write caching.
The 1600SW is fantastic but the Number Nine card could be better
It's also supported by the 3DLabs Oxygen VX1-1600SW. I don't know whether that card's better than the #9 Revolution IV-FP or not. (Presumably one reason SGI switched is that #9 is out of business....)
(and doesn't have a driver in XFree86 4).
One has been checked into the XFree86 CVS tree, so some future 4.x release will probably support it.
I don't think there's currently any XFree86 4.x support for the VX1-1600SW, but it may appear in the future.
They now supply a MultiLink adapter which allows the monitor to accept many types of video input.
The only drawback is that the XFree86 support is very weak, it mostly works under 3.3.6 (but no DPMS support) and there is no 4.0 support.
It appears that an i128 driver was checked into the XFree86 CVS tree recently, so a future 4.x release will probably support the Revolution IV-FP.
I don't think there's yet support for the 3DLabs Oxygen VX1-1600SW, though. (Anybody know of a store in the UK that sells the SGI monitor + 3DLabs card and that lets you order online? Yes, the UK - I want to buy one from the US and have it delivered to an address in the UK.)
For example, the Windows GDI is notoriously slow. It is largely 16 bit code that needs to thunk in every call to it. However, MS managed to get it to a decent speed by rewriting parts of it in ASM and putting it into the kernel.
Was the person who spoke of the Windows drawing code having been put into the kernel speaking of the Windows OT drawing code, or the Windows NT drawing code? If the latter (i.e., the move, from NT 3.x to NT 4.x, of the drawing code from, err, umm, a server process to which the gdi32.dll library sent messages to kernel code to which the gdi32.dll library made system calls), then that code isn't 16-bit code, as far as I know - the Windows OT GDI code may, as I have heard, be 16-bit, but I rather doubt the Windows NT code is.
And the evidence to support this belief is? (The fact that Cutler was one of the people working on that project - I seem to remember hearing that "Prism" was the name of the RISC architecture they were doing; I don't know whether the OS they were doing had the same name - doesn't ipso facto mean that the next OS he did included any code from that project. Ideas, maybe, but not necessarily code.)
Microsoft hired some key VMS dude (okay, I forget his name, so sue me), from Digital, and he was like one of the chief architects of the NT kernel early on.
I think that Sun hired a load of the guys at Berkely, Bill Joy etc, who did a lot of the early work on UNIX.
I suppose being one of the four founders of Sun, as Bill was, could be read as being hired by Sun, in a sense.:-)
However, I don't think any of the other core BSD guys were Sun employees - Kirk McKusick wasn't (I seem to remember he may have consulted at Sun, but he wasn't on the payroll), and neither was Sam Leffler (he went to SGI, not Sun); I forget whether Mike Karels was involved with 4BSD or 2BSD at that time Sun was founded - in any case, he also wasn't ever a Sun employee, as far as I know.
Also, didn't Micros~1 hire one of the key programmers on Mach to write the NT kernel?
They hired Rick Rashid for Microsoft Research, but that was, I think, well after NT was shipped. They may have hired other Mach people to work on NT, but I don't know of any myself, for what that's worth.
They did hire a guy from Digital Equipment Corporation, Dave Cutler, to be one of the architects of NT (perhaps the chief architect, although in the foreword to the first edition of Inside Windows NT he just says "I must say that I did not design Windows NT -- I was merely one of the contributors to the design of the system.")
The I/O subsystem of NT looks somewhat VMSish, but I suspect the VMS I/O subsystem looks somewhat RSX-11M-ish; I suspect Cutler was responsible for much of the design of all three I/O subsystems (which does not mean that he necessarily used any VMS code in NT, it may just mean he reused earlier ideas of his).
That's Research OPD Mini Processor. OPD = Office Products Division.
ROMP was originally designed to be used in office products, primarily text editing systems such as the IBM Office System/6 and DisplayWriter. The architectural work started in late spring of 1977, as a spin-off of the T.J. Watson Research 801 work (hence the "Research" in the acronym). Most of the architectural changes were for "cost reductions," such as adding 16-bit instructions for "byte-efficiency"--a main concern at IBM at the time.
Every mention I've seen of a port says they're being done for UNIX, as in "UNIX is a registered trademark of The Open Group." Nowhere is Linux mentioned.
UNIX is, in the legal sense, a registered trademark of The Open Group.
It is also, the trademark standard nonwithstanding, a term used to refer to a large class of operating systems with a certain set of APIs; most if not all Linux distributions belong to this class of operating systems.
Mainsoft doesn't currently run on "UNIX" in the sense of "all members of that class of operating systems"; it doesn't even run on "UNIX" in the sense of "all OSes that have passed the Open Group test suite and can thus have the trademark used when referring to them" - under "IBM" they list "AIX 4.3.2" but make no mention of OS/390 (yes, OS/390 has passed the UNIX 95 test suite, as per this list of products that have passed that test suite).
However, they do have, in beta, a MainWin for Linux, as per this page, although it's past "the first quarter of 2000" and there's no sign of it having emerged from beta yet, so I don't know if the MainWin for Linux has stalled, or been killed, or what.
So, whilst it's probably not impossible for them to have ported MainWin, and thus not impossible for them to use it to port IE etc., whether it'll happen is unspecified (i.e., it has not been indicated that it will and there's no firm indication that it won't, either).
Paul Thurrott, the author of the Wininformant piece, askes a good question in as to why Mainsoft needs a copy of the WinNT source code if it's only porting IE.
I wouldn't consider that a particularly good question; the question was
One might wonder why Microsoft would need to supply the jealously guarded Windows source code to a company that was simply porting old versions of IE and WMP to other operating systems.
to which the answer is very simple: Mainsoft is not a company that is "simply porting old versions of IE and WMP to other operating systems".
Mainsoft is a company whose product is a library to implement the Win32 API atop other operating systems. The "MainWin: How It Works page on Mainsoft's Web site says
MainWin Architecture Overview
The MainWin libraries consist of two layers that sit directly on top of the UNIX operating system:
MainWin Win32 subsystem
The Win32 subsystem is a low-level implementation of the Windows 32-bit interface (Win32) on UNIX. This thin and efficient layer sits close to the low-level UNIX service layers such as POSIX, Xlib, and OpenGL. This layer provides Windows graphic services, window management, NT kernel (thread and synchronization objects), networking, and Windows GL (graphic layer) support.
Windows NT Services
The Windows NT Services consist of millions of lines of Windows NT4 source code which have been rehosted on UNIX. The MainWin Win32 layer has allowed us to port large portions of Windows NT run-time support with minimal code modifications. Having the actual Windows NT source code running on UNIX assures you of the highest level of Windows NT compatibility for your applications; and allows the same source code to run correctly on both UNIX and Windows.
(Note that Windows NT isn't just a kernel, it's a complete OS and window system/GUI; the stuff being rehosted is presumably large amounts of userland code.)
I'm also not sure why Thurrott thought the fact that Mainsoft had access to NT source code was some Deep Dark Secret that his informant had revealed to him, as per his comment
And they even mention having access to the Windows 2000/NT 4 source code, a tidbit that was also divulged to me in Israel.
Sunnyvale, California August 27, 1998-Mainsoft, the market leader in extending Windows APIs to UNIX, announced that it has signed a new WISE agreement with Microsoft, giving Mainsoft access to Windows NT source code up to and including Windows NT version 5. The WISE Agreement provides Mainsoft with the sources necessary to continue development and support of MainWin through the next generation of its Windows on UNIX..
Same-day release of Windows and UNIX versions of Internet Explorer 5.0
On March 18, 1999, Microsoft simultaneously released Windows and UNIX version of Internet Explorer 5.0 with Outlook Express. Rather than rewrite the code for the UNIX version, Microsoft chose to use MainWin to rehost the source code on UNIX. Using MainWin, Microsoft was able to ship the UNIX version of this complex and technically advanced release of Internet Explorer on the same day as the Windows version.
which would seem to imply that the version of IE 5 that was ported to UNIX was about as far from "old" as one could imagine; no, they may not have ported IE 5.5 yet, but, at the time they ported IE 5.0, it was as new as you can get.)
Methinks Thurrott should, before he speaks further on this topic, spend an hour or so browsing the Mainsoft Web site, at least if his goal is journalistic accuracy rather than journalistic excitement (you can often write far more exciting stories if you're not constrained by such boring mundane restrictions as a requirement to have what you say correspond, to some extent, to reality).
The problem is, I suspect, that Qt doesn't acknowledge the existence of the "clipboard" selection in X (which is documented in the ICCCM, even if they didn't bother assigning an XA_ atom to it); instead, it uses only the primary selection.
This has two disadvantages:
other toolkits that think the clipboard is, as per the ICCCM, implemented by the clipboard attachment don't see stuff cut or copied to the Qt clipboard on a paste, and don't cut or copy stuff to the Qt clipboard on a cut or copy;
merely selecting something, at least in, for example, the Qt multi-line text editing box, causes it to be copied to the clipboard (the claim I saw in the code was something about X users expecting this, but I'm curious if only X users who confuse cut-and-paste with middle-mouse-button paste-current-selection would expect that; the middle button is not the UNIX/X cut-and-paste mechanism, it's a mechanism over and above cut/copy/paste), which, I suspect, makes it a pain if you want to replace one blob of text by another by selecting the blob to be copied, copying it to the clipboard, selecting the blob to be replaced, and doing a paste (which worked just fine copying from, say, UNIX Netscape, a Motif application, to Ethereal, a GTK+ application, when I tried it just now) - I'll have to check when I get home (where I have KDE applications available) to see if that works.
I suspect the first problem could be fixed by having the QClipboard code in Qt for X assert ownership of both the primary and clipboard selections, and having it supply the contents of the primary selection only if the clipboard selection isn't set (for backwards compatibility with applications using older versions of Qt).
The second problem would be harder to fix, as you'd have to:
provide some Qt API to set the primary selection - and, in the Windows version, somehow either make that work with some Windows mechanism or implement it internally to Qt, as I infer from the code that Qt for Windows ("infer" because I don't have source to Qt for Windows - I don't think they make that available) that, at least when the Motif look-and-feel is specified, they try to provide middle-mouse-button paste-current-selection if your mouse has 3 buttons;
change code (in Qt, KDE, and elsewhere) to use that API for changes to the current selection and for middle-mouse-button paste-current-selection, and only use QClipboard for genuine cuts, copies, and pastes.
The chip really based on the VAX was the National Semiconductor 32016 and 32032. I'm not sure that chip ever made it out of test marketing.
I assume the second sentence is joking; the first Sequent machines (Balance) were NS32K-based, as were Encore's first machines. Sequent switched to 386's for the Symmetry machines - I forget what Encore did.
There was also a PC532, which was a home-brew NS32532 design for which there's a NetBSD port.
You miss the point, we FreeBSD'ers are supposed to run the Linux version. All Loki says is that they are going to make sure the game also runs in the Linuxator in FreeBSD as well.
...which misses the point the person to whom you were replying was making. He said:
I just can't see serious demand for FreeBSD games if they are released so much later than the Windows counterparts. Then when we find out that Linux software games have light sales it won't help the cause to create Linux/BSD versions of these games at the same time as the Windows version.
which should perhaps have been stated as "I just can't see serious demand for FreeBSD/Linux games" to make it clear that it's not Linux vs. BSD he's talking about, it's Windows vs. everything else lumped together.
I.e., he's saying that releasing games for non-Windows platforms - regardless of which platforms those are, and regardless of whether the version for FreeBSD is native or just the Linux version made to install and run on the Linuxator - later than the Windows version could lead to lower sales for the non-Windows versions, leading to less incentive for developers to make games run on those platforms.
Anyone feel this is a practice run for them, to help getting a feel for coding under the Mac OSX architecture?
Perhaps some people do, but I don't, because
the article said "Through this new partnership, Loki and BSDI will work together to ensure Loki's gaming titles are compatible with FreeBSD using the Linux-compatibility features";
MacOS X may have a BSD-compatible kernel and much BSD userland, but the native window system is quite different from the native window system on most UNIXes, and I suspect most native MacOS X desktop applications will use either the "Classic" API/ABI (i.e., be generic MacOS apps), the "Carbon" tweaked MacOS API/ABI (also not particularly UNIXish, as far as I know), or the "Cocoa" API/ABI (which, as I understand it, is NeXTStEP), even for those functions you can perform with a native UNIXish API - even if they were doing native FreeBSD versions of the games, that'd probably largely be minor portability tweaks, not the sort of changes you'd need to make a native MacOS X application that uses the MacOS X window system, etc., etc..
I.e., whilst there's BSD-compatible stuff "under the hood" of MacOS X, I get the impression that the BSD-flavored UNIX APIs there are not what most MacOS X desktop applications (and maybe not even most server applications) will use, so porting an application that runs on one UNIX-flavored OS (e.g., Linux) to *BSD (the BSDs are also UNIX-flavored OSes) doesn't make the application much more friendly towards the non-UNIX-flavored APIs that I suspect most MacOS X appls will use.
How fast can information be transmitted from one machine to another? Is fiber optic the way to go? What about the time spent in routers and switches?
and
How many instructions per second can the microprocessor as we know it execute?
are in part arguably physics questions (i.e., "how fast can you make transistors switch?", "how fast an optical switch can you make?", etc.).
The question
How fast can we search a database? Is there some fundamental sorting algorithm that we've missed?
strikes me as being a more purely CS question (although with stuff such as Adelman's DNA computing it might not be pure CS either - toss in a little chemistry...).
Several members of the project have expressed an intrest in such a thing. In theory it won't be too hard -- making it as efficient as XF86 might be a challenge, but assuming we can provide GGI visuals to XF86/GGI (which already works fine) then there's a good chance it'll show up early on in our releases. Of course, if you're perfectly satisfied with X, XF86 will likely serve you better, but we do recognize the significant utility of X compatibility.
so they at least realize that it will probably ultimately need to be X-compatible - there are just too many X applications out there for them to treat X as irrelevant.
It may not have X support now, but, in that FAQ, they quite explicitly say that it's not ready for prime time yet:
Who should install Berlin?
At the moment Berlin in NOT ueful to normal people. We consider ourself to be a test-ground for UI-development. This does not mean, that we do not want "normal people" to play around with our work! It just means that we have NO real-world applications yet, not even a terminal with the features you know from XTerm (or other Terminals like rxvt, gnome-terminal,...).
so the fact that it currently lacks X compatibility may not really mean that much.
Slashdot Mirror
Michael Everson of Everson Gunn Teoranta has proposed an encoding of Klingon in Plane 1 of ISO/IEC 10646-2; if it gets adopted, future versions of Unicode may adopt it (Everson's one of the editors and authors of Unicode 3.0).
Presumably you meant "...97% of the closed source Linux applications."
Some file systems that support access control lists (NTFS and the Solaris version of the BSD file system, I think) give directories a second access control list which is the ACL to give to files created in that directory. (I seem to remember that Multics had this - I think it originally had "common ACLs" for directories, which were combined with the ACLs of files in the directories to give the ACL that gives permissions for access to those files, and that those were replaced with an "initial ACL" of that sort.)
Probably a wise decision - I'm not sure I'd trust write-caching disk drives not to lose data on power failures. I suspect many OSes simply tell the drives not to do their own write caching.
Unless the colored plastic can turn a 17.3-inch (diagonal) display into a 22-inch (diagonal) display, I doubt that the Apple Cinema Display is a colored-plastic-covered SGI 1600SW.
It's also supported by the 3DLabs Oxygen VX1-1600SW. I don't know whether that card's better than the #9 Revolution IV-FP or not. (Presumably one reason SGI switched is that #9 is out of business....)
One has been checked into the XFree86 CVS tree, so some future 4.x release will probably support it.
I don't think there's currently any XFree86 4.x support for the VX1-1600SW, but it may appear in the future.
...although, as I read SGI's FAQ on the MultiLink Adapter and, in particular, the answer to "What happens if my card is not SuperWide savvy?", you don't get 1600x1024 unless you have a "SuperWide Savvy" adapter - and you may need driver support for that; see the SuperWide Savvy page.
It appears that an i128 driver was checked into the XFree86 CVS tree recently, so a future 4.x release will probably support the Revolution IV-FP.
I don't think there's yet support for the 3DLabs Oxygen VX1-1600SW, though. (Anybody know of a store in the UK that sells the SGI monitor + 3DLabs card and that lets you order online? Yes, the UK - I want to buy one from the US and have it delivered to an address in the UK.)
It was recently checked into the XFree86 CVS tree (I don't know if it works yet, all I know is that it was checked in).
Some other amusing entries in the knowledgebase are Computer Randomly Plays Classical Music and Sometimes Barney Starts Playing Peekaboo on His Own.
And I was talking about the person who said:
who may or may not have been talking about the Windows 9x GDI.
Was the person who spoke of the Windows drawing code having been put into the kernel speaking of the Windows OT drawing code, or the Windows NT drawing code? If the latter (i.e., the move, from NT 3.x to NT 4.x, of the drawing code from, err, umm, a server process to which the gdi32.dll library sent messages to kernel code to which the gdi32.dll library made system calls), then that code isn't 16-bit code, as far as I know - the Windows OT GDI code may, as I have heard, be 16-bit, but I rather doubt the Windows NT code is.
And the evidence to support this belief is? (The fact that Cutler was one of the people working on that project - I seem to remember hearing that "Prism" was the name of the RISC architecture they were doing; I don't know whether the OS they were doing had the same name - doesn't ipso facto mean that the next OS he did included any code from that project. Ideas, maybe, but not necessarily code.)
Dave Cutler, as per this earlier posting of mine.
I suppose being one of the four founders of Sun, as Bill was, could be read as being hired by Sun, in a sense. :-)
However, I don't think any of the other core BSD guys were Sun employees - Kirk McKusick wasn't (I seem to remember he may have consulted at Sun, but he wasn't on the payroll), and neither was Sam Leffler (he went to SGI, not Sun); I forget whether Mike Karels was involved with 4BSD or 2BSD at that time Sun was founded - in any case, he also wasn't ever a Sun employee, as far as I know.
They hired Rick Rashid for Microsoft Research, but that was, I think, well after NT was shipped. They may have hired other Mach people to work on NT, but I don't know of any myself, for what that's worth.
They did hire a guy from Digital Equipment Corporation, Dave Cutler, to be one of the architects of NT (perhaps the chief architect, although in the foreword to the first edition of Inside Windows NT he just says "I must say that I did not design Windows NT -- I was merely one of the contributors to the design of the system.")
The I/O subsystem of NT looks somewhat VMSish, but I suspect the VMS I/O subsystem looks somewhat RSX-11M-ish; I suspect Cutler was responsible for much of the design of all three I/O subsystems (which does not mean that he necessarily used any VMS code in NT, it may just mean he reused earlier ideas of his).
You misspelled "ROMP". :-) The RT PC used the IBM-developed ROMP; see The IBM RT Information page, and pages linked to it, such as the IBM RT system hardware FAQ, which says:
Perhaps you were mistaken and it doesn't contain any Mach code.
UNIX is, in the legal sense, a registered trademark of The Open Group.
It is also, the trademark standard nonwithstanding, a term used to refer to a large class of operating systems with a certain set of APIs; most if not all Linux distributions belong to this class of operating systems.
Mainsoft doesn't currently run on "UNIX" in the sense of "all members of that class of operating systems"; it doesn't even run on "UNIX" in the sense of "all OSes that have passed the Open Group test suite and can thus have the trademark used when referring to them" - under "IBM" they list "AIX 4.3.2" but make no mention of OS/390 (yes, OS/390 has passed the UNIX 95 test suite, as per this list of products that have passed that test suite).
However, they do have, in beta, a MainWin for Linux, as per this page, although it's past "the first quarter of 2000" and there's no sign of it having emerged from beta yet, so I don't know if the MainWin for Linux has stalled, or been killed, or what.
So, whilst it's probably not impossible for them to have ported MainWin, and thus not impossible for them to use it to port IE etc., whether it'll happen is unspecified (i.e., it has not been indicated that it will and there's no firm indication that it won't, either).
I wouldn't consider that a particularly good question; the question was
to which the answer is very simple: Mainsoft is not a company that is "simply porting old versions of IE and WMP to other operating systems".
Mainsoft is a company whose product is a library to implement the Win32 API atop other operating systems. The "MainWin: How It Works page on Mainsoft's Web site says
(Note that Windows NT isn't just a kernel, it's a complete OS and window system/GUI; the stuff being rehosted is presumably large amounts of userland code.)
I'm also not sure why Thurrott thought the fact that Mainsoft had access to NT source code was some Deep Dark Secret that his informant had revealed to him, as per his comment
given that there's a press release on Mainsoft's site, linked to by an item on Mainsoft's home page , that says
(I'm also not sure why he speaks of "old versions" of IE and WMP being ported; another item on Mainsoft's Web site says
which would seem to imply that the version of IE 5 that was ported to UNIX was about as far from "old" as one could imagine; no, they may not have ported IE 5.5 yet, but, at the time they ported IE 5.0, it was as new as you can get.)
Methinks Thurrott should, before he speaks further on this topic, spend an hour or so browsing the Mainsoft Web site, at least if his goal is journalistic accuracy rather than journalistic excitement (you can often write far more exciting stories if you're not constrained by such boring mundane restrictions as a requirement to have what you say correspond, to some extent, to reality).
He said "clipboard", not "drag-and-drop".
The problem is, I suspect, that Qt doesn't acknowledge the existence of the "clipboard" selection in X (which is documented in the ICCCM, even if they didn't bother assigning an XA_ atom to it); instead, it uses only the primary selection.
This has two disadvantages:
I suspect the first problem could be fixed by having the QClipboard code in Qt for X assert ownership of both the primary and clipboard selections, and having it supply the contents of the primary selection only if the clipboard selection isn't set (for backwards compatibility with applications using older versions of Qt).
The second problem would be harder to fix, as you'd have to:
I assume the second sentence is joking; the first Sequent machines (Balance) were NS32K-based, as were Encore's first machines. Sequent switched to 386's for the Symmetry machines - I forget what Encore did.
There was also a PC532, which was a home-brew NS32532 design for which there's a NetBSD port.
...which misses the point the person to whom you were replying was making. He said:
which should perhaps have been stated as "I just can't see serious demand for FreeBSD/Linux games" to make it clear that it's not Linux vs. BSD he's talking about, it's Windows vs. everything else lumped together.
I.e., he's saying that releasing games for non-Windows platforms - regardless of which platforms those are, and regardless of whether the version for FreeBSD is native or just the Linux version made to install and run on the Linuxator - later than the Windows version could lead to lower sales for the non-Windows versions, leading to less incentive for developers to make games run on those platforms.
Perhaps some people do, but I don't, because
I.e., whilst there's BSD-compatible stuff "under the hood" of MacOS X, I get the impression that the BSD-flavored UNIX APIs there are not what most MacOS X desktop applications (and maybe not even most server applications) will use, so porting an application that runs on one UNIX-flavored OS (e.g., Linux) to *BSD (the BSDs are also UNIX-flavored OSes) doesn't make the application much more friendly towards the non-UNIX-flavored APIs that I suspect most MacOS X appls will use.
Note that
and
are in part arguably physics questions (i.e., "how fast can you make transistors switch?", "how fast an optical switch can you make?", etc.).
The question
strikes me as being a more purely CS question (although with stuff such as Adelman's DNA computing it might not be pure CS either - toss in a little chemistry...).
Now, I'd put "is P = NP?" on the list....
As does the English country names and code elements page on the ISO 3166 Maintenance Agency Web site. (The French country names and code elements page says it's "CHRISTMAS, ÎLE".)
Well, in the Berlin FAQ, they say:
so they at least realize that it will probably ultimately need to be X-compatible - there are just too many X applications out there for them to treat X as irrelevant.
It may not have X support now, but, in that FAQ, they quite explicitly say that it's not ready for prime time yet:
so the fact that it currently lacks X compatibility may not really mean that much.