By definition, if it hadn't been GPLed, it would never have registered in the would of contemporary computing.
If it hadn't been GPLed, it might've been released under a BSD-ish or X-ish license (in fact, I have the impression that the first license Torvalds put on it wasn't the GPL, but was some license of his own, and that he later GPLed it; I don't remember the details of the terms he originally put on it).
I suspect any license that would've made it free-as-in-speech would've been sufficient, although there is the question of whether that would've caused non-free commercial derivatives to spring up, and what effect that would've had.
(When it comes to the original question, my personal suspicion is that it would, indeed, probably not have been a big success had it not been free-as-in-speech (and thus contributed to by a cast of thousands) and free-as-in-beer (and thus available to members of that cast of thousands to put on a machine at home, or at school, or...).)
Are there any free or commercial UNIX compatible operating systems that are not derived from the original code?
Are? I'm not sure.
Were? Yes - a company called Mark Williams had a V7-clone called Coherent; I remember hearing a story that AT&T actually had Dennis Ritchie reading their code to make sure they hadn't stolen any UNIX code.
Mark Williams is no longer with us, and presumably the same is true of Coherent.
So at least one company was "crazy enough to undertake all this in a commercial, proprietary setting"; I don't know how successful they were when they were around, nor do I know whether the fact that they're not around any more says that they really were crazy.
The 386 was the first 32-bit x86 processor, and the first one with support for demand paging - it had a new instruction-set architecture. Not particularly revolutionary in general, but revolutionary for x86.
The Pentium implemented the same instruction set architecture (with some minor additions); it was primarily revolutionary in its implementation, in that it was the first superscalar x86 chip to ship (again, not particularly revolutionary in general, but revolutionary for x86).
The latter means that, with Pentium, they pretty much, well, "went for the speed race".
Intel should be coming up with new technology
...or getting it from HP. (I have the impression a lot, perhaps most, of the ideas in IA-64 came from HP.)
The Lame Unit In I.T. does have a new instruction set, because it'll be the first IA-64 implementation; is that the kind of "better technology" you're looking for?
Interpreted languages are superior in a number of ways from the standpoint of the programmer. They are simpler to modify and read,
"Simpler to modify and read" in what sense? If you mean it's easier to read programs written in those languages, and to modify an existing program written in those languages, how much of that is due to the language and how much of it is due to its implementation being interpretive?
(Is "interpreted" a property of a language or an implementation? I think the first LISP implementations were interpreted, but LISP compilers exist; most C implementations are compiled, but I think C interpreters exist. I could imagine Perl or VB implementations that generate compiled code - I have the impression that VB code can be compiled into machine code - and if you were to translate one of this sort of language into, say, Java byte codes, and to run them in an environment with a JIT compiler, is it interpreted or compiled?)
Some of the benefits may be due to the implementation being interpretive, e.g. an interpreter might be able to do a better job of telling you where something blew up (although symbolic debuggers can, at least sometimes, do a decent job of that, at least if the code is unoptimized), but I'm curious whether a sufficiently clever non-interpretive environment could do as good a job.
I.e., speeding up "higher-level" languages might be doable by means other than throwing faster processors at them; one can debate whether they're better doable by those means, but that's a separate question.
But, yes, it's not ipso facto the case that faster processors server only to encourage sloppy code; some might debate whether software and what it can do has progressed in any truly useful fashion since the days of the Manchester Mark 1, but....
Windows networking code is anything but posix compliant.
As far as I know, the POSIX standards for network APIs (e.g., P1003.1g) are still drafts, so, arguably, NO networking code is "POSIX compliant"; has the standard been approved yet?
Microsoft has decided to call their network api "windows sockets".
They decided that ages ago; it's BSD-like, but has some of its own stuff (e.g., I think it lets you start a host name lookup without waiting for it to finish, and to wait for it to finish later, and, I suspect, to wait either for it to finish or some other event to come in, so you can handle other events while you're waiting).
The aim of this project, at least in part as I understand it, is to write an api for linux that will allow the use of "windows sockets" code on posix compliant systems.
If it works on POSIX-compliant systems, it's not an "API for Linux", it's an API for POSIX-compliant systems - or, rather, for systems that provide a networking API that looks like the POSIX/POSIX draft one, which would include but not be limited to UNIX.
Or, perhaps, it's for systems with a UNIX-style network API, rather than the (still apparently in draft form, as per the above) POSIX network API.
Of course, MainWin already has support for Winsock, according to this page on the Mainsoft site, so it's not as if that's not already available. And it supports more than just the sockets API; I rather suspect you'd need to support a heck of a lot more of the Win32 API than just the Winsock calls to port the server applications you mentioned, so I rather doubt that there's some project to deal only with Winsock.
The major difference between MainWin and this being CygWin is open source.
No, the major difference between MainWin and Cygwin is that they go in opposite directions; MainWin provides a Win32 API atop UNIX-compatible OSes, while Cygwin provides a UNIX API atop Win32 OSes. If you want to contrast Cygwin to a non-open-source UNIX-apps-atop-Windows product, contrast it with Interix, and if you want to contrast MainWin with open-source Windows-apps-atop-UNIX software, contrast it with Wine or TWIN or Twine, say.
and they use Mainsoft as a kind-of-reverse WINE to translate Win32 to Unix calls
Reverse WINE? Isn't that what Wine does - translates Win32 (and Win16, and DOS) calls to Windows calls, so you can run Windows apps on UNIX-compatible x86 OSes, and compile source for those apps to make UNIX apps?
(And I'd think that SQL or Exchange would be the remotest of possibilities just for marketing reasons.)
Maybe Exchange, and maybe Outlook - it depends on whether they'd want to force folks with UNIX-compatible OSes on their desk to switch to Windows so they can read mail from an Exchange server, or whether they want to let UNIX systems read from an Exchange server on NT (rather than, say, some UNIX-based mail server).
A contradiction between "thin and efficient" and "several million lines of Windows source code"? Perhaps the "thin and efficient" layer implements very low-level Win32 operations, and the "several million lines of Windows source code" make those Win32 calls (and undocumented Windows calls implemented by MainWin, if any), so that most of the environment consists of said Windows source.
"They", in the sense of "Mainsoft", sell Visual SourceSafe for UNIX, which is Microsoft's source code control system rehosted to UNIX using Mainsoft's MainWin product - MainWin isn't an app, it's libraries and the like to let you build Win32 apps to run on the UNIX-compatible OSes on which MainWin is offered.
Internet Explorer was ported to various UNIX-compatible OSes using it, as were a variety of apps - none of them looking like they'd be the Top Ten Shrink-Wrapped Windows Applications at your local computer store (they're more specialized) - as seen by checking out Mainsoft's press releases. Those applications don't all come from Mainsoft and don't all come from Microsoft; they come from a variety of vendors.
Mainsoft, or Softway? Microsoft did buy Softway, whose Interix product is sort of an inverse MainWin (it's a subsystem+libraries for NT that lets you recompile source code written for applications for UNIX-compatible OSes and run them on NT), but I have seen no announcement that they bought Mainsoft.
Microsoft probably views Interix as a way to get a site to move to NT if they have a pile of (in-house) UNIX apps, as the press release on their purchase suggests:
"Our acquisition of Softway's assets is a demonstration of our commitment to provide interoperability for applications and other solutions between UNIX and Windows," said Keith White, Director of Marketing, Business and Enterprise Division at Microsoft. "While we recommend that customers migrate their software solutions to native 32-bit Windows, today's announcement allows certain customers to move rapidly to a Windows NT-based solution during that transition process."
and they probably view WISE (Windows Interface Source Environment) products such as MainWin as a way of encouraging people to write Win32 applications rather than UNIX (or MacOS) applications.
Microsoft is likely willing to spend an awful lot of money on "market research". At this point, they are probably just trying to find out how viable a platform Linux is.
Microsoft may or may not be spending money on this; MainWin is a product of Mainsoft, not Microsoft, so all Microsoft may have done is said "we won't yank your license for the Windows source in MainWin if you do a Linux port", they haven't necesarily contributed money or other resources to this.
(It is interesting to note that they don't already have an x86 UNIX in the list of platforms on which MainWin is available, so, if they port it, Linux may be the first UNIX-that-runs-on-a-PC on which MainWin is available.)
My question is this, though: what underlying toolkit will they use. Will it be based on raw Xlib (good for speed)
Probably. I don't have IE-for-Solaris (the port of which was done with MainWin) handy, but I don't remember it being dynamically linked with any toolkit libraries (although I also don't remember whether it was dynamically linked with Xlib, so that doesn't by itself prove anything). The UI of IE-for-Solaris is somewhat Motifish, but looks different enough that it's unlikely to be Motif. I suspect it's neither GTK+ nor Qt, either - I seem to remember the bevels on the scrollbars being narrower than those of Motif, GTK+, or Qt.
They're extremely unlikely, I suspect, to use KDE or GNOME - not all Linux systems necessarily have those, and they don't require either of them for IE/Solaris, so MainWin doesn't require them.
Linux core (the True Linux or kernel) will always be the same among the distros.
Well, applications often sit atop more than just the kernel - either they're dynamically linked (and thus sit atop the system shared libraries), or they're statically linked (and may have wired into their binaries assumptions about, say, the locations of files used by the library routines).
Fortunately, it appears that most distributions on which you'd run shrink-wrapped applications (as opposed to, say, a "slap this on a PC with multiple network interfaces and you have a router/firewall" distribution) may be converging on glibc 2.x (although, if the shrink-wrapped application is called "Netscape Communicator 5.0", or whatever the next release is, it may require glibc 2.1 or later, as per Mozilla's requirements); I don't know if any other libraries those applications might use differ widely between distributions.
I note, though, that "Linux core (the True Linux or kernel) will always be the same among the distros." isn't necessarily entirely the case - they aren't all using the same kernel version (Debian's still on 2.0[.x] - no, Potato isn't "done" yet - but I think the other "major" distributions have gone to 2.2[.x]), and they might make local changes (which, of course, other distributions could adopt - blah blah blah GPL blah blah blah - but that doesn't mean they will).
In some cases, local changes are just "enhancements", in which case an application vendor might choose Just To Say No and not use features added by a distribution. Of course, the trick there is how to discover what's distribution-unique; an LSB "reference implementation" might be useful there - if it doesn't run on the reference implementation, it might not run on all LSB-compliant distributions.
I'm curious what "support" means in this context. (NOTE: in the following, I'm using "Red Hat" because it's the one people seem to most fear becoming the Only Linux For Which People Release Software.)
Does it mean "we're releasing a version that can be installed on, and run on, a Red Hat system, but that depends on stuff (installer, libraries, file system layouts, etc.) on a Red Hat system, so it won't work, or won't work quite right, on a different distribution"?
Or does it mean "well, we're not trying to make it Red Hat-only, but we're only going to test it on Red Hat, and are only going to offer support for customers running Red Hat - if you call us up because it doesn't work on OpenLinux or TurboLinux or SuSE or Debian or..., we'll tell you how sorry we are to hear that, and then we'll suggest you install Red Hat if you want to run our software"?
(It may well be that different vendors mean different things by "support".)
To some extent, the first of those could perhaps be worked around by adding stuff to your non-Red Hat system (unless the changes needed to get the software to run are incompatible changes - but I don't know how many users, other than technoids, will want to do that). Perhaps that'll provide an incentive for vendors to make their distributions more Red Hat-like, for better or worse.
The second of those may be less of a problem, in that software that's not "supported", in that sense, on other distributions may Just Work on those distributions - but there may be customers for whom "it works, but we won't answer your phone calls" may not be good enough.
However, I think most Linux vendors would be willing to support several Linux variants if they knew the customers were there, and the best way for them to find out that is the case is for the customers to let them know directly...
...and those vendors might, in turn, apply pressure on developers of Linux distributions to try to make it easier for software to work on multiple distributions - and for software vendors to test software without having to do a ton of testing on N different distributions. (The LSB appears to be intended to have a sample implementation; however, the LSB Organization page says:
The sample implementation will be used to compare and evaluate features that are being considered for inclusion in the standard. The sample implementation is not meant to be used as a reference implementation for the purpose of resolving conformance issues among distribution vendors, though it may be used during the investigation of such issues.
so it won't necessarily be usable as a distribution on which vendors can do testing of their applications.)
(Hmm. I'm curious how vendors of Windows applications handle Windows OT, e.g W95 and W98, and Windows NT? I wouldn't be at all surprised to hear that they have to test applications on both platforms if they're going to support them on both platforms - and to test them on different versions of those platforms, e.g. W95 and W98, or NT 4.0 and NT 4.n^H^H^H4.0 SPn. Heck, the Windows OT and Windows NT implementations of the Win32 API probably differ a lot more, in their kernel and API libraries, than would the kernel and API-library implementations of two 2.2-kernel/glibc-2.1 Linux distributions.)
You can get wide-format monitors from SGI as part of the Octane package, I believe.
You can get wide-format monitors with the SGI name on them from a variety of places; Number Nine sells (at least in the US; their online store only sells in the US) the Digital Flat Panel Solution Pack for PC's (and I think they had a package for Macs as well), which includes a Revolution IV-FP video card and the SGI monitor. It's probably available from various distributors as well. It comes with drivers for operating systems from Redmond; Accelerated-X also includes drivers, as does, I think, the latest XFree86. (I see nothing in the graphics card section of the BeOS Ready List for Intel about it, and I wouldn't be surprised to hear that there's no OS/2 drivers for it, either, alas, as, when I get a second disk for my home machine, I'd be tempted to install those on it as well, just to see what they're like....)
They are really nice, but heavy as hell,
The ones you installed are presumably CRTs; this one is an LCD, and thus presumably not so heavy (or bulky)...
We set them up to run 1600x1024 at 75Hz.
...and give you 1600x1024 as well.
The price on Number Nine's online store is about USD 2800, but I got mine for about USD 2200, at least several months ago - I seem to remember the list price being less than USD 2800 when I bought it, so maybe it's gone up; I don't know what the price would be outside the US.
Stable Hues -Due to reversal of sub-carrier phase on alternate lines, any phase error will be corrected by an equal and oposite error on the next line, correcting the original error. In early PAL implementations it was left to the low resolution of the human eye's colour abilities to provide the averaging effect; it is now done with a delay line.
That stuff was done before anything we'd think of as a "checksum" in the digital sense would fit inside a TV, as far as I know - it's all analog....
Here's the WorldWide TV Standards - A Web Guide main page, with information on TV broadcast standards; unfortunately, I didn't see anything there that said what the memoire is avec which the French SECAM system comes; how exactly does it differ from PAL?
Also, I might add, America contributes more financial aid to other nations than any other country in the world (including Canada).
And the US has a higher GNP and higher population than most if not all other "first world" nations; do we contribute more financial aid as a percentage of GNP than any other developed country in the world - or are we, as I've seen claimed, closer to the bottom of that list?
In the ideal world, you'd contribute effort to the open source component,
In the real world, not everybody on the planet who might use an X server is an X server wizard in a position to "contribute effort to the open source component".
most programs stopped working, it didnt store libraries and fonts in right directories and dselect keept bitching about dependencies (it thought i didnt have X installed on my system)
I don't seem to remember seeing those problems on my Debian partition at home, but I didn't install XiG's libraries - I bought it for the server, not for the client code (at the time, XFree86 didn't, as far as I know, contain support for the Number Nine Revolution IV-FP card; amusingly enough, I have XiG to thank for discovering that XFree86 later added support, as they had something on their Web site, as I remember, comparing Accelerated-X and XFree86 performance with that card), so I'm just using the XFree86 client code that came with Debian.
Debian doesn't start up xdm on my home machine because it doesn't think XFree86 has been set up, but that's about the only place I've seen where Debian was unhappy about Accelerated-X.
They're trying to advertise their product like every other company does.
Well, some other companies may well advertise their product[s] in a clueless fashion, so "like every other company does" doesn't necessarily mean "in a fashion that shouldn't be roasted".
Methinks "our product is better, because it's not a piece of free software, it's Commercial-Quality Software" may not be the best approach if you're trying to sell to a community of people running an operating system made out of, err, umm, free software....
I.e., it's not clear that
[The X server] is more than twice the size of the Linux kernel and much, much busier. Critical communications, fonts, drawing, windowing, mouse, keyboard, memory functions, and more all depend on the X server.
is in and of itself a sufficient reason to believe that "free software does a good job" applies to an OS kernel and OS libraries (Linux and glibc, say) but not to an X server.
The guys at Xig Graphics know how to write X Servers.
So are you saying that they know how to make good servers for something that's still shit?
Or are you saying "X" when you mean "XFree86"?
At least some posters in this thread, when they say "X is shit", are referring to the X Window System, rather than to a particular set of server implementations for it; are you saying
X, in and of itself, sucks, but XiG manage to make servers that make it suck less;
X, in and of itself, dones't suck, but the XFree86 servers suck?
(I'm not taking a position on whether X sucks or not; I'm just asking whether you think using XiG's servers is sufficient to make it not suck, or whether the real answer might be "use something other than X", e.g. Berlin?
It drives me nuts that I can't cut and paste from emacs to Netscape. If Accelerated X would fix that, it might be worth the money.
The Accelerated-X server's involvement in cut-and-paste is that it accepts requests from X clients to set and get various properties on windows, and the like; the problem you're having is probably a problem with what either Emacs or Netscape is doing, not with what the X server is doing.
Maybe those applications are dynamically-linked with toolkit libraries that are doing the X requests to do the cut-and-paste operations, and maybe, if you also use XiG's versions of the client libraries, it'll work better (or if you relink a statically-linked Emacs with those libraries), but I wouldn't count on it.
I just tried it with GNU Emacs 19.34.3 and Netscape Communicator 4.02 on Solaris 2.5.1 (displaying on Exceed on an NT box); paste-current-selection (i.e., select something in the GNU Emacs window, and hit the middle mouse button in the Netscape window) worked, but true copy-and-paste (select something in the GNU Emacs window, use the "Edit/Copy" menu item in Emacs, go to the Netscape window, select the "Location" box, and try to use "Edit/Paste") didn't - the "Edit" menu had "Paste" grayed out. (I did copy-and-paste rather than cut-and-paste because I ran Emacs on a file to which I didn't have write access; both of them should use the CLIPBOARD X selection in order to Play Well With Others.)
Yes, at least up to a point; if it works too poorly, what's the point?
& does java applet based systems count?
No. A Java applet is just a small locally-run application that happens to be written in Java rather than in some other language (or, perhaps, "that happens to be distributed in the form of Java bytecode" - something distributed in Java bytecode form wasn't necessarily written in Java, as there exist compilers that translate other languages into Java bytecodes, e.g. the JPython compiler) and that happens to use whatever toolkit the environment in which it's running provides. Interesting, potentially cross-platform (if you don't manage to use some platform-specific classes, say), but not the same as the examples many people were giving, e.g. Slashdot or Web mail and calendar systems, wherein "the web is the interface" - if your browser happens to pop up some Java applet that handles input events, I/O, etc. itself and provides its own UI with its own code, the Web isn't the interface, it's just the pipe over which the code for that application was delivered, and perhaps the pipe over which it talks to some server, but if that's sufficient to make the Web the interface, a boring old "widget-centric/shrink-wrap" application downloaded via HTTP "makes the Web the interface" as long as it includes HTTP client code that it uses for some operations.
(Besides, I rather doubt you can make a "Java applet-based" version of the GIMP, or of the other applications/suites I mentioined, for one simple reason - by the time you're done, it'll probably be too big to be called an "applet". "Applet" isn't short for "application written in Java" or "application delivered as Java bytecodes"; the "let" part is a diminutive, indicating that it has to be a small application before it gets to be called an "applet".)
Why Don't you go tell Sun that Star Portal can't work.
Because, according to this press release, StarPortal isn't the sort of "Web-based application" the original poster was citing as a reason why we should all "forget about toolkits". It says
Completing development of StarPortal, a web-based version of the office suite that combines a Java(TM)-based client with the software to enable browser access to office productivity tools.
which appear to be saying it's an application written in Java (see earlier comments in which I note that a Java-based application is just an application written for Java plus some widget set, just as a GNOME application is written in C or C++ or whatever plus GTK+ and a KDE application is written in C++ or whatever plus Qt), not a "web-based application" where you just fill in forms and hit "Submit", as the Web calendar and mail applications some people mentioned are.
Yeah, maybe it's more cross-platform than, say, a UNIX+KDE or UNIX+GNOME application is, but it's not the same sort of application as is, say, Slashdot, that being an example that one of the people to whom I replied gave.
And what about a web based mp3 player? Couldn't they store all the mp3 files on the server and stream to your local machine, saving you from having to find all the mp3s you want and archiving them yourself.
Again, that's not a "Web-based application" any more than an MP3 player that can read files somehow magically becomes "NFS-based" or "CIFS-based" by reading from a file system on a server; the application is a local application, written using some toolkit - toolkits being what the person to whom I originally replied (and who cited Slashdot as an example of "Writing for the Web") said we should "forget".
Are you trying to say that Netscape doesn't have access to your sound card?
No - but if it's playing something itself, it's not as if somebody "wrote for the Web" - they didn't write any application at all to play MP3s, they just used an application that already existed, namely Netscape or a plug-in. If you already have a canned application to perform some function, the mere fact that the canned application happens to be part of a Web browser doesn't mean that, by using that application, you've "written for the Web", it means you haven't had to write it in the first place - that certainly means you don't have to worry about toolkits, but it doesn't help you if that's something Netscape or whatever doesn't do.
Try reading Tim O'reilly's new article on MS vs. Linux.
Oh, you mean this one, which I read several days ago, where he says
Traditional software embeds small amounts of information in a lot of software; infoware embeds small amounts of software in a lot of information. The "actions" in an infoware product are generally fairly simple: make a choice, buy or sell, enter a small amount of data, and get back a customized result.
and
Information interfaces are not as efficient for tasks that you do over and over as pure software interfaces, but they are far better for tasks you do only rarely, or differently each time. In particular, they are good for interfaces in which you make choices based on information presented to you. Whether you're buying a book or CD at Amazon.com, or a stock at E*Trade, the actual purchase is a fairly trivial part of the interaction. It's the quality of the information provided to help you make a decision that forms the heart of the application you interact with.
where he pretty clearly indicates that he does not think that all traditional applications are dead and that CGI scripts will replace them, he indicates that there's a whole pile of new applications for doing new things that are best done with browsers talking to Web servers.
The problem that some people have is that, as, if I remember correctly, Abraham Maslow said, "to somebody whose only tool is a hammer, the whole world looks like a nail". Web-based applications, in the "3270 for the '90s" sense (as somebody described Web stuff several years ago), are cool - but they're not the whole world.
Forget toolkits. Linux-only development is a dead-end. Write for the web and maybe you'll make some bucks like CmdrTaco and Jerry Yang.
(without, it appears, bothering to ask what application the submitter of the question was trying to write).
Writing a custom GUI application to do Internet shopping, or calendar management, or library card catalog searching, might be a dumb thing to do now that we have HTTP servers and clients all over the place (although I'm not about to boldly declare that it is foolish; there may well be reasons why some particular such application makes more sense than a CGI script as a solution for some particular problem); nobody's made a convincing case that writing GUI applications in general is no longer necessary now that we have the Web.
The members of
mozilla.org are employees of Netscape Communications Corporation. We are some of the people who wrote Netscape Communicator. We are the people who know the code best, since (until March 31st) we were among the very small set of people who have ever seen it.
As time goes by, it will no longer be the case that the people who know the code best are necessarily people who are also employed by Netscape Communications Corporation; we intend to delegate authority over the various modules to the people most qualified to make decisions about them. We intend to operate as a meritocracy: the more good code you contribute, the more responsibility you will be given. We believe that to be the only way to continue to remain relevant, and to do the greatest good for the greatest number.
...
Netscape is paying our salaries, and providing hardware and bandwidth in the hope of making mozilla.org a success.
Other than that, Netscape's role is the same as yours: Netscape writes code, and makes use of code written by others. Netscape will contribute new code back to the public just as others will.
(emphasis mine). Has the situation changed since that was written, such that the folks on Mozilla with e-mail addresses ending with "@netscape.com" aren't being paid by Netscape^H^H^H^H^H^H^H^HAOL to work on Mozilla?
That page also says that
Netscape will also continue to provide an executable-only release of Mozilla that bears the "Netscape" brand (e.g., the name "Netscape Communicator."
which, if still true, may mean that there's at least some extent to which a development project by a commercial entity depends on Mozilla, and might put some pressure on Mozilla to have schedules, etc..
However
They are not looking for a profit.
is, to some extent, presumably true, as AOL will probably be giving Netscape {Navigator,Communicator} 5.0 away, just as they're giving 4.x away. However, that's also true of Internet Explorer, if you treat it as a separate program rather than a pile of OS/GUI COM objects to provide HTML display and Internet access, plus a browser wrapper around those objects (if you treat it as the latter - which is true only in Windows - then you could view its developers as part of the Windows OT and Windows NT development teams, I guess).
I believe either Merced or McKinnely will have NATIVE PA-RISC support, rather than emulated support as is the case of x86...
"Native" and "emulated" in what sense? Merced (and, I suspect, McKinley) will be able to directly run x86 code; in what sense is that "emulated" rather than "native"? (The latest Microprocessor Report has a story on Intel's presentation on Merced at the latest Microprocessor Forum; it says
Sharangpani's presentation shed little new light on Merced's IA-32 portion. As disclosed earlier, IA-32 code and data share the same caches and execute in the same function units. [Presumably "same" means "same as what IA-64 code and data use". -gh] When in IA-32 mode, the processor fetches x86 instructions into a separate decoding and scheduling unit that reorders the instructions and executes them using the native execution core. [The article doesn't say that they'll be translated to native instructions. -gh] We expect the IA-32 decoding and scheduling unit to be similar to Pentium III's front end.
As for PA-RISC code, HP's IA-64 documentation online (see my other comment in this thread for a reference) says that the chip won't execute PA-RISC code; software will translate PA-RISC code to IA-64 code, and the IA-64 code is what will be executed. In what sense is that "native" rather than "emulated"?
A while back, I did some calculating of chips based on their SPEC performance, and MHz for MHz, the PA-RISC series is the fastest line of chips.
But if it's easier to make, say, a 21264 run at a given clock rate than it is to make a PA-8500 run at that clock rate, "Alpha wins in the end" regardless - SPEC/MHz isn't necessarily a figure of merit in and of itself.
Slashdot Mirror
If it hadn't been GPLed, it might've been released under a BSD-ish or X-ish license (in fact, I have the impression that the first license Torvalds put on it wasn't the GPL, but was some license of his own, and that he later GPLed it; I don't remember the details of the terms he originally put on it).
I suspect any license that would've made it free-as-in-speech would've been sufficient, although there is the question of whether that would've caused non-free commercial derivatives to spring up, and what effect that would've had.
(When it comes to the original question, my personal suspicion is that it would, indeed, probably not have been a big success had it not been free-as-in-speech (and thus contributed to by a cast of thousands) and free-as-in-beer (and thus available to members of that cast of thousands to put on a machine at home, or at school, or...).)
Are? I'm not sure.
Were? Yes - a company called Mark Williams had a V7-clone called Coherent; I remember hearing a story that AT&T actually had Dennis Ritchie reading their code to make sure they hadn't stolen any UNIX code.
Mark Williams is no longer with us, and presumably the same is true of Coherent.
So at least one company was "crazy enough to undertake all this in a commercial, proprietary setting"; I don't know how successful they were when they were around, nor do I know whether the fact that they're not around any more says that they really were crazy.
"Revolutionary" in what sense?
The 386 was the first 32-bit x86 processor, and the first one with support for demand paging - it had a new instruction-set architecture. Not particularly revolutionary in general, but revolutionary for x86.
The Pentium implemented the same instruction set architecture (with some minor additions); it was primarily revolutionary in its implementation, in that it was the first superscalar x86 chip to ship (again, not particularly revolutionary in general, but revolutionary for x86).
The latter means that, with Pentium, they pretty much, well, "went for the speed race".
...or getting it from HP. (I have the impression a lot, perhaps most, of the ideas in IA-64 came from HP.)
The Lame Unit In I.T. does have a new instruction set, because it'll be the first IA-64 implementation; is that the kind of "better technology" you're looking for?
"Simpler to modify and read" in what sense? If you mean it's easier to read programs written in those languages, and to modify an existing program written in those languages, how much of that is due to the language and how much of it is due to its implementation being interpretive?
(Is "interpreted" a property of a language or an implementation? I think the first LISP implementations were interpreted, but LISP compilers exist; most C implementations are compiled, but I think C interpreters exist. I could imagine Perl or VB implementations that generate compiled code - I have the impression that VB code can be compiled into machine code - and if you were to translate one of this sort of language into, say, Java byte codes, and to run them in an environment with a JIT compiler, is it interpreted or compiled?)
Some of the benefits may be due to the implementation being interpretive, e.g. an interpreter might be able to do a better job of telling you where something blew up (although symbolic debuggers can, at least sometimes, do a decent job of that, at least if the code is unoptimized), but I'm curious whether a sufficiently clever non-interpretive environment could do as good a job.
I.e., speeding up "higher-level" languages might be doable by means other than throwing faster processors at them; one can debate whether they're better doable by those means, but that's a separate question.
But, yes, it's not ipso facto the case that faster processors server only to encourage sloppy code; some might debate whether software and what it can do has progressed in any truly useful fashion since the days of the Manchester Mark 1, but....
As far as I know, the POSIX standards for network APIs (e.g., P1003.1g) are still drafts, so, arguably, NO networking code is "POSIX compliant"; has the standard been approved yet?
They decided that ages ago; it's BSD-like, but has some of its own stuff (e.g., I think it lets you start a host name lookup without waiting for it to finish, and to wait for it to finish later, and, I suspect, to wait either for it to finish or some other event to come in, so you can handle other events while you're waiting).
If it works on POSIX-compliant systems, it's not an "API for Linux", it's an API for POSIX-compliant systems - or, rather, for systems that provide a networking API that looks like the POSIX/POSIX draft one, which would include but not be limited to UNIX.
Or, perhaps, it's for systems with a UNIX-style network API, rather than the (still apparently in draft form, as per the above) POSIX network API.
Of course, MainWin already has support for Winsock, according to this page on the Mainsoft site, so it's not as if that's not already available. And it supports more than just the sockets API; I rather suspect you'd need to support a heck of a lot more of the Win32 API than just the Winsock calls to port the server applications you mentioned, so I rather doubt that there's some project to deal only with Winsock.
No, the major difference between MainWin and Cygwin is that they go in opposite directions; MainWin provides a Win32 API atop UNIX-compatible OSes, while Cygwin provides a UNIX API atop Win32 OSes. If you want to contrast Cygwin to a non-open-source UNIX-apps-atop-Windows product, contrast it with Interix, and if you want to contrast MainWin with open-source Windows-apps-atop-UNIX software, contrast it with Wine or TWIN or Twine, say.
Reverse WINE? Isn't that what Wine does - translates Win32 (and Win16, and DOS) calls to Windows calls, so you can run Windows apps on UNIX-compatible x86 OSes, and compile source for those apps to make UNIX apps?
Maybe Exchange, and maybe Outlook - it depends on whether they'd want to force folks with UNIX-compatible OSes on their desk to switch to Windows so they can read mail from an Exchange server, or whether they want to let UNIX systems read from an Exchange server on NT (rather than, say, some UNIX-based mail server).
A contradiction between "thin and efficient" and "several million lines of Windows source code"? Perhaps the "thin and efficient" layer implements very low-level Win32 operations, and the "several million lines of Windows source code" make those Win32 calls (and undocumented Windows calls implemented by MainWin, if any), so that most of the environment consists of said Windows source.
No.
Yes. For details on those last two answers, see Mainsoft's "MainWin and the X architecture" white paper.
Think of it as containing its own toolkit, whose API looks suspiciously like the window-system part of Win32....
(No, I have no idea what rule they used to insert registered-trademark symbols into that white paper; of whom is "Window Manager" a trademark? :-))
Apps?
"They", in the sense of "Mainsoft", sell Visual SourceSafe for UNIX, which is Microsoft's source code control system rehosted to UNIX using Mainsoft's MainWin product - MainWin isn't an app, it's libraries and the like to let you build Win32 apps to run on the UNIX-compatible OSes on which MainWin is offered.
Internet Explorer was ported to various UNIX-compatible OSes using it, as were a variety of apps - none of them looking like they'd be the Top Ten Shrink-Wrapped Windows Applications at your local computer store (they're more specialized) - as seen by checking out Mainsoft's press releases. Those applications don't all come from Mainsoft and don't all come from Microsoft; they come from a variety of vendors.
Mainsoft, or Softway? Microsoft did buy Softway, whose Interix product is sort of an inverse MainWin (it's a subsystem+libraries for NT that lets you recompile source code written for applications for UNIX-compatible OSes and run them on NT), but I have seen no announcement that they bought Mainsoft.
Microsoft probably views Interix as a way to get a site to move to NT if they have a pile of (in-house) UNIX apps, as the press release on their purchase suggests:
and they probably view WISE (Windows Interface Source Environment) products such as MainWin as a way of encouraging people to write Win32 applications rather than UNIX (or MacOS) applications.
Microsoft may or may not be spending money on this; MainWin is a product of Mainsoft, not Microsoft, so all Microsoft may have done is said "we won't yank your license for the Windows source in MainWin if you do a Linux port", they haven't necesarily contributed money or other resources to this.
(It is interesting to note that they don't already have an x86 UNIX in the list of platforms on which MainWin is available, so, if they port it, Linux may be the first UNIX-that-runs-on-a-PC on which MainWin is available.)
Probably. I don't have IE-for-Solaris (the port of which was done with MainWin) handy, but I don't remember it being dynamically linked with any toolkit libraries (although I also don't remember whether it was dynamically linked with Xlib, so that doesn't by itself prove anything). The UI of IE-for-Solaris is somewhat Motifish, but looks different enough that it's unlikely to be Motif. I suspect it's neither GTK+ nor Qt, either - I seem to remember the bevels on the scrollbars being narrower than those of Motif, GTK+, or Qt.
They're extremely unlikely, I suspect, to use KDE or GNOME - not all Linux systems necessarily have those, and they don't require either of them for IE/Solaris, so MainWin doesn't require them.
Well, applications often sit atop more than just the kernel - either they're dynamically linked (and thus sit atop the system shared libraries), or they're statically linked (and may have wired into their binaries assumptions about, say, the locations of files used by the library routines).
Fortunately, it appears that most distributions on which you'd run shrink-wrapped applications (as opposed to, say, a "slap this on a PC with multiple network interfaces and you have a router/firewall" distribution) may be converging on glibc 2.x (although, if the shrink-wrapped application is called "Netscape Communicator 5.0", or whatever the next release is, it may require glibc 2.1 or later, as per Mozilla's requirements); I don't know if any other libraries those applications might use differ widely between distributions.
I note, though, that "Linux core (the True Linux or kernel) will always be the same among the distros." isn't necessarily entirely the case - they aren't all using the same kernel version (Debian's still on 2.0[.x] - no, Potato isn't "done" yet - but I think the other "major" distributions have gone to 2.2[.x]), and they might make local changes (which, of course, other distributions could adopt - blah blah blah GPL blah blah blah - but that doesn't mean they will).
In some cases, local changes are just "enhancements", in which case an application vendor might choose Just To Say No and not use features added by a distribution. Of course, the trick there is how to discover what's distribution-unique; an LSB "reference implementation" might be useful there - if it doesn't run on the reference implementation, it might not run on all LSB-compliant distributions.
(Love your login name, BTW....)
I'm curious what "support" means in this context. (NOTE: in the following, I'm using "Red Hat" because it's the one people seem to most fear becoming the Only Linux For Which People Release Software.)
Does it mean "we're releasing a version that can be installed on, and run on, a Red Hat system, but that depends on stuff (installer, libraries, file system layouts, etc.) on a Red Hat system, so it won't work, or won't work quite right, on a different distribution"?
Or does it mean "well, we're not trying to make it Red Hat-only, but we're only going to test it on Red Hat, and are only going to offer support for customers running Red Hat - if you call us up because it doesn't work on OpenLinux or TurboLinux or SuSE or Debian or..., we'll tell you how sorry we are to hear that, and then we'll suggest you install Red Hat if you want to run our software"?
(It may well be that different vendors mean different things by "support".)
To some extent, the first of those could perhaps be worked around by adding stuff to your non-Red Hat system (unless the changes needed to get the software to run are incompatible changes - but I don't know how many users, other than technoids, will want to do that). Perhaps that'll provide an incentive for vendors to make their distributions more Red Hat-like, for better or worse.
The second of those may be less of a problem, in that software that's not "supported", in that sense, on other distributions may Just Work on those distributions - but there may be customers for whom "it works, but we won't answer your phone calls" may not be good enough.
...and those vendors might, in turn, apply pressure on developers of Linux distributions to try to make it easier for software to work on multiple distributions - and for software vendors to test software without having to do a ton of testing on N different distributions. (The LSB appears to be intended to have a sample implementation; however, the LSB Organization page says:
so it won't necessarily be usable as a distribution on which vendors can do testing of their applications.)
(Hmm. I'm curious how vendors of Windows applications handle Windows OT, e.g W95 and W98, and Windows NT? I wouldn't be at all surprised to hear that they have to test applications on both platforms if they're going to support them on both platforms - and to test them on different versions of those platforms, e.g. W95 and W98, or NT 4.0 and NT 4.n^H^H^H4.0 SPn. Heck, the Windows OT and Windows NT implementations of the Win32 API probably differ a lot more, in their kernel and API libraries, than would the kernel and API-library implementations of two 2.2-kernel/glibc-2.1 Linux distributions.)
You can get wide-format monitors with the SGI name on them from a variety of places; Number Nine sells (at least in the US; their online store only sells in the US) the Digital Flat Panel Solution Pack for PC's (and I think they had a package for Macs as well), which includes a Revolution IV-FP video card and the SGI monitor. It's probably available from various distributors as well. It comes with drivers for operating systems from Redmond; Accelerated-X also includes drivers, as does, I think, the latest XFree86. (I see nothing in the graphics card section of the BeOS Ready List for Intel about it, and I wouldn't be surprised to hear that there's no OS/2 drivers for it, either, alas, as, when I get a second disk for my home machine, I'd be tempted to install those on it as well, just to see what they're like....)
The ones you installed are presumably CRTs; this one is an LCD, and thus presumably not so heavy (or bulky)...
...and give you 1600x1024 as well.
The price on Number Nine's online store is about USD 2800, but I got mine for about USD 2200, at least several months ago - I seem to remember the list price being less than USD 2800 when I bought it, so maybe it's gone up; I don't know what the price would be outside the US.
"Checksum"? Isn't that the sort of thing those guys with those big room-sized Automatic Data Processing Machines would use? :-)
According to this TV Systems: A Comparison page, one PAL advantage is:
That stuff was done before anything we'd think of as a "checksum" in the digital sense would fit inside a TV, as far as I know - it's all analog....
Here's the WorldWide TV Standards - A Web Guide main page, with information on TV broadcast standards; unfortunately, I didn't see anything there that said what the memoire is avec which the French SECAM system comes; how exactly does it differ from PAL?
And the US has a higher GNP and higher population than most if not all other "first world" nations; do we contribute more financial aid as a percentage of GNP than any other developed country in the world - or are we, as I've seen claimed, closer to the bottom of that list?
In the real world, not everybody on the planet who might use an X server is an X server wizard in a position to "contribute effort to the open source component".
I don't seem to remember seeing those problems on my Debian partition at home, but I didn't install XiG's libraries - I bought it for the server, not for the client code (at the time, XFree86 didn't, as far as I know, contain support for the Number Nine Revolution IV-FP card; amusingly enough, I have XiG to thank for discovering that XFree86 later added support, as they had something on their Web site, as I remember, comparing Accelerated-X and XFree86 performance with that card), so I'm just using the XFree86 client code that came with Debian.
Debian doesn't start up xdm on my home machine because it doesn't think XFree86 has been set up, but that's about the only place I've seen where Debian was unhappy about Accelerated-X.
Well, some other companies may well advertise their product[s] in a clueless fashion, so "like every other company does" doesn't necessarily mean "in a fashion that shouldn't be roasted".
Methinks "our product is better, because it's not a piece of free software, it's Commercial-Quality Software" may not be the best approach if you're trying to sell to a community of people running an operating system made out of, err, umm, free software....
I.e., it's not clear that
is in and of itself a sufficient reason to believe that "free software does a good job" applies to an OS kernel and OS libraries (Linux and glibc, say) but not to an X server.
So are you saying that they know how to make good servers for something that's still shit?
Or are you saying "X" when you mean "XFree86"?
At least some posters in this thread, when they say "X is shit", are referring to the X Window System, rather than to a particular set of server implementations for it; are you saying
(I'm not taking a position on whether X sucks or not; I'm just asking whether you think using XiG's servers is sufficient to make it not suck, or whether the real answer might be "use something other than X", e.g. Berlin?
The Accelerated-X server's involvement in cut-and-paste is that it accepts requests from X clients to set and get various properties on windows, and the like; the problem you're having is probably a problem with what either Emacs or Netscape is doing, not with what the X server is doing.
Maybe those applications are dynamically-linked with toolkit libraries that are doing the X requests to do the cut-and-paste operations, and maybe, if you also use XiG's versions of the client libraries, it'll work better (or if you relink a statically-linked Emacs with those libraries), but I wouldn't count on it.
I just tried it with GNU Emacs 19.34.3 and Netscape Communicator 4.02 on Solaris 2.5.1 (displaying on Exceed on an NT box); paste-current-selection (i.e., select something in the GNU Emacs window, and hit the middle mouse button in the Netscape window) worked, but true copy-and-paste (select something in the GNU Emacs window, use the "Edit/Copy" menu item in Emacs, go to the Netscape window, select the "Location" box, and try to use "Edit/Paste") didn't - the "Edit" menu had "Paste" grayed out. (I did copy-and-paste rather than cut-and-paste because I ran Emacs on a file to which I didn't have write access; both of them should use the CLIPBOARD X selection in order to Play Well With Others.)
Yes, at least up to a point; if it works too poorly, what's the point?
No. A Java applet is just a small locally-run application that happens to be written in Java rather than in some other language (or, perhaps, "that happens to be distributed in the form of Java bytecode" - something distributed in Java bytecode form wasn't necessarily written in Java, as there exist compilers that translate other languages into Java bytecodes, e.g. the JPython compiler) and that happens to use whatever toolkit the environment in which it's running provides. Interesting, potentially cross-platform (if you don't manage to use some platform-specific classes, say), but not the same as the examples many people were giving, e.g. Slashdot or Web mail and calendar systems, wherein "the web is the interface" - if your browser happens to pop up some Java applet that handles input events, I/O, etc. itself and provides its own UI with its own code, the Web isn't the interface, it's just the pipe over which the code for that application was delivered, and perhaps the pipe over which it talks to some server, but if that's sufficient to make the Web the interface, a boring old "widget-centric/shrink-wrap" application downloaded via HTTP "makes the Web the interface" as long as it includes HTTP client code that it uses for some operations.
(Besides, I rather doubt you can make a "Java applet-based" version of the GIMP, or of the other applications/suites I mentioined, for one simple reason - by the time you're done, it'll probably be too big to be called an "applet". "Applet" isn't short for "application written in Java" or "application delivered as Java bytecodes"; the "let" part is a diminutive, indicating that it has to be a small application before it gets to be called an "applet".)
Because, according to this press release, StarPortal isn't the sort of "Web-based application" the original poster was citing as a reason why we should all "forget about toolkits". It says
which appear to be saying it's an application written in Java (see earlier comments in which I note that a Java-based application is just an application written for Java plus some widget set, just as a GNOME application is written in C or C++ or whatever plus GTK+ and a KDE application is written in C++ or whatever plus Qt), not a "web-based application" where you just fill in forms and hit "Submit", as the Web calendar and mail applications some people mentioned are.
Yeah, maybe it's more cross-platform than, say, a UNIX+KDE or UNIX+GNOME application is, but it's not the same sort of application as is, say, Slashdot, that being an example that one of the people to whom I replied gave.
Again, that's not a "Web-based application" any more than an MP3 player that can read files somehow magically becomes "NFS-based" or "CIFS-based" by reading from a file system on a server; the application is a local application, written using some toolkit - toolkits being what the person to whom I originally replied (and who cited Slashdot as an example of "Writing for the Web") said we should "forget".
No - but if it's playing something itself, it's not as if somebody "wrote for the Web" - they didn't write any application at all to play MP3s, they just used an application that already existed, namely Netscape or a plug-in. If you already have a canned application to perform some function, the mere fact that the canned application happens to be part of a Web browser doesn't mean that, by using that application, you've "written for the Web", it means you haven't had to write it in the first place - that certainly means you don't have to worry about toolkits, but it doesn't help you if that's something Netscape or whatever doesn't do.
Oh, you mean this one, which I read several days ago, where he says
and
where he pretty clearly indicates that he does not think that all traditional applications are dead and that CGI scripts will replace them, he indicates that there's a whole pile of new applications for doing new things that are best done with browsers talking to Web servers.
The problem that some people have is that, as, if I remember correctly, Abraham Maslow said, "to somebody whose only tool is a hammer, the whole world looks like a nail". Web-based applications, in the "3270 for the '90s" sense (as somebody described Web stuff several years ago), are cool - but they're not the whole world.
Try reading the original poster's article, which said
(without, it appears, bothering to ask what application the submitter of the question was trying to write).
Writing a custom GUI application to do Internet shopping, or calendar management, or library card catalog searching, might be a dumb thing to do now that we have HTTP servers and clients all over the place (although I'm not about to boldly declare that it is foolish; there may well be reasons why some particular such application makes more sense than a CGI script as a solution for some particular problem); nobody's made a convincing case that writing GUI applications in general is no longer necessary now that we have the Web.
Umm, that's not true of all of them. To quote the "Who We Are" page on the mozilla.org Web site:
(emphasis mine). Has the situation changed since that was written, such that the folks on Mozilla with e-mail addresses ending with "@netscape.com" aren't being paid by Netscape^H^H^H^H^H^H^H^HAOL to work on Mozilla?
That page also says that
which, if still true, may mean that there's at least some extent to which a development project by a commercial entity depends on Mozilla, and might put some pressure on Mozilla to have schedules, etc..
However
is, to some extent, presumably true, as AOL will probably be giving Netscape {Navigator,Communicator} 5.0 away, just as they're giving 4.x away. However, that's also true of Internet Explorer, if you treat it as a separate program rather than a pile of OS/GUI COM objects to provide HTML display and Internet access, plus a browser wrapper around those objects (if you treat it as the latter - which is true only in Windows - then you could view its developers as part of the Windows OT and Windows NT development teams, I guess).
"Native" and "emulated" in what sense? Merced (and, I suspect, McKinley) will be able to directly run x86 code; in what sense is that "emulated" rather than "native"? (The latest Microprocessor Report has a story on Intel's presentation on Merced at the latest Microprocessor Forum; it says
As for PA-RISC code, HP's IA-64 documentation online (see my other comment in this thread for a reference) says that the chip won't execute PA-RISC code; software will translate PA-RISC code to IA-64 code, and the IA-64 code is what will be executed. In what sense is that "native" rather than "emulated"?
But if it's easier to make, say, a 21264 run at a given clock rate than it is to make a PA-8500 run at that clock rate, "Alpha wins in the end" regardless - SPEC/MHz isn't necessarily a figure of merit in and of itself.