But wouldn't it be better to go help Bernlin Consortium instead of try to put lipstick on a pig?
Well, first of all, I don't know whether there's a universal consensus that the X Rendering Extension constitutes "[putting] lipstick on a pig"; the fact that a person, or even that many people, happen to believe so doesn't ipso facto make it so.
Second of all, "help[ing] the Berlin Consortium" doesn't help all the zillions of X-based applications and toolkits and... that are our there now; to quote the Berlin Vs. X. FAQ:
Note that Berlin is still in development. As of this writing Berlin is only useful for demos (really cool demos though:) while the X Window System is in full production use by many users.
Even if, when completed, Berlin is superior even to X with the Rendering Extension (which might well be the case), if the X Rendering Extension comes out significantly earlier than a version of Berlin sufficient to replace X, dumping the X Rendering Extension work and going off to work on Berlin may be a case of "the best is the enemy of the good".
Maybe Berlin would come out sooner if everybody quit working on X - but
you might still get better rendering sooner by doing the X Rendering Extension, and this might still make people, on the whole, better off;
if herding programmers is like herding cats, herding free-software programs is, I suspect, like herding feral cats, so there's no guarantee that by exhorting people to stop working on project A and, instead, work on its competitor B one will actually achieve this goal (note that, for "A" and "B" one can substitute "KDE", "GNOME", "Linux", "*BSD", etc., etc.).
I think that both the X Rendering Extension and Berlin are interesting projects; I'm unconvinced that it'd be a Good Thing if either were abandoned, as, if nothing else, they mean that people are thinking about More Than One Way Of Doing Things, which could lead to a group working on project A picking up Good Ideas from the group working on project B.
No. In NT 3.5.x, just as in 4.0 and, as far as I know, 5.0^H^H^HW2K, drivers for devices such as disk and network controllers, and network protocol implementations run in kernel mode in a fashion similar to the way they function in various UNIX systems.
even the GUI ran in userspace (and netorking would contintue even if the gui crashed)
Yes, rendering was done in 3.x by sending messages to the Win32 subsystem process...
...but if that's sufficient to make NT a microkernel, then, well, err, umm, Linux - or {Free,Net,Open}BSD, or Solaris, or HP-UX, or AIX, or Digital UNIX, or... - are also microkernels if they're running X; in systems running X, the rendering code runs in "a process within its own memory space", i.e. the X server, in user mode.
BTW, "the GUI" runs, in part, in user mode even on NT 4 - the low-level rendering is done in kernel drivers, but the toolkit - the equivalent of Motif or GTK+ or Qt or... - lives, as far as I know, in user32.dll, which is a library that calls routines in gdi32.dll to get stuff rendered.
user32.dll is, as far as I know, just user-mode library code, as is gdi32.dll; on 3.x, gdi32.dll sent messages to the Win32 subsystem process, and, in 4.x and later, it goes through the kernel driver in at least some cases. (The fact that it's a shared library means that binaries built for 3.x should just continue to work - the ABI for drawing stuff on the screen is, in effect, a bunch of "call routine XXX in this library, with these arguments" items, and the way routine XXX accomplishes that can change from release to release without affecting programs that don't go around the back of the library.)
(user32.dll probably roughly corresponds to your toolkit library or libraries in X, and gdi32.dll probably rougly corresponds to Xlib, although there may be differences.)
What he's saying is if you do anti-aliased text the "old way" of rendering pixmaps and pushing them out, there's no longer any "text" to be selected in the clipboard. It's just an image.
If that's what he's saying, then he's very confused.
On the X server there's no "text" to be selected on the clipboard no matter how you rendered it on the screen - there's just pixels. There is no guarantee that the text characters sent over the wire in a "draw text" request are somehow "remembered" by the X server, and, even if the X server happens to remember them, there's no X request to fetch those characters back (you can perhaps read the pixels back, but not the text).
As I said at least once, selection is done on the client, though, so whether the server was told to put pixels on the screen by a "draw text" request or was just handed the pixels by the client is irrelevant.
The client has to keep a copy of the text, which it can do regardless of whether it renders that text on the screen by sending the X server one or more "draw text" requests or by converting it to pixels internally and sending those pixels over the wire; that copy is what's selected in the clipboard (or, rather, what's supplied if somebody asks the client for the contents of the clipboard).
At the moment if you move to rendering anti-aliased text you have to add the clipboard support in as well by hand. Of course, a reasonable 'AA text library' would do this for you I suppose.
Are you asserting here that anti-aliased text would somehow be stored differently in the clipboard than non-anti-aliased text? I have yet to see any indication that it would have to be; if you're cutting from a word processor, the character sizes and fonts might be available through the clipboard when using a format that includes it (although it'd probably also be made available as Boring ASCII Text, or Boring ISO 8859/n Text, or Boring JIS Text, or Boring UTF-8 Text, or...), but I wouldn't see an indication of whether the text happened to be rendered anti-aliased or not being made available via the clipboard.
(The fact that the text might have been rendered on the screen by sending raw pixels rather than sending text is irrelevant, given that, as I said, the client handles the cutting and pasting, not the server, and the client has the characters available.)
I meant that every app will have access to these extensions
...which, of course, doesn't mean that they necessarily will use them, unless they're modified to use them, or the toolkit they use is modified to use them.
I was looking at how the QNX kernel offers only core services like threading, IPC, process creation, memory management, initial interrupt handling, etc. Everything else functions as a process within it's own memory space.
it's not - in NT, file systems, drivers for devices such as disk and network controllers, and network protocol implementations run in kernel mode in a fashion similar to the way they function in various UNIX systems.
Some of the Win32 semantics are implemented in the user-mode Win32 subsystem process, but some Win32 calls just get mapped into native NT system calls by the Win32 library.
It also means that if you're rendering anti-alised text then you can't cut+paste it!
Eh? Whether you can cut and paste stuff is independent of how it's rendered on the screen; cut and paste is largely done by the client(s), with the only server involvement typically being the use of the selections such as the primary and clipboard selection.
Putting all these primitives in the Xserver will result in *every* app being able to use these new features efficiently.
...but they'll only use it if and when either the application, or the toolkit it uses, is changed to use the rendering extension, unless they somehow bury that stuff in Xlib itself, which I have the impression they're not doing (and I have the impression might not be doable).
but what does Ethereal do that would astound network troubleshooters?
Provides a GUI packet capture and analysis program for UNIX? GUI sniffers are something Windows and Mac folk have been used to for a while, but if the network administrators had only seen tty-oriented tools such as tcpdump or snoop, Ethereal might've been a surprise.
Ethereal isn't the only GUI packet capture and analysis program for UNIX; there's also Knetdump (given the first letter, nobody gets a prize for guessing which GUI toolkit and desktop environment it uses:-)), and there's also tcpview, a Motif application based on an old version of tcpdump.
Analyzer is the way to go. Free, open sourced, and really nice UI.
If you're using Windows, at least.
You'll need winpcap to get it to work right.
You'll need WinPcap to get it to capture packets at all - but you'll need WinPcap to get Ethereal to capture packets on Win32 as well.
The Politecnico di Torino folk also have WinDump, a port of tcpdump to Win32, also using WinPcap.
Search for it on packetstorm.
Or just go to the Analyzer site (I'm assuming from the reference to WinPcap that you're talking about the Politecnico di Torino Analyzer). If the site isn't up, try again later.
Sniffer programs are also useful if you only care about the traffic between two machines, at least one of which is capable of running the sniffer program (or can otherwise produce a network trace file). Perhaps that's less common for network administrators than for software developers, but if you're a developer at a manufacturer of, well, Network Appliances, packet analyzer programs can come in very handy even if you can't see all the traffic on a network segment.
After that everything installed, but got a run error: "error in loading shared libraries: ethereal: undefined symbol: snmp_set_suffix_onl".
Ah, the joys of binary non-compatibility; UCD SNMP 4.1.1, which RH 6.2 picked up, changed a routine Ethereal uses into a macro, which meant that the Ethereal in the binary RPMs, which were built on RH 6.1, and linked with the UCD SNMP shared library, don't work on 6.2, as a routine it calls isn't present in the 6.2 UCD SNMP shared library. (UCD SNMP 4.1.2 turned that and other macros back into routines; I filed a bug with Red Hat suggesting that they pick up 4.1.2, which, as I remember, they said they'd do in 7.0.)
I threw into Ethereal 0.8.10 a greasy hack, inspired by greasy hacks I've been told are used on Windows to e.g. allow applications to use new DLL routines if present on a particular system without blowing up if they aren't, to work around that.
Whilst it worked on my simulation of that situation on my Debian 2.1 partition, it appears not to work on RH 6.2; I have some diagnostic information from one user who reported that on the ethereal-users mailing list, and will see if I can check in a change more likely to make it Just Work.
Installing ucd-snmp-utils and ucd-snmp-devel fixed the runtime error.
That's all you did? Just installing those two RPMs? That's bizarre - what files did installing those two RPMs add to your system?
Or is there an "I then recompiled from source" step after that step?
Try Analyzer for windows. free, open sourced, impressive.
Try giving a URL for it.
I'll assume that you're referring to Analyzer from the folks at the Politecnico di Torino, the folks who also bring you WinDump, a port of tcpdump to Win32 systems, and WinPcap, a port of libpcap to Win32 systems (including drivers for Windows 9x and Windows NT, including NT 5.0^H^H^H^H^H^HWindows 2000), which is the library that Ethereal on Win32, Analyzer, and WinDump all use.
(The Politecnico di Torino site appears not to be responding at the time that I'm posting this; be patient - we sometimes get folks posting to the ethereal-users mailing list asking "that site is down, how do I get WinPcap?", for which the answer is "it's probably just temporarily down, try again later".)
You can do all that with the ports by just typing 'make extract' to do everything up to extracting the sources in the work directory (then go into work/ and change whatever you want)
Why am I better off doing that than just extracting the tarball? (Note: "because it works with Berkeley make" would not be a valid answer - I've installed GNU make on my machine, which is what I get by default when building stuff, which, for me, is a feature.)
or 'make patch' to do everything up to the freebsd patches
If the original tarball needed patches to build on FreeBSD (other than patches to work with Berkeley make, which I don't care about), the changes should've been sent back to the maintainer of the package, so that future tarballs won't require that.
From there you can type 'make configure' or 'make' or 'make install', whatever.
If all I'm doing is make followed by make install, I'd go for the binary package.
This page also lets you get at some free IP, although you have to go to one of the subdirectories, download and unpack the tarball, and get it from the appropriate directory...
This page also lets you get at some free IP, although you have to go to one of the subdirectories, download and unpack the tarball, and get it from the appropriate directory (kernel/net/ipv4).
FreeBSD has gone the low road, and instead of trying to implement a package system, they provide very clever makefiles that will download the source, 'fix' it, then compile.
That's certainly a way of installing software on FreeBSD, but I usually just do pkg_add -rpackage and have it download the binary package (and packages on which it depends) and install it/them. (If I care about the source, I'll download the original tarball and do the configure/make/make install myself, as I'm likely to care about the source because I want to change something, in which case I'll probably want to send it back, and patching the vanilla source rather than port-ized source seems as if it'd be a better idea.)
What ever nice points FreeBSD has, good sound card support is NOT one of them. The best solution is to get an extra box with an OS that works with your sound card.
Fortunately, I already have two OSes on my home machine that work with my sound card...
...FreeBSD 3.x and NT 4.0.
It's a plug-and-play ISA sound card (I saw no reason to get a PCI sound card when there was a spare ISA slot), and I didn't particularly feel like banging on isapnptools or jam a PnP ISA patch into the 2.0[.x] kernel on my Debian 2.1 partition to get the sound card to work - or to shove a 2.2[.x] kernel and jam in the patch, or shove a 2.3[.x] kernel on it - given that it worked out of the box on BSD. (It also looked like More Trouble Than It Was Worth to get it to work on the machine's fourth OS, Solaris 7.)
I.e., when it comes to hardware support, the important phrase here is "your mileage may vary"; categorical statements about FreeBSD and/or Linux support may, even if valid in general (as in "more sound cards are supported by the Linux 2.x.y kernel than by the FreeBSD m.n kernel", which I suspect may be the case for most reasonable values of "x", "y", "m", and "n", although I could be surprised) may not apply in all cases.
Oops - I must have thought otherwhise, but what I meant is that they're adopting a lot of the software the Linux community worked on.
...and that, I suspect, people outside "the Linux community" worked on as well.
Do tcsh and less antedate Linux? Even if they don't, were they originally done for Linux, or were they done for other UNIXes instead or as well?
If the answer to either of those questions is "yes", then saying "they're adopting a lot of the software the Linux community worked on" may be technically true, but may not necessarily be equivalent to "getting with the GNU bandwagon" or "switching to using GNU userland software" even if you reinterpret "GNU" in your original message as meaning "Linux", so, no, I do not believe that particular idea of your original post still stands.
I'm not sure that "we lose the original BSD software, which wouldn't be a good thing" applies either, if by "lose" you mean "don't have it available as part of the system" (as opposed to "the source is unavailable" - as noted, the source is still available in the CVS tree). I don't see csh as being preferable to tcsh, or more as being preferable to less, merely by virtue of being the implementation that came with older versions of BSD - the BSDs have changed a number of things, over time, from "the original BSD software" in the sense of, say, "what came with 4.4-Lite", but I don't view that as being ipso facto A Bad Thing.
There may be other reasons to prefer csh or more, but there are probably reasons why, for arbitrary piece of code XXX in release N of operating system YYY, some people might prefer alternative ZZZ, where alternative ZZZ might have been there instead of XXX in release N-k. So it goes....
Re:The other side of Echelon
on
Inside Echelon
·
· Score: 2
How cool would it be if some of technology involved would trickle down sooner rather than later. Think about all the incredibly cool -- and useful -- things we could do!
Yup - as the article says:
In one sense, the main function of Dictionary computers are to throw most intercepted information away.
Put that technology between you and Slashdot, and watch First Posts and the like disappear; pretty soon the penis bird will become an endangered species.
I think Qt themes are coded, not pixmapped, which means that GTK+ can't just run them, just as Qt can't just run GTK+ coded themes.
Theme writers sufficiently ambitious to take on two toolkits might want to create packages consisting of both GTK+ and Qt themes that provide the same appearance etc..
But why both kde and gnome? If these teams joined forces, imagine how fast the Linux/UNIX desktop world would evolve.
...in one direction, which is not necessarily completely a Good Thing.
If there's only one {UNIX-flavored OS, compiler, desktop, Web browser, etc.}, you run the risk of having things done only the way the group in charge of that particular project decides things should be done (or you get a fork, but then there isn't only one any more).
something to do with grading the possible transmission of information in such subtle ways as someone replying to an email or not replying to an email (ie: regardless of the content of the message, this accounts for one bit of unpredictable information)
Western Digital has an external disk drive with an IEEE 1394 interface. I don't know whether it's an IDE drive with an IDE1394 bridge inside, or a drive whose native interface is 1394.
The cost of improving wine to where it would fully operate with most/all of the MS Apps, might well be fairly insignificant (with proper knowledge of the Apps and MS OS internals, something that the Apps division will have plenty of.)
Or it might not.
Thus they suddenly gain massive market opportunity
Is the UNIX market for Office sufficiently large for it to be worth MicroApp's while to port it? (Note that this may mean "sufficiently large relative to the Windows market", which is pretty large.)
antialiased font?? I thought it was internal xlib problem and not solvable baring serious X modifications ( of course one can always resort to drawing and antialiasing letters on his own but that sucks)
I think there might be some component of GNOME (not GTK+) that does exactly that (rendering stuff on its own); I have the impression that FrameMaker for UNIX might do so as well.
However, Keith Packard's paper on a new rendering model for X speaks of anti-aliasing for text (see section 4.5, "Text", at the bottom of that section) as one feature to be added. I presume this - and other work described therein - would be done by adding protocol extensions (and requiring toolkits to fall back on doing the rendering themselves, or disabling the features in question, if the extensions aren't present; see section 3, "Reasons for a New Model").
SunOS 5.x and Solaris 2.x (up to 2.6) were
exactly the same thing.
Actually, I think Sun presented it as "SunOS 5.x is the OS portion of Solaris 2.x", with "Solaris" containing, in addition to SunOS, the window system and desktop code - but the key point, as you note, is that there's still SunOS in there, even if the code base for SunOS changed.
I haven't used it but I have a feeling uname would report it as SunOS 5.7
You are correct - that's exactly what uname -sr reports on Solaris 7.
(uname -sr gets you the OS name and release number, without all the other stuff you get from uname -a; it's what I use if I just care what version of what OS a box is running, although, for those OSes constructed by assembling a large number of independent pieces, it tends to give only the version number of the kernel - uname -sr on a Linux box won't tell you it's running Red Hat 6.2 or Debian 2.1 or SuSE 6.3 or Mandrake 7.0 or..., it'll tell you it's running Linux 2.0.36 or Linux 2.2.14 or.... There are times where that's a feature, but there are times where it's not, given that the behavior of a system, both from the user and programmer point of view, is controlled by more than just what's in the kernel.
Of course, the next question one might sometimes ask of a system is "which patches does it have installed", and uname -sr doesn't necessarily answer that; Solaris has, I think, a way of finding that out, but I don't know which other OSes do.)
Slashdot Mirror
Well, first of all, I don't know whether there's a universal consensus that the X Rendering Extension constitutes "[putting] lipstick on a pig"; the fact that a person, or even that many people, happen to believe so doesn't ipso facto make it so.
Second of all, "help[ing] the Berlin Consortium" doesn't help all the zillions of X-based applications and toolkits and... that are our there now; to quote the Berlin Vs. X. FAQ:
Even if, when completed, Berlin is superior even to X with the Rendering Extension (which might well be the case), if the X Rendering Extension comes out significantly earlier than a version of Berlin sufficient to replace X, dumping the X Rendering Extension work and going off to work on Berlin may be a case of "the best is the enemy of the good".
Maybe Berlin would come out sooner if everybody quit working on X - but
I think that both the X Rendering Extension and Berlin are interesting projects; I'm unconvinced that it'd be a Good Thing if either were abandoned, as, if nothing else, they mean that people are thinking about More Than One Way Of Doing Things, which could lead to a group working on project A picking up Good Ideas from the group working on project B.
No. In NT 3.5.x, just as in 4.0 and, as far as I know, 5.0^H^H^HW2K, drivers for devices such as disk and network controllers, and network protocol implementations run in kernel mode in a fashion similar to the way they function in various UNIX systems.
Yes, rendering was done in 3.x by sending messages to the Win32 subsystem process...
...but if that's sufficient to make NT a microkernel, then, well, err, umm, Linux - or {Free,Net,Open}BSD, or Solaris, or HP-UX, or AIX, or Digital UNIX, or... - are also microkernels if they're running X; in systems running X, the rendering code runs in "a process within its own memory space", i.e. the X server, in user mode.
BTW, "the GUI" runs, in part, in user mode even on NT 4 - the low-level rendering is done in kernel drivers, but the toolkit - the equivalent of Motif or GTK+ or Qt or... - lives, as far as I know, in user32.dll, which is a library that calls routines in gdi32.dll to get stuff rendered.
user32.dll is, as far as I know, just user-mode library code, as is gdi32.dll; on 3.x, gdi32.dll sent messages to the Win32 subsystem process, and, in 4.x and later, it goes through the kernel driver in at least some cases. (The fact that it's a shared library means that binaries built for 3.x should just continue to work - the ABI for drawing stuff on the screen is, in effect, a bunch of "call routine XXX in this library, with these arguments" items, and the way routine XXX accomplishes that can change from release to release without affecting programs that don't go around the back of the library.)
(user32.dll probably roughly corresponds to your toolkit library or libraries in X, and gdi32.dll probably rougly corresponds to Xlib, although there may be differences.)
If that's what he's saying, then he's very confused.
On the X server there's no "text" to be selected on the clipboard no matter how you rendered it on the screen - there's just pixels. There is no guarantee that the text characters sent over the wire in a "draw text" request are somehow "remembered" by the X server, and, even if the X server happens to remember them, there's no X request to fetch those characters back (you can perhaps read the pixels back, but not the text).
As I said at least once, selection is done on the client, though, so whether the server was told to put pixels on the screen by a "draw text" request or was just handed the pixels by the client is irrelevant.
The client has to keep a copy of the text, which it can do regardless of whether it renders that text on the screen by sending the X server one or more "draw text" requests or by converting it to pixels internally and sending those pixels over the wire; that copy is what's selected in the clipboard (or, rather, what's supplied if somebody asks the client for the contents of the clipboard).
Are you asserting here that anti-aliased text would somehow be stored differently in the clipboard than non-anti-aliased text? I have yet to see any indication that it would have to be; if you're cutting from a word processor, the character sizes and fonts might be available through the clipboard when using a format that includes it (although it'd probably also be made available as Boring ASCII Text, or Boring ISO 8859/n Text, or Boring JIS Text, or Boring UTF-8 Text, or...), but I wouldn't see an indication of whether the text happened to be rendered anti-aliased or not being made available via the clipboard.
(The fact that the text might have been rendered on the screen by sending raw pixels rather than sending text is irrelevant, given that, as I said, the client handles the cutting and pasting, not the server, and the client has the characters available.)
...which, of course, doesn't mean that they necessarily will use them, unless they're modified to use them, or the toolkit they use is modified to use them.
Not in the sense of (from the original article)
it's not - in NT, file systems, drivers for devices such as disk and network controllers, and network protocol implementations run in kernel mode in a fashion similar to the way they function in various UNIX systems.
Some of the Win32 semantics are implemented in the user-mode Win32 subsystem process, but some Win32 calls just get mapped into native NT system calls by the Win32 library.
Eh? Whether you can cut and paste stuff is independent of how it's rendered on the screen; cut and paste is largely done by the client(s), with the only server involvement typically being the use of the selections such as the primary and clipboard selection.
...but they'll only use it if and when either the application, or the toolkit it uses, is changed to use the rendering extension, unless they somehow bury that stuff in Xlib itself, which I have the impression they're not doing (and I have the impression might not be doable).
Provides a GUI packet capture and analysis program for UNIX? GUI sniffers are something Windows and Mac folk have been used to for a while, but if the network administrators had only seen tty-oriented tools such as tcpdump or snoop, Ethereal might've been a surprise.
Ethereal isn't the only GUI packet capture and analysis program for UNIX; there's also Knetdump (given the first letter, nobody gets a prize for guessing which GUI toolkit and desktop environment it uses :-)), and there's also tcpview, a Motif application based on an old version of tcpdump.
If you're using Windows, at least.
You'll need WinPcap to get it to capture packets at all - but you'll need WinPcap to get Ethereal to capture packets on Win32 as well.
The Politecnico di Torino folk also have WinDump, a port of tcpdump to Win32, also using WinPcap.
Or just go to the Analyzer site (I'm assuming from the reference to WinPcap that you're talking about the Politecnico di Torino Analyzer). If the site isn't up, try again later.
Sniffer programs are also useful if you only care about the traffic between two machines, at least one of which is capable of running the sniffer program (or can otherwise produce a network trace file). Perhaps that's less common for network administrators than for software developers, but if you're a developer at a manufacturer of, well, Network Appliances, packet analyzer programs can come in very handy even if you can't see all the traffic on a network segment.
Ah, the joys of binary non-compatibility; UCD SNMP 4.1.1, which RH 6.2 picked up, changed a routine Ethereal uses into a macro, which meant that the Ethereal in the binary RPMs, which were built on RH 6.1, and linked with the UCD SNMP shared library, don't work on 6.2, as a routine it calls isn't present in the 6.2 UCD SNMP shared library. (UCD SNMP 4.1.2 turned that and other macros back into routines; I filed a bug with Red Hat suggesting that they pick up 4.1.2, which, as I remember, they said they'd do in 7.0.)
I threw into Ethereal 0.8.10 a greasy hack, inspired by greasy hacks I've been told are used on Windows to e.g. allow applications to use new DLL routines if present on a particular system without blowing up if they aren't, to work around that.
Whilst it worked on my simulation of that situation on my Debian 2.1 partition, it appears not to work on RH 6.2; I have some diagnostic information from one user who reported that on the ethereal-users mailing list, and will see if I can check in a change more likely to make it Just Work.
That's all you did? Just installing those two RPMs? That's bizarre - what files did installing those two RPMs add to your system?
Or is there an "I then recompiled from source" step after that step?
Try giving a URL for it.
I'll assume that you're referring to Analyzer from the folks at the Politecnico di Torino, the folks who also bring you WinDump, a port of tcpdump to Win32 systems, and WinPcap, a port of libpcap to Win32 systems (including drivers for Windows 9x and Windows NT, including NT 5.0^H^H^H^H^H^HWindows 2000), which is the library that Ethereal on Win32, Analyzer, and WinDump all use.
(The Politecnico di Torino site appears not to be responding at the time that I'm posting this; be patient - we sometimes get folks posting to the ethereal-users mailing list asking "that site is down, how do I get WinPcap?", for which the answer is "it's probably just temporarily down, try again later".)
Why am I better off doing that than just extracting the tarball? (Note: "because it works with Berkeley make" would not be a valid answer - I've installed GNU make on my machine, which is what I get by default when building stuff, which, for me, is a feature.)
If the original tarball needed patches to build on FreeBSD (other than patches to work with Berkeley make, which I don't care about), the changes should've been sent back to the maintainer of the package, so that future tarballs won't require that.
If all I'm doing is make followed by make install, I'd go for the binary package.
Here's that particular free IP in an easier-to-view form.
Cool. Here's some free IP, and here's some more free IP, and here's some more free IP.
This page also lets you get at some free IP, although you have to go to one of the subdirectories, download and unpack the tarball, and get it from the appropriate directory (kernel/net/ipv4).
That's certainly a way of installing software on FreeBSD, but I usually just do pkg_add -r package and have it download the binary package (and packages on which it depends) and install it/them. (If I care about the source, I'll download the original tarball and do the configure/make/make install myself, as I'm likely to care about the source because I want to change something, in which case I'll probably want to send it back, and patching the vanilla source rather than port-ized source seems as if it'd be a better idea.)
Fortunately, I already have two OSes on my home machine that work with my sound card...
...FreeBSD 3.x and NT 4.0.
It's a plug-and-play ISA sound card (I saw no reason to get a PCI sound card when there was a spare ISA slot), and I didn't particularly feel like banging on isapnptools or jam a PnP ISA patch into the 2.0[.x] kernel on my Debian 2.1 partition to get the sound card to work - or to shove a 2.2[.x] kernel and jam in the patch, or shove a 2.3[.x] kernel on it - given that it worked out of the box on BSD. (It also looked like More Trouble Than It Was Worth to get it to work on the machine's fourth OS, Solaris 7.)
I.e., when it comes to hardware support, the important phrase here is "your mileage may vary"; categorical statements about FreeBSD and/or Linux support may, even if valid in general (as in "more sound cards are supported by the Linux 2.x.y kernel than by the FreeBSD m.n kernel", which I suspect may be the case for most reasonable values of "x", "y", "m", and "n", although I could be surprised) may not apply in all cases.
...and that, I suspect, people outside "the Linux community" worked on as well.
Do tcsh and less antedate Linux? Even if they don't, were they originally done for Linux, or were they done for other UNIXes instead or as well?
If the answer to either of those questions is "yes", then saying "they're adopting a lot of the software the Linux community worked on" may be technically true, but may not necessarily be equivalent to "getting with the GNU bandwagon" or "switching to using GNU userland software" even if you reinterpret "GNU" in your original message as meaning "Linux", so, no, I do not believe that particular idea of your original post still stands.
I'm not sure that "we lose the original BSD software, which wouldn't be a good thing" applies either, if by "lose" you mean "don't have it available as part of the system" (as opposed to "the source is unavailable" - as noted, the source is still available in the CVS tree). I don't see csh as being preferable to tcsh, or more as being preferable to less, merely by virtue of being the implementation that came with older versions of BSD - the BSDs have changed a number of things, over time, from "the original BSD software" in the sense of, say, "what came with 4.4-Lite", but I don't view that as being ipso facto A Bad Thing.
There may be other reasons to prefer csh or more, but there are probably reasons why, for arbitrary piece of code XXX in release N of operating system YYY, some people might prefer alternative ZZZ, where alternative ZZZ might have been there instead of XXX in release N-k. So it goes....
Yup - as the article says:
Put that technology between you and Slashdot, and watch First Posts and the like disappear; pretty soon the penis bird will become an endangered species.
I think Qt themes are coded, not pixmapped, which means that GTK+ can't just run them, just as Qt can't just run GTK+ coded themes.
Theme writers sufficiently ambitious to take on two toolkits might want to create packages consisting of both GTK+ and Qt themes that provide the same appearance etc..
The status is "it's going to be called GTK+ 2.0"; GTK+ and GLib 1.3.1 unstable developer's preview releases have been announced.
...in one direction, which is not necessarily completely a Good Thing.
If there's only one {UNIX-flavored OS, compiler, desktop, Web browser, etc.}, you run the risk of having things done only the way the group in charge of that particular project decides things should be done (or you get a fork, but then there isn't only one any more).
Sounds like a story about "covert channels"; I don't know to which story your professor was referring, but here's one story about covert channels from the multicians.org site.
Western Digital has an external disk drive with an IEEE 1394 interface. I don't know whether it's an IDE drive with an IDE1394 bridge inside, or a drive whose native interface is 1394.
Or it might not.
Is the UNIX market for Office sufficiently large for it to be worth MicroApp's while to port it? (Note that this may mean "sufficiently large relative to the Windows market", which is pretty large.)
I think there might be some component of GNOME (not GTK+) that does exactly that (rendering stuff on its own); I have the impression that FrameMaker for UNIX might do so as well.
However, Keith Packard's paper on a new rendering model for X speaks of anti-aliasing for text (see section 4.5, "Text", at the bottom of that section) as one feature to be added. I presume this - and other work described therein - would be done by adding protocol extensions (and requiring toolkits to fall back on doing the rendering themselves, or disabling the features in question, if the extensions aren't present; see section 3, "Reasons for a New Model").
Actually, I think Sun presented it as "SunOS 5.x is the OS portion of Solaris 2.x", with "Solaris" containing, in addition to SunOS, the window system and desktop code - but the key point, as you note, is that there's still SunOS in there, even if the code base for SunOS changed.
You are correct - that's exactly what uname -sr reports on Solaris 7.
(uname -sr gets you the OS name and release number, without all the other stuff you get from uname -a; it's what I use if I just care what version of what OS a box is running, although, for those OSes constructed by assembling a large number of independent pieces, it tends to give only the version number of the kernel - uname -sr on a Linux box won't tell you it's running Red Hat 6.2 or Debian 2.1 or SuSE 6.3 or Mandrake 7.0 or..., it'll tell you it's running Linux 2.0.36 or Linux 2.2.14 or.... There are times where that's a feature, but there are times where it's not, given that the behavior of a system, both from the user and programmer point of view, is controlled by more than just what's in the kernel.
Of course, the next question one might sometimes ask of a system is "which patches does it have installed", and uname -sr doesn't necessarily answer that; Solaris has, I think, a way of finding that out, but I don't know which other OSes do.)