Also be sure to include a commercial unix with your hardware like Solaris.
Well, that'll show that damn Windows lover!
In order not to rig the competition so that a Windows box is inherently excluded merely by virtue of running Windows (given that this does appear to be a bit of an OS X vs. Windows debate, and a rigged debate is only interesting in its perversity), you might want to eliminate that requirement, or replace it with a requirement for XP Pro rather than XP Home if that makes sense in an Apples-to-Wintel^Wapples-to-apples comparison.
When reply to an e-mail it brings up the right from address.
At least in my experience, it often does, but it doesn't always do so. From some experimentation I just did, it appears to base it on the address to which the mail was sent - but if it was sent to a mailing list, so that none of my e-mail addresses appear in the To: or Cc: header, it doesn't pick the address I happen to use on that list.
If it could be given rules to say "if it's to any of these addresses, use address XXX in replies", as I infer (perhaps incorrectly) Pine can, that could be fixed.
I'm not asking for much. If the system recognizes a pattern (bunch of emails from a paricular last name; let's let the next one through the spam filter). Pattern recognition is quite simple in most programs.
Such as Mail.app in its spam filter. I don't know whether that technique can be used for other mail filters - the spam filter might have been told some information about spam to get it started, with subsequent reclassifications of purported spam as non-spam and purported non-spam as spam updating it, but I don't know whether it'd work without that sort of preloading.
However, the source to the darwin that is contained in Tiger is available now.
Surely you mean "the source to the Darwin that is contained in the Tiger WWDC preview is available now". Mac OS X 10.4 hasn't, as the original poster noted, been released yet, and source to it isn't available for the simple reason that it doesn't yet exist.
Windows and Mac OS have their roots in the UNIX goo, even though they don't show it as well as Linux.
Really? Some stuff in Windows might be inspired by stuff in UNIX, but it's not really a descendant, and, as for Mac OS, or, at least, Mac OS X:
% sw_vers ProductName: Mac OS X ProductVersion: 10.3.4 BuildVersion: 7H63 % ifconfig -a lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384 inet6::1 prefixlen 128 inet6 fe80::1 prefixlen 64 scopeid 0x1 inet 127.0.0.1 netmask 0xff000000
...
Looks more like the UNIXes I'm used to than the ifconfig output I've seen on Linux distributions.... (Ignore the lack of indentation - the lines after the "lo0" line really are indented, they just don't show up as such inside <ECODE>.)
That's an extreme example, perhaps, but the OS X boxes on which I type look pretty much like any other UN*X boxes - there are things that are different from other UN*X boxes, but if some alleged UN*X doesn't do at least one thing annoyingly different from most of the other UN*Xes out there, it's not really UN*X-compatible - doing something different is pretty much a requirement for being a "real UN*X".:-)
The OS X GUI is different from that on other UN*Xes, but then CDE is different from GNOME is different from KDE is different from..., so it's not as if OS X is entirely unique in that respect (although it's less Windowsish than many of the other UN*X desktop environments).
For example, Windows is designed with a certain file system in mind.
In what sense? Windows NT (including NT 5.x, i.e. W2K, WXP, and W2K3 Server) has a pluggable file system interface, and I think Windows OT (95/98/Me) did as well, just as Linux has one (its VFS), and most other UNIX-flavored OSes now do (going back to SunOS 2.0 and its VFS).
Perhaps some applications expect support for multiple streams in files, but even those applications should work either with NTFS or with the SMB client file system when it's talking to a server that supports multiple streams in files (and those applications won't work on Windows OT, so there probably aren't a lot of applications that require multiple streams in files, as opposed to ones that'll use them if available and fall back on some other mechanism if not).
Also, while there may be Windows for other processors, it is overwhelmingly designed for one architecture.
The Intel i860?:-) NT, at least, was allegedly originally developed for the i860 (in the sense that the machines on which it was run during development were i860-based machines), but with at least some amount of portability in mind as it'd also have to run on x86 as well (and perhaps because the i860 was replaced by MIPS processors, and later ports were done to PowerPC and Alpha; it's also recently been ported to IA-64 and AMD64).
Windows OT was x86-only; are you thinking of Windows OT here?
it is still true that Linux has a great deal more abstraction between the kernel, the shell and the applications
What are some examples of how Windows has less abstraction between the kernel and the shell? ("Shell" either as "command interpreter" or "desktop environment".)
There's no sorting done when the file is opened; do you mean that if the packets are out of order by time stamp in the capture file (which would be the result of a bug in the underlying capture mechanism - it should be delivering packets in time-stamp order; when do you see out-of-order packets?), Ethereal should re-order them?
If Ethereal were to do that, note that Tethereal wouldn't be able to reorder them, as it is, by design and intent, a one-pass program.
tpcdump[sic] has very powerful filtering - you just have to learn to use it.
And Ethereal has, of course, the exact same filtering for captures (because they both use libpcap for capturing and filtering of captures). Ethereal's display filtering can do the same sort of things, albeit with different syntax (tcpdump's syntax doesn't fit the "filter on arbitrary field" model Ethereal has; it might be nice to have Ethereal translate a smaller display-filter-like language into capture filters - the full display filter syntax isn't implementable with BPF-style capture filters - and that might happen at some point).
"Sort logs by date" in what sense? Presumably something other than sorting by clicking on the title of the "Time" column if it's configured to display absolute time or absolute date and time.
I can't open more than one trace per session.
Non-trivial to implement - doable, but we'd need to make a lot of state information per-trace (i.e., attach it to a capture file structure) rather than global.
It doesn't put the trace into memory. Every time you apply a new filter it re-reads the damn file!
Every time you apply a new filter it:
generates a complete protocol tree so that it can run the filter;
generates the column data so that it can add a row to the display;
and, as I remember from the last profiling runs done when running filters, that takes more time than does re-reading the raw packet data. A version of the Wiretap code to memory-map the capture file being read (with a mapping window so that files bigger than the amount of address space available for mapping can be read) might be interesting, although it wouldn't necessarily improve things much, as indicated. It'd also have to deal with gzipped capature files.
The one thing all sniffers lack that is needed is a quick and easy method to take notes. I'm constantly jotting down reminders, line #s, and ips on sticky notes. GIVE ME COPY & PASTE!
That's not "copy and paste"; "copy and paste" would be the ability to copy stuff from the capture dissection (some analyzers do that; Ethereal currently doesn't). That might let you copy line (packet?) numbers and IP addresses from captures into a text file, but not arbitrary notes.
What you're asking for sounds more like the ability to insert notes into the capture file itself. Some capture file formats support that, as do the analyzers using that format (I think Microsoft Network Monitor might). Ethereal's native format (libpcap) doesn't; the next generation of libpcap is intended to be extensible, and one extension would be comment records with arbitrary text in them.
...the VFS layer, which I'm pretty sure MacOS X has the equiv. of.
Yes, it's called the VFS layer (just as it is on other BSDs - and as it was in SunOS 2.0, which had a VFS layer before Linux existed; the BSD VFS layer is a bit like the one in various SunOS releases, although it's not the same).
Well finally OS X will have 64-bit pointers and
long longs.
Presumably you meant "longs":
% uname -sr Darwin 7.4.0 % sw_vers ProductName: Mac OS X ProductVersion: 10.3.4 BuildVersion: 7H63 % cat foo.c #include <stdio.h>
int main(int argc, char **argv) { printf("long longs are %lu bits\n", (unsigned long)(sizeof(long long))*8); return 0; } % gcc -o foo foo.c %./foo long longs are 64 bits
I.e., it's always had 64-bit "long long"s, if you needed a 64-bit integral data type, and those worked even on 32-bit processors (but then most compilers these days offer 64-bit integral data types on 32-bit processors, so that's not particularly exciting).
However, it didn't have 64-bit pointers or "long"s, so if you needed a >4GB address space you couldn't get what you need - that's what'll be in Tiger (for 64-bit processors only).
(note the space between "19604" and "28", which was in the original article), that doesn't mean they can just copy it and paste it to the location field in their browser and expect it to work (they have to remove the space, first).
I've seen that in Slashdot on a number of of occasions; I don't know if it's a bug in Slashcode or just somebody being sloppy when typing the URL. In this posting, it appears to be a Slashdot bug - previewing shows another space, between "196" and "04", but I didn't put that one in.
In any case, having to copy and paste the URL is a pain - and so is having to select it and then use OS X/Safari's "Services->Open URL" or the KDE menu item that pops up when URLs are selected or..., so I just format my postings as HTML and put in URLs as, well, links.
I have, although it's more obvious when reading it with Mail.app on my Mac at work than with Mutt on my machine at home - it shows up in the Cyrillic alphabet in Mail.app but not in Mutt in my boring old ISO 8859-1 xterm.
Messages in various Chinese/Japanese/Korean encodings look, when viewed by software assuming ISO 8859-1 encoding, like a different form of noise than messages in Cyrillic script, so you might be able to reconize Russian spam that way as well.
I actually got a piece of junk mail that I thought was funny once. The subject was "Hard times ahead!" and I thought it would be about saving money, but it was for viagra or something.
One of the funniest spams I saw was one posted to alt.sex.nfs (which I was reading at the time as I was working on NFS at Network Appliance) - it had the subject "Men needed for lesbian lust", which is somewhat of a Special Extra Bonus Unclear On The Concept subject line....
If caught early, and if you can figure out how to modulate the immune system (which has already been tried, and which alone does not seem to modify the course of the disease), then perhaps exenatide could be used to repopulate the pancreas.
Eh? I didn't see anything in the article about causing more beta cells to appear - it seemed to imply that the drug affected what the beta cells do:
The origin of the novel drug, called exenatide, is itself novel. It is a synthetic version of the hormone exendin-4, found in the saliva of the Gila monster, a lizard native to several Southwestern U.S. states. The Gila monster eats just four times a year and turns its pancreas off between those meals. When it's time to turn its pancreas on again, it secretes exendin-4.
The exendin-4 is similar in action to human GLP-1, a hormone produced in the gut that can stimulate insulin production without causing threateningly low blood sugar, which can occur after taking insulin and some oral anti-diabetes pills.
This doesn't look as if it'll do anything for Type 1, just Type 2.
So, let's see. It starts with "Mission Statement", follows that up with a <SPOILER>broken link</SPOILER>, and then has "Tocqueville Award".
So does the Tocqueville Award involve any money? If so, then, you can replace the "Accomplishments" with "???" by virtue either of it being a broken link or of the accomplishments being nonexistent, and one might consider "Steal underpants" to be a mission statement, thereby giving....
I don't really know what the issue is. There really are few programs out there that on Linux _don't_ use GTK or QT and use their cut/paste semantics, which I am quite familiar with. It works just like Windows...
I suspect the issue is, at least in part, one or more of
some people don't understand that selecting text doesn't automatically copy it to the clipboard, in most cases, and the middle mouse button doesn't paste the clipboard, in most cases, and therefore get confused by mixing the primary-selection-based select/middle-mouse-button mechanism and the clipboard-based ^C/^X/^V mechanism;
some people don't know that the clipboard-based ^C/^X/^V mechanism even exists in many X11 toolkits and applications (where "many" includes the toolkits for GNOME and KDE, so "many" here is a lot);
some applications/toolkits don't implement the behaviors described in the X clipboard explanation, leading people to believe the problem is "the clipboard is completely broken in X" because they generalize from problems with some applications and to then act as if ^C/^X/^V is completely unavailable.
There are three things called "selections" in X terminology, only one of which is properly called a "clipboard" (otherwise, you run the risk of confusing the heck out of people used to the meaning of "clipboard" in other GUIs):
the PRIMARY selection;
the SECONDARY selection;
the CLIPBOARD selection.
The SECONDARY selection, however, is not used by many toolkits; I think XView (Sun's OPEN LOOK-ified port of their old toolkit for their old pre-X11 and pre-NeWS window system) and OLIT (AT&T's Xt-based OPEN LOOK toolkit) might have used it, but I don't know of any other toolkits that do.
The X clipboard that nabs anything highlighted and pastes with the middle button.
That's the PRIMARY selection.
KDE (or is it Qt?) has a clipboard that works in more the way we think it should work.
It's Qt, and it's the CLIPBOARD selection, although Qt prior to 3.0 (hence, KDE prior to 3.0) didn't, as I remember, use it at all, it used the PRIMARY selection as the clipboard - 3.0 and later use CLIPBOARD for that.
Gnome ( or is it GTk ? ) seems to have it's own clipboard too!
Really? It should just be using CLIPBOARD; what behaviors lead you to think it's using something different from KDE 3.x?
Is there a way to get xterm to use the Clipboard selector, instead of the Primary selector?
Use it for what? If you want to have selections become the clipboard selection rather than the primary selection and have the middle mouse button paste the clipboard (and thus make xterm behave differently from most other applications on your desktop, and run the risk of confusion with applications that use PRIMARY and CLIPBOARD in the fashion recommended by the X clipboard explanation:
selecting but with no explicit copy should only set PRIMARY, never CLIPBOARD
middle mouse button should paste PRIMARY, never CLIPBOARD
explicit cut/copy commands (i.e. menu items, toolbar buttons) should always set CLIPBOARD to the currently-selected data (i.e. conceptually copy PRIMARY to CLIPBOARD)
explicit paste commands should paste CLIPBOARD, not PRIMARY)
you can probably set mouse bindings in your.Xdefaults file.
Slashdot Mirror
YR.
Well, that'll show that damn Windows lover!
In order not to rig the competition so that a Windows box is inherently excluded merely by virtue of running Windows (given that this does appear to be a bit of an OS X vs. Windows debate, and a rigged debate is only interesting in its perversity), you might want to eliminate that requirement, or replace it with a requirement for XP Pro rather than XP Home if that makes sense in an Apples-to-Wintel^Wapples-to-apples comparison.
At least in my experience, it often does, but it doesn't always do so. From some experimentation I just did, it appears to base it on the address to which the mail was sent - but if it was sent to a mailing list, so that none of my e-mail addresses appear in the To: or Cc: header, it doesn't pick the address I happen to use on that list.
If it could be given rules to say "if it's to any of these addresses, use address XXX in replies", as I infer (perhaps incorrectly) Pine can, that could be fixed.
Such as Mail.app in its spam filter. I don't know whether that technique can be used for other mail filters - the spam filter might have been told some information about spam to get it started, with subsequent reclassifications of purported spam as non-spam and purported non-spam as spam updating it, but I don't know whether it'd work without that sort of preloading.
No, that one's already been used.
Or maybe Feral Tabby.
I tried, but it didn't have an entry for "Xenu" - or "Xemu", for that matter.
Surely you mean "the source to the Darwin that is contained in the Tiger WWDC preview is available now". Mac OS X 10.4 hasn't, as the original poster noted, been released yet, and source to it isn't available for the simple reason that it doesn't yet exist.
Really? Some stuff in Windows might be inspired by stuff in UNIX, but it's not really a descendant, and, as for Mac OS, or, at least, Mac OS X:
Looks more like the UNIXes I'm used to than the ifconfig output I've seen on Linux distributions.... (Ignore the lack of indentation - the lines after the "lo0" line really are indented, they just don't show up as such inside <ECODE>.)
That's an extreme example, perhaps, but the OS X boxes on which I type look pretty much like any other UN*X boxes - there are things that are different from other UN*X boxes, but if some alleged UN*X doesn't do at least one thing annoyingly different from most of the other UN*Xes out there, it's not really UN*X-compatible - doing something different is pretty much a requirement for being a "real UN*X". :-)
The OS X GUI is different from that on other UN*Xes, but then CDE is different from GNOME is different from KDE is different from..., so it's not as if OS X is entirely unique in that respect (although it's less Windowsish than many of the other UN*X desktop environments).
In what sense? Windows NT (including NT 5.x, i.e. W2K, WXP, and W2K3 Server) has a pluggable file system interface, and I think Windows OT (95/98/Me) did as well, just as Linux has one (its VFS), and most other UNIX-flavored OSes now do (going back to SunOS 2.0 and its VFS).
Perhaps some applications expect support for multiple streams in files, but even those applications should work either with NTFS or with the SMB client file system when it's talking to a server that supports multiple streams in files (and those applications won't work on Windows OT, so there probably aren't a lot of applications that require multiple streams in files, as opposed to ones that'll use them if available and fall back on some other mechanism if not).
The Intel i860? :-) NT, at least, was allegedly originally developed for the i860 (in the sense that the machines on which it was run during development were i860-based machines), but with at least some amount of portability in mind as it'd also have to run on x86 as well (and perhaps because the i860 was replaced by MIPS processors, and later ports were done to PowerPC and Alpha; it's also recently been ported to IA-64 and AMD64).
Windows OT was x86-only; are you thinking of Windows OT here?
What are some examples of how Windows has less abstraction between the kernel and the shell? ("Shell" either as "command interpreter" or "desktop environment".)
There's no sorting done when the file is opened; do you mean that if the packets are out of order by time stamp in the capture file (which would be the result of a bug in the underlying capture mechanism - it should be delivering packets in time-stamp order; when do you see out-of-order packets?), Ethereal should re-order them?
If Ethereal were to do that, note that Tethereal wouldn't be able to reorder them, as it is, by design and intent, a one-pass program.
And Ethereal has, of course, the exact same filtering for captures (because they both use libpcap for capturing and filtering of captures). Ethereal's display filtering can do the same sort of things, albeit with different syntax (tcpdump's syntax doesn't fit the "filter on arbitrary field" model Ethereal has; it might be nice to have Ethereal translate a smaller display-filter-like language into capture filters - the full display filter syntax isn't implementable with BPF-style capture filters - and that might happen at some point).
"Sort logs by date" in what sense? Presumably something other than sorting by clicking on the title of the "Time" column if it's configured to display absolute time or absolute date and time.
Non-trivial to implement - doable, but we'd need to make a lot of state information per-trace (i.e., attach it to a capture file structure) rather than global.
Every time you apply a new filter it:
and, as I remember from the last profiling runs done when running filters, that takes more time than does re-reading the raw packet data. A version of the Wiretap code to memory-map the capture file being read (with a mapping window so that files bigger than the amount of address space available for mapping can be read) might be interesting, although it wouldn't necessarily improve things much, as indicated. It'd also have to deal with gzipped capature files.
That's not "copy and paste"; "copy and paste" would be the ability to copy stuff from the capture dissection (some analyzers do that; Ethereal currently doesn't). That might let you copy line (packet?) numbers and IP addresses from captures into a text file, but not arbitrary notes.
What you're asking for sounds more like the ability to insert notes into the capture file itself. Some capture file formats support that, as do the analyzers using that format (I think Microsoft Network Monitor might). Ethereal's native format (libpcap) doesn't; the next generation of libpcap is intended to be extensible, and one extension would be comment records with arbitrary text in them.
Yes, it's called the VFS layer (just as it is on other BSDs - and as it was in SunOS 2.0, which had a VFS layer before Linux existed; the BSD VFS layer is a bit like the one in various SunOS releases, although it's not the same).
So does Avie Tevanian, it appears, according to what he said at a recent conference.
Presumably you meant "longs":
I.e., it's always had 64-bit "long long"s, if you needed a 64-bit integral data type, and those worked even on 32-bit processors (but then most compilers these days offer 64-bit integral data types on 32-bit processors, so that's not particularly exciting).
However, it didn't have 64-bit pointers or "long"s, so if you needed a >4GB address space you couldn't get what you need - that's what'll be in Tiger (for 64-bit processors only).
...and for people who don't understand that, just because something looking like a URL shows up in a Slashdot article, such as
(note the space between "19604" and "28", which was in the original article), that doesn't mean they can just copy it and paste it to the location field in their browser and expect it to work (they have to remove the space, first).
I've seen that in Slashdot on a number of of occasions; I don't know if it's a bug in Slashcode or just somebody being sloppy when typing the URL. In this posting, it appears to be a Slashdot bug - previewing shows another space, between "196" and "04", but I didn't put that one in.
In any case, having to copy and paste the URL is a pain - and so is having to select it and then use OS X/Safari's "Services->Open URL" or the KDE menu item that pops up when URLs are selected or..., so I just format my postings as HTML and put in URLs as, well, links.
I have, although it's more obvious when reading it with Mail.app on my Mac at work than with Mutt on my machine at home - it shows up in the Cyrillic alphabet in Mail.app but not in Mutt in my boring old ISO 8859-1 xterm.
Messages in various Chinese/Japanese/Korean encodings look, when viewed by software assuming ISO 8859-1 encoding, like a different form of noise than messages in Cyrillic script, so you might be able to reconize Russian spam that way as well.
One of the funniest spams I saw was one posted to alt.sex.nfs (which I was reading at the time as I was working on NFS at Network Appliance) - it had the subject "Men needed for lesbian lust", which is somewhat of a Special Extra Bonus Unclear On The Concept subject line....
Eh? I didn't see anything in the article about causing more beta cells to appear - it seemed to imply that the drug affected what the beta cells do:
This doesn't look as if it'll do anything for Type 1, just Type 2.
...which takes you to a page with
So, let's see. It starts with "Mission Statement", follows that up with a <SPOILER>broken link</SPOILER>, and then has "Tocqueville Award".
So does the Tocqueville Award involve any money? If so, then, you can replace the "Accomplishments" with "???" by virtue either of it being a broken link or of the accomplishments being nonexistent, and one might consider "Steal underpants" to be a mission statement, thereby giving....
That can probably also be configured by setting the resources for xterm to have the appropriate key binding for the key you want.
I suspect the issue is, at least in part, one or more of
...in some toolkits and/or some applications. Those should be fixed, so that selecting affects only PRIMARY and leaves CLIPBOARD the hell alone.
Other toolkits do the right thing.
There are three things called "selections" in X terminology, only one of which is properly called a "clipboard" (otherwise, you run the risk of confusing the heck out of people used to the meaning of "clipboard" in other GUIs):
The SECONDARY selection, however, is not used by many toolkits; I think XView (Sun's OPEN LOOK-ified port of their old toolkit for their old pre-X11 and pre-NeWS window system) and OLIT (AT&T's Xt-based OPEN LOOK toolkit) might have used it, but I don't know of any other toolkits that do.
That's the PRIMARY selection.
It's Qt, and it's the CLIPBOARD selection, although Qt prior to 3.0 (hence, KDE prior to 3.0) didn't, as I remember, use it at all, it used the PRIMARY selection as the clipboard - 3.0 and later use CLIPBOARD for that.
Really? It should just be using CLIPBOARD; what behaviors lead you to think it's using something different from KDE 3.x?
Use it for what? If you want to have selections become the clipboard selection rather than the primary selection and have the middle mouse button paste the clipboard (and thus make xterm behave differently from most other applications on your desktop, and run the risk of confusion with applications that use PRIMARY and CLIPBOARD in the fashion recommended by the X clipboard explanation:
you can probably set mouse bindings in your .Xdefaults file.