Pre-5.x SunOS was originally BSD-derived, although it picked up rather a lot of System V in its life; if that qualifies it as System V, then all the BSD stuff SVR4 picked up, and all the BSD stuff various other SV derivatives picked up, might qualify them as BSD.
Of course, rather a lot of pre-5.x SunOS (and probably rather a lot of stuff in other UNIXes people might consider to be "BSD") came neither from BSD nor System V, but from the vendor of the OS (the SunOS 4.x VM system and dynamic linking system, for example, were designed and implemented at Sun).
...Later on, I can customize whatever I want, but I don't want to have to deal with every feature at once.
This sounds like "progressive disclosure", an idea I first saw mentioned in articles about the Xerox Star. See, for example, this section from what I infer is an essay in the book Bringing Design to Software, which says:
The
Open command was the basis for applying a technique of progressive disclosure--showing the user only the relevant information for a task at hand, and then providing a way to reveal more possibilities as they were needed.
Perhaps not exactly the same idea, but, if not, it still might be a somewhat related idea.
And even then, the benefit will only affect software on operating systems that offer both user and kernel level threads like BeOS and Solaris UNIX. NT doesn't really cut the mustard.
In what fashion? Its threads may not be "both user and kernel level" in the sense that there are user-level threads that can be executed by a pool of kernel-level LWPs, with the possibility that there are more user-level threads than kernel-level LWPs, as is the case in Solaris, but I don't see why that's necessary in order to get a speedup to a threaded program by adding processors - would not the model I think NT uses, wherein every thread known to userland is known to the kernel (I ignore "fibers" here), be sufficient?
If nothing else, the 32-bit limitations of the architecture are hurting Intel's sales in the lucrative server market (where 10's of gigabytes of RAM are common, and 100's not unknown).
...although, of course, one can support more than 4GB of RAM with a 32-bit processor, in the sense of a processor that can't handle more than 32-bit linear virtual addresses, as long as the processor's physical addresses can be more than 32 bits (as is the case with most, if not all, P6-core processors - Pentium Pro, PII, PIII) and as long as the chipset can handle it.
It may be less convenient, as one might have to have a process manually map stuff into and out of its address space if you want a single process to use more than 4GB of RAM (as opposed to, say, having file systems use it as a buffer cache, although that may also involve switching mappings), but it's certainly still possible.
(I say "linear virtual addresses" because, whilst the x86 segmented virtual addresses go up to 48 bits, they first get mapped by the segmentation hardware to a 32-bit linear address before being used as physical addresses, if you haven't enabled paging, or before being run through the page table, if you have enabled paging; not only are 48-bit addresses not necessary for accessing more than 4GB of physical memory, they don't even help you to access it.)
To solve the branch problem, IA-64 doesn't use branch prediction. This is the really important part of EPIC. It executes both branches and once the correct path is know it discards the instructions it executed on the wrong branch.
I assume you mean that it performs speculative execution (which is what you described) in addition to having predicated instructions, e.g. speculatively executing predicated instructions before it knows what's in the instruction's predicate register, and throwing away instructions' results as soon as it finds out that the predicate register was false.
(I.e., predicated instructions aren't the same thing as speculative execution; don't automatically conclude that Merced does speculative execution merely because IA-64, of which Merced is planned to be the first implementation, has predicated instructions.)
and a more familiar climate, similar to Linus's homeland Finland (they don't get a lot of snow in LA, do they... ).
One presumes the above is Sengan's own April Fool's joke (my Russian vocabulary has largely evaporated - or, at least, been moved to tertiary storage - but there wasn't anything about LA in the article), given that Transmeta isn't in LA.
But we don't get much snow here in Silicon Valley, either.
Solaris has {various things} and best of all, its source code is freely available to look at (and modify for personal use).
Really? I found this page for the Solaris SPARC and Intel Source code Program, but if you follow the Download the agreement link under "Licensing Agreement", you find it says "Please note that we cannot accept applications from non-educational institutions nor from individual students."
So to what other program are you referring to when you say "its source code is freely available to look at (and modify for personal use)."? Given that you didn't qualify that as "freely available to educational institutions", you clearly weren't referring to that program, unless I missed something else that indicates that you can get the source even if you're not an educational institution.
More important, some months ago some guy posted an url here. There was some sceenshots showing off Qt with a Next theme, surely looked awesome. Maybe someone remember the url, I don't??
I didn't, either, but AltaVista Is Your Friend; I eventually found this Linux Weekly News page, which said, near the bottom:
The beta version of Qt 2.0 has been
announced. An anonymous source provided us with this screenshot of a partial port of KDE to Qt 2.0. It demonstrates one of Qt's new styles, the "platinum" look, meant to appeal to MacIntosh aficionados. In addition, a screenshot of the Qt "metal" demo (Qt widgets) is also available.
Only a fool would want an floppy-type drive to automount anymore these days.Why ? Can you say computer viruses and other such garabge?
And the reason why automounting a floppy disk is bad, and manually mounting it is not bad, is? (NOTE: automount and autorun aren't the same thing. Automount would be something like "if you refer to something under/floppy, and there's a floppy disk in the drive that/floppy is set up to automount, and that disk isn't currently mounted, mount it on/floppy." Autorun, for a floppy drive, would be something like "if the machine detects that a disk has been put into the floppy drive - which, on a PC, would probably involve polling the floppy drive - mount it and run autorun (or whatever) on the root directory, if it exists.")
Unix is a multiuser system, so anything that would change the operating environment for everyone at once requires root privileges, whether it's changing the CD or editing XF86Config.
This is perhaps better stated as
Unix systems can be multiuser systems; on such a system, anything that would change the operating environment for everyone at once should require root privilege (or, if your system has more levels of privilege than "ordinary" and "root", sufficient privilege), whether it's changing the CD or editing XF86Config.
I.e., disable automount on a server, perhaps, but don't prohibit users from putting it on their own single-user desktop machine.
OpenDoc, originally developed by several industry software leaders, is an object oriented software component architecture designed to accelerate the industry's shift from monolithic, one-size-fits-all applications to more flexible and modular object oriented component-based applications. IBM's OpenDoc offering provides a collection of 'as is' freeware class libraries and frameworks (including source code) that can be reused by advanced C/C++ developers wishing to build C++ desktop applications requiring integrated compound document and component services. As a rich set of compound document technology, advanced developers can leverage and reuse this freely available technology in the development of desktop operating system optimized applications written purely in C++ on OS/2 WARP, Windows 95, Windows NT and AIX/600. OpenDoc supports IBM's VisualAge for C++ or Microsoft's Visual C++ compilers.
With the industry's revolutionary shift to network computing and e-business internet solutions, IBM has evolved its component software strategy to be based on the exciting 'write once, run anywhere', network-savy capabilities of the Java and JavaBeans component technologies. While JavaBeans represents the centerpiece of IBM's component strategy, IBM will continue to make the OpenDoc technology available as freeware for developers of advanced C++ solutions to leverage. For more information on IBM's component software strategy, visit our Application Development website.
The IBM OpenDoc technology is available to download at no cost, and is being provided as 'as is' freeware without formal IBM technical support. IBM plans no major new releases beyond the currently available OpenDoc v1.2, but does plan, at a future date, to make full OpenDoc source code available in the public domain for reuse by advanced C++ developers.
If you are student of C++, component software, compound document technology or are an advanced C++ developer wishing to reuse and leverage robust C++/SOM class libraries technology in the development of your solutions, we welcome you to download and reuse the freeware OpenDoc technologies!
I'm not familiar with the details of OpenDoc, so I don't know how useful that stuff (which I infer isn't OpenDoc in its entirety) would be outside the environments they mention.
...I recall reading a number of months ago that MS did a port of IE to (I believe) Solaris,
Yes, and, if I remember correctly, HP-UX as well.
...using a third party tool that emulated the Win API.
MainWin, from Mainsoft; Mainsoft's home page mentions that it was used for the IE 5.0 port, and an older press release mentions that it was used for IE 4.0 as well (that used to be what Mainsoft's home page mentioned, before 5.0 came out).
...monstrous, statically-linked binaries seem more their style.
cranford$ cd ~/microsoft cranford$ file bin/iexplorer bin/iexplorer: Bourne shell script text cranford$ tail -8l bin/iexplorer
executable=${MSFT_HOME}/progs/${OSdir}/startup if [ -x $executable ] then exec $executable $target $@ fi
echo "Support for $OSname $OSrev has not been installed on this system." >&2 cranford$ file progs/sunos5/startup progs/sunos5/startup: ELF 32-bit MSB executable, SPARC, version 1, dynamically linked (uses shared libs), stripped cranford$ size progs/sunos5/startup 23004 + 1546 + 18432 = 42982 cranford$ ldd progs/sunos5/startup libX11.so.4 =>/usr/lib/libX11.so.4 libc.so.1 =>/usr/lib/libc.so.1 libXext.so.0 =>/usr/openwin/lib/libXext.so.0 libsocket.so.1 =>/usr/lib/libsocket.so.1 libnsl.so.1 =>/usr/lib/libnsl.so.1 libdl.so.1 =>/usr/lib/libdl.so.1 libmp.so.2 =>/usr/lib/libmp.so.2
Not statically linked, and not very big. There is also a big pile of.so files with names that look suspiciously like those of Win32 DLLs but with.dll replaced by.so; those might be loaded at run time with dlopen().
Interix (www.interix.com) have something similar to run Unix/Linux apps on NT.
In what way is Interix, a product that provides a UNIX-compatible environment under NT, letting you compile source code for UNIX applications and run the resulting binaries under NT, "similar" to something that provides a virtual machine in which you can run a complete foreign operating system's binary code, including kernel-mode code?
(No, you can't run binaries from a UNIX-flavored system under Interix; the Interix FAQ says as much in the section "The INTERIX Environment":
Can I run any of my UNIX applications with INTERIX?
INTERIX doesn't allow you to take UNIX binaries (Linux/BSD/SCO/AIX etc.) and run that binary on a Windows NT system. The INTERIX Software Development Kit is a source level tool that allows you to take existing open systems source code and recompile the source code into a native NT binary with little or no effort.
KDE is coming along nicely now, I wish the devlopers would clean up some of the file ops, like finish a working Explorer clone that has smb capability
I'm not sure it's the job of a file manager to have SMB capability, at least if your OS's kernel has an SMB client pluggable file system, as Linux does; does the KDE file manager have NFS capability, or does it just treat an NFS-mounted file system the same way it treats a local file system? If the latter, than you presumably get your SMB capability from "smbfs", unless you want to get at, say, NT server capabilities (e.g., viewing and modifying ACLs) that you (currently, at least) can't get at through the kernel's file system API.
Slashdot Mirror
Of course, rather a lot of pre-5.x SunOS (and probably rather a lot of stuff in other UNIXes people might consider to be "BSD") came neither from BSD nor System V, but from the vendor of the OS (the SunOS 4.x VM system and dynamic linking system, for example, were designed and implemented at Sun).
This sounds like "progressive disclosure", an idea I first saw mentioned in articles about the Xerox Star. See, for example, this section from what I infer is an essay in the book Bringing Design to Software , which says:
Perhaps not exactly the same idea, but, if not, it still might be a somewhat related idea.
In what fashion? Its threads may not be "both user and kernel level" in the sense that there are user-level threads that can be executed by a pool of kernel-level LWPs, with the possibility that there are more user-level threads than kernel-level LWPs, as is the case in Solaris, but I don't see why that's necessary in order to get a speedup to a threaded program by adding processors - would not the model I think NT uses, wherein every thread known to userland is known to the kernel (I ignore "fibers" here), be sufficient?
I was under the impression that "auto-parallelizing" compilers can convert, say, some Fortran or C/C++ code into multi-threaded code.
See, for example, this Sun white paper on their compilers, which, it appears, can auto-parallelize loops to run on multiple processors.
...although, of course, one can support more than 4GB of RAM with a 32-bit processor, in the sense of a processor that can't handle more than 32-bit linear virtual addresses, as long as the processor's physical addresses can be more than 32 bits (as is the case with most, if not all, P6-core processors - Pentium Pro, PII, PIII) and as long as the chipset can handle it.
It may be less convenient, as one might have to have a process manually map stuff into and out of its address space if you want a single process to use more than 4GB of RAM (as opposed to, say, having file systems use it as a buffer cache, although that may also involve switching mappings), but it's certainly still possible.
(I say "linear virtual addresses" because, whilst the x86 segmented virtual addresses go up to 48 bits, they first get mapped by the segmentation hardware to a 32-bit linear address before being used as physical addresses, if you haven't enabled paging, or before being run through the page table, if you have enabled paging; not only are 48-bit addresses not necessary for accessing more than 4GB of physical memory, they don't even help you to access it.)
I assume you mean that it performs speculative execution (which is what you described) in addition to having predicated instructions, e.g. speculatively executing predicated instructions before it knows what's in the instruction's predicate register, and throwing away instructions' results as soon as it finds out that the predicate register was false.
(I.e., predicated instructions aren't the same thing as speculative execution; don't automatically conclude that Merced does speculative execution merely because IA-64, of which Merced is planned to be the first implementation, has predicated instructions.)
Yeah, I've seen it through the smog on the way to work.
I must've been inside when that happened. (The hail, on the other hand, I was in the middle of.)
One presumes the above is Sengan's own April Fool's joke (my Russian vocabulary has largely evaporated - or, at least, been moved to tertiary storage - but there wasn't anything about LA in the article), given that Transmeta isn't in LA.
But we don't get much snow here in Silicon Valley, either.
This brief history of mcsun (and its mcvax predecessor) seems to suggest "kremvax" was an invention of the Dutch, not of the Russians....
You're probably referring to Sun's Community Source License; these are the products they currently have under that license - but Solaris isn't one of them.
Really? I found this page for the Solaris SPARC and Intel Source code Program, but if you follow the Download the agreement link under "Licensing Agreement", you find it says "Please note that we cannot accept applications from non-educational institutions nor from individual students."
So to what other program are you referring to when you say "its source code is freely available to look at (and modify for personal use)."? Given that you didn't qualify that as "freely available to educational institutions", you clearly weren't referring to that program, unless I missed something else that indicates that you can get the source even if you're not an educational institution.
Wrong. "fvwm" and Enlightenment are window managers; KDE and Gnome are collections of a bunch of pieces of software, including:
People can argue about whether that stuff is useful, but it's difficult to argue that it's not there....
See the What is KDE? document and the GNOME User's Guide for more details.
I didn't, either, but AltaVista Is Your Friend; I eventually found this Linux Weekly News page, which said, near the bottom:
And the reason why automounting a floppy disk is bad, and manually mounting it is not bad, is? (NOTE: automount and autorun aren't the same thing. Automount would be something like "if you refer to something under /floppy, and there's a floppy disk in the drive that /floppy is set up to automount, and that disk isn't currently mounted, mount it on /floppy." Autorun, for a floppy drive, would be something like "if the machine detects that a disk has been put into the floppy drive - which, on a PC, would probably involve polling the floppy drive - mount it and run autorun (or whatever) on the root directory, if it exists.")
This is perhaps better stated as
I.e., disable automount on a server, perhaps, but don't prohibit users from putting it on their own single-user desktop machine.
I'm not familiar with the details of OpenDoc, so I don't know how useful that stuff (which I infer isn't OpenDoc in its entirety) would be outside the environments they mention.
Yes, and, if I remember correctly, HP-UX as well.
MainWin, from Mainsoft; Mainsoft's home page mentions that it was used for the IE 5.0 port, and an older press release mentions that it was used for IE 4.0 as well (that used to be what Mainsoft's home page mentioned, before 5.0 came out).
...but, yes, if Microsoft ports Office to any UNIX-flavored OS, I suspect they'll use MainWin (that being what they used to port IE).
cranford$ file bin/iexplorer
bin/iexplorer: Bourne shell script text
cranford$ tail -8l bin/iexplorer
executable=${MSFT_HOME}/progs/${OSdir}/startup
if [ -x $executable ]
then
exec $executable $target $@
fi
echo "Support for $OSname $OSrev has not been installed on this system." >&2
cranford$ file progs/sunos5/startup
progs/sunos5/startup: ELF 32-bit MSB executable, SPARC, version 1, dynamically linked (uses shared libs), stripped
cranford$ size progs/sunos5/startup
23004 + 1546 + 18432 = 42982
cranford$ ldd progs/sunos5/startup
libX11.so.4 =>
libc.so.1 =>
libXext.so.0 =>
libsocket.so.1 =>
libnsl.so.1 =>
libdl.so.1 =>
libmp.so.2 =>
Not statically linked, and not very big. There is also a big pile of .so files with names that look suspiciously like those of Win32 DLLs but with .dll replaced by .so; those might be loaded at run time with dlopen().
Well, some members of the audience actually saw the parenthetical note the author put after that comment, which was
but I guess not everybody did.In what way is Interix, a product that provides a UNIX-compatible environment under NT, letting you compile source code for UNIX applications and run the resulting binaries under NT, "similar" to something that provides a virtual machine in which you can run a complete foreign operating system's binary code, including kernel-mode code?
(No, you can't run binaries from a UNIX-flavored system under Interix; the Interix FAQ says as much in the section "The INTERIX Environment":
)There's a missing "h" in there, and it wasn't made a link; here's a link to the patent.
But wasn't that mentioned in a Slashdot article ages ago?
Or Mainsoft did.
I'm not sure it's the job of a file manager to have SMB capability, at least if your OS's kernel has an SMB client pluggable file system, as Linux does; does the KDE file manager have NFS capability, or does it just treat an NFS-mounted file system the same way it treats a local file system? If the latter, than you presumably get your SMB capability from "smbfs", unless you want to get at, say, NT server capabilities (e.g., viewing and modifying ACLs) that you (currently, at least) can't get at through the kernel's file system API.
Red Hat is listed as a sponsor on the Linuxconf Web site, but there's nothing I saw in my quick look to indicate that it's a Red Hat project.