Bloglines is, mostly, great. It does at least one thing right: it views feeds inline, blog/Slashdot-style.
I am one of those readers to whom reading by headline is practically impossible: I read by viewing the content in the aggregate, not by actually reading every headline.
None of the three-pane readers work for me, then. They force me to click on a headline, read its contents. Then click on another one, then read that.
Nobody writes good headlines. So when the mass of information reaches a certain level (anything above half a screenful or so of entries), it becomes chaotic, anonymous and uninteresting. I have the same problem with newsgroups and mailing lists.
So Bloglines solves that. However, it has an extremely vicious interface deficiency: it automatically marks everything you see as read by default, even if you haven't read it.
Come on, that's crazy. It has a tiny checkbox next to each entry in order to allow me to keep it unread. Crazy. It means that if I click on a feed and then change my mind about reading it right now, the entire read state of that screwed.
Instead, it should provide a reasonably large clickable surface allowing me to mark something as read, preferably by immediately hiding -- or collapsing into a very small space -- the entry using DHTML/CSS.
Since I can't use Bloglines, can anyone recommend a newspaper-style feed reader on Windows? I've tried BlogExpress, which is friendly and streamlined, but it uses IE as its HTML browser, which is not something I want to touch.
Copying and improving. They are evolving an existing design, a design that hasn't changed in 20 or 30 years. That design hasn't been frozen for so long because it's perfect, but because it's "just good enough" for people to consider and rethink.
What? Copying Windows? I thought we already were...
Yep.
Everyoneiscopyingeveryoneelse. It's the nature of design: for the next generation, always combine the best bits of everything else.
Yes, everything's dandy, until you happen to be using two programs that don't export and import data in compatible formats.
You missed the part about the type system, then. Any program can access the data, because the data is packed in nice structured.NET types -- arrays, lists, instances, etc. You use reflection to inspect even types your program doesn't understand.
For example, if something wants to sort objects on an attribute "name", it doesn't need to know the type of the input: it just asks for the value of the name properties. Obviously a sorter needs to know how to compare values against each other: it needs, in short, to be able to turn anything into a string. Those things are solved using formal interfaces: if your "name" attribute is not a string object, it needs to support an interface that allows it to be turned into a string on command (just like Python's __str__(), Java's toString(), etc.). With.NET's type system and automatic boxing/unboxing you already have a rich set of types to interact with.
The challenge here is agreeing on a set of interfaces that make programs able to interact beyond the basic.NET primitives. For example, let's say the output of my program consists of image bitmaps. Something like a class with an (x, y) extent and a vector of RGB objects. All you need to share such objects is to specify the appropriate interface for clients to use. The client certainly doesn't need any of the originator program's code, just the interface.
If you think about it, such interfaces already exist in daily usage in a different format: JPEG. GIF. PNG. They're standards need for interoperability. In the same way, programs need to standardize their exchange mechanisms, and if you're saying that the solution is for "everything to be just text" (or more precisely, octet streams) then you're just moving the problem somewhere else. Ultimate, at some point that text/those octets need to become something else.
Microsoft is doing something interesting and innovating. The Unix world could use this.
Basically, Monad formalizes in.NET the pipe interface between shell programs. A pipe participant is just something that implements the appropriate "commandlet" interface: it receives some input, produces some output, maybe some errors.
However, in the case of Monad the input and output can be anything, not just text. So in the example:
The get-process command produces a sequence of processes; where filters it based on an attribute; sort sorts on an attribute, and out-chart produces a textual table of the filtered output.
It's important that the input and output of these processes are structures (actually, objects, but I don't want to tickle anyone's prejudices about OOP)..NET knows at runtime about the attributes these structures can have, so you can write apps that manipulate a wide variety of object types: files, metadata-annotated documents, log entries, whatever.
Naturally input/output can be pure text, allowing all the traditional Unix commands such as grep.
Immediate benefit? If you have the right translator, there's no need to munge text output using awkward tools like tr, cut, awk and so on, just to get at the process ID column of ps or the URL column of the Apache log file.
AP: Why did you change your mind and decide to put the original three movies out on DVD now?
Lucas: Just because the market has shifted so dramatically. A lot of people are getting very worried about piracy. That has really eaten dramatically into the sales. It really just came down to, there may not be a market when I wanted to bring it out, which was like, three years from now. So rather than just sit by and watch the whole thing fall apart, better to bring it out early and get it over with.
Does this strike anyone else as incredibly short-sighted? Never mind that he's saying right out that the reason for putting out the DVDs are purely financial. But he also suspects that nobody will be making money on publishing movies in three years' time. He clearly doesn't care about putting out a physical box set for fans to cherish on their mantelpieces, before the time comes when publishing anything physical is no longer feasible: he's talking about money.
Firstly the tab extensions does not seem to be a supported extension. Now I've read often enough about how it is horrible and ugly and all, but I use it for everyday browsing. I'd really like the default to be "open link in new tab" for just about everything with the middle mouse button set to "open link in this tab". The tab groups are also nice, but could be managed outside the standard tab extensions.
If you're referring to the Tabbrowser Extensions plugin, it works, and you can install it right here. It has been updated to work with the RC.
The only plugin that I so far I have not found an update to is the Googlebar.
I'm not fond of OOP, but it sure makes sense when you deal with visual objects, and OpenGL doesn't really feel OO. Dealing with OpenGL for Lisp or Python is easy, but sure as hell ain't pretty.
You seem to have a mistaken understanding of what Direct3D is.
Direct3D does offer a retained-mode API -- a scene graph engine, to be precise -- in which language-level objects are used to represent scene objects, such as frames, lights, cameras, meshes and textures. No game, and no application that I know, uses this API. (As the interface to a scene graph engine, it's horribly convoluted and hard to use.)
What games use is the immediate-mode API, which is basically just a way to throw triangles at the video card -- no support for cameras, for example, or animation, both of which must be handled by the application, which is why you need a higher-level scene-graph engine on top of the API. In this respect, Direct3D is very much like OpenGL.
More recently,.org and.info domain registry company Afilias has sponsored developer Jan Wieck to work full time on developing a new, enterprise-class replication system for PostgreSQL called Slony-I, to be presented next month at OSCON in Portland, Ore.
Except Slony-I is a single-master/multiple-slave replication system -- hardly "enterprise-class".
What's slightly noteworthy about Slony is that it has "switchover" support. If the master fails, one of the slaves become the master.
Of course, since Slony's replication is asynchronous, it means that at the point of switchover, slaves might not have received all pending changes, thus becoming out of sync with the master. Unfortunately, Slony doesn't really address this problem.
The design overview is useful reading, if rather confusing; the writer's first language is probably not English.
Microsoft's downloadables, including SP2, are hosted by Akamai. Akamai's proximity-based distribution mechanism is essentially a competitor to BitTorrent. As some users are discovering, downloading directly from Microsoft -- that is, through Akamai -- is actually faster and more bandwidth-efficient than with BitTorrent.
Not that this in any way puts BitTorrent in a bad light: First of all, Akamai is a commercial system, and Microsoft pays a lot of money to use it. Akamai is itself a system that scales statically, by providing fixed caches located around the globe; it must be manually maintained in order to scale.
BitTorrent, on the other hand, is free, and is built on a pool of dynamic caches (ie., seeders), allowing it to scale indefinitely. BitTorrent's seeding system has weaknesses, but it's one of the best solutions so far.
Q: How did you manage to achieve such high performance without cache and additional I/O processor?
A: The RAID processing and caching is done on the host motherboard. Performance is so high because of today's high CPU speeds and patented RAIDCore RAID algorithms.
The picture is being co-financed by Warner Independent, a new division of WB devoted to serious films with modest budgets.
Warner Independent? Isn't that a bit like Kraft Foods creating a new division called Mom & Pop?
I have nothing against a studio deciding to do "serious films with modest budgets", but this blatant abuse of the word independent is moronic and, of course, deceiving.
, despite the title, is a faithful, low-budget, low-key adaptation of "Second Variety." Unfortunately it's also a bit of a bore.
Actually, Screamers isn't faithful to the original short story at all. The short story doesn't have any "screamers". It doesn't have any Shakespeare-quoting villains. Or peace negotiations.
Damn you, Dan O'Bannon, for leaving your talent behind in Alien. And curse you, Christian Duguay, for not sticking to Scanners sequels.
I would love to switch. I love the choice of file systems, the superior kernel, the superior security, the superior software management system (APT), etc. But there are a number of problems standing in my way.
Speed. First of all, I'm used to -- and pampered by, perhaps -- the wonderful performance of Windows' GUI. It's simply extremely responsive. I wrote this in a Slashdot thread recently, but nobody replied:
Between Windows 2000, Linux (both on the same system, NVidia GF4 MX) and Mac OS X (Panther, on a 1GHz PowerBook), I would say that the Windows GUI feels extremely zippy, Linux feels sluggish, and OS X feels positively pedestrian.
Question: How does FreeBSD compare?
As far as I know, Windows derives most of its speed from having display drivers live in kernel space. NVidia's XFree86 driver actually uses a kernel module, so in theory the two architectures should be roughly equal; is XFree86's internal architecture that bad compared to Windows and GDI?
FreeBSD's kernel is, according to its adherents, faster than Linux. Apparently it had an O(1) scheduler long before Linux. How well does XFree86 run on FreeBSD?
Anyone want to reply this time around? I should add that by sluggish I mean noticeably, unacceptably slow on an Athlon XP 2500+ with 1GB of RAM. If you're a Linux user it's probably not something you would notice unless you spent a few weeks on Windows and then went back. Also, I should like to point out that I turn off most performance-crippling visual bells and whistles (anti-aliasing, drop shadows, animation, fading) on Windows as well as Linux.
Consistency. Windows' GUI is also fairly consistent with respect to keyboard shortcuts, clipboard functionality, drag/drop etc. There is a whole bunch of applications that subvert Windows' natural consistency by inventing their own widgets (Microsoft Office is one example, but by no means the worst), but they are the minority.
On Linux you have GNOME and KDE and the big glaring seams between them. GNOME's file open/save/etc. dialogs are completely different (and vastly inferior to, imho) KDE's, for example. Keyboard shortcuts such as for clipboard accessing also don't seem consistent. You can cross-dress the toolkits with compatibility themes to make them appear identical, but they still behave differently.
Applications. Windows' file manager, Explorer, is not a great app by far, but it's fast and effective. Nautilus and Konqueror are bloated and slow, full of features I don't want and missing the ones I do want; for example, Nautilus, last I tried it, had a folder pane that only allowed opening and closing of folders, no interaction; and where's the click-and-drag to select multiple elements?
Speaking of file management, where's the transparent, GUI-managed support for Samba, FTP and WebDAV browsing that's also integrated into the OS so that mounts are available to other, non-GNOME/KDE apps? I'm sure it's in there somewhere, but I've never been able to find it. Windows has had network-transparent file-system-mounting for, what, 10 years? OS X has had it since its first release.
While Linux/BSD seem to have a larger quantity of apps, the quality is so-so.
For example, on Windows, I have foobar2000, a most excellent audio player blissfully free of visual bells or whistles; pure function. On Linux, it seems I have the option of XMMS (horrible Winamp clone), ZINF (horrible I-don't-know-what) and something GNOME calls "Music organizer and player", plus a whole bunch of other ugly, nerdy-looking apps with nothing to set them apart from the rest.
On Windows, I have Klient and mIRC, two excellent IRC clients; on Linux, there is X-Chat, not an excellent IRC client. On Windows, I have Media Player Classic for playing movies, another hyper-functional, minimalistic app; on Linux I have MPlayer, VLC and Kaboodle -- 'nuff said. On Windows I have Nero for CD/DVD burning, but I haven't seen anything worthwhile on Li
To share an experience with the Jabber server and offer a note on our workaround.
With a Jabber server. I suspect you would have had greater success with the C server, btw. One nice aspect of the server architecture, incidentally, is that it can easily be clustered, meaning it is extremely scalable.
It's not really a product, per se... I mean, it's open source and free.
While I dislike having to go into a discussion about language, I'd like to point that product implies neither "non-open-source" or "non-free".
They're two different things - COUGAAR is a distributed agent architecture, Jabber is a messaging protocol. I'm not sure a comparison is really in order...
You were able to exchange one for the other, so I do think a comparison is in order; you brought it up. Both include a message routing system.
Jabber is more than a messaging protocol, though. It's not a single protocol, but a set of protocols. It encompasses presence, discovery (through directory services), gatewaying, routing, conferencing, remote procedure calls, authentication -- additionally, the XMPP protocol is extensible, so there are no limits, really.
Anyway, as you pointed out, your problem was implementation-related, not necessarily architecture-related; so instead of blatantly generalizing about "Jabber... being too slow", what you really meant is that one particular Jabber implementation was too slow for your needs.
Sorry if I'm being harsh, but I dislike people throwing out careless, vague comments that give a bad name to other people's work.
Jabber ended up being too slow, though, so we built a more specialized message router...
While I understand the intended meaning -- that Jabber was not suitable for your application -- I dislike (1) the implication that Jabber is somehow inherently slow (what was slow? The Jabber4R client library? The Jabber server? Which server? Or the architecture?), and (2) the fact that you are providing no new information, but merely throwing out some vague, critical remark about Jabber of no use to anyone, leading up to a shameless plug for your own unrelated product. What was your point, man?
How about doing a design comparison between Cougaar and Jabber?
One drawback with SCSI is that you'll have to deal with a number of different cable/connector formats and terminators.
You seem to be operating under the assumption that there is one interface called SCSI, which is false, and grouping them all under the term "SCSI" when discussing cabling is showing off your ignorance.
If your system is a Fast SCSI system and you buy an Ultra2 SCSI hard drive, you have, by definition, incompatible devices, requiring adapter hardware or possibly a new controller. As a consumer, this is like buying a SCART DVD player to connect to your coax RF TV. Or a FireWire video camera to connect to your USB-only PC.
You could argue that this "impedance mismatch" is a problem with the SCSI standard process (why can't they master cable compatibility if the Ethernet guys can?), but this is reality -- SCSI is both a physical and a logical interface, and the physical interface is subject to the requirements/limitations of our physical reality in terms of how electrons can be transported efficiently around. Reality, and by extension hardware, is not malleable in the same sense that software is.
No, SCSI is "plug and then realize you hadn't shut down the computer...
I spy a troll. You actually tried to hot-plug a hard drive, and suffered the consequences. How is this a misfeature of SCSI?
Your complaint about cables is equally misguided; it is you who don't have the right equipment. Do you complain in the same way when trying to mount a CD-ROM drive with chassis screws?
Between Windows 2000, Linux (both on the same system, NVidia GF4 MX) and Mac OS X (Panther, on a 1GHz PowerBook), I would say that the Windows GUI feels extremely zippy, Linux feels sluggish, and OS X feels positively pedestrian.
Question: How does FreeBSD compare?
As far as I know, Windows derives most of its speed from having display drivers live in kernel space. NVidia's XFree86 driver actually uses a kernel module, so in theory the two architectures should be roughly equal; is XFree86's internal architecture that bad compared to Windows and GDI?
FreeBSD's kernel is, according to its adherents, faster than Linux. Apparently it had an O(1) scheduler long before Linux. How well does XFree86 run on FreeBSD?
Probably just my lack of experience, but I have a friend who helped me with the install, and he is definitly experienced - but it just was tricky to get it working.
That's not fickle, a word which means, in this context, unstable. You just mean "hard to use".
However, SCSI is arguably easier to set up than IDE/ATA. SCSI is "plug and play" (except when you have conflicting IDs), whereas ATA still has the concept of master/slave/single modes, with physical jumper settings to get things right.
The reason SCSI might be more difficult for the end user to set up is that operating system boot disks and installers frequently come with a wide range of ATA controller drivers, but only a handful of SCSI controller drivers.
Slashdot Mirror
I am handy with scripting languages, but I don't really have the patience to tweak something like this. Does AmphetaDesk behave like I want?
I am one of those readers to whom reading by headline is practically impossible: I read by viewing the content in the aggregate, not by actually reading every headline.
None of the three-pane readers work for me, then. They force me to click on a headline, read its contents. Then click on another one, then read that.
Nobody writes good headlines. So when the mass of information reaches a certain level (anything above half a screenful or so of entries), it becomes chaotic, anonymous and uninteresting. I have the same problem with newsgroups and mailing lists.
So Bloglines solves that. However, it has an extremely vicious interface deficiency: it automatically marks everything you see as read by default, even if you haven't read it.
Come on, that's crazy. It has a tiny checkbox next to each entry in order to allow me to keep it unread. Crazy. It means that if I click on a feed and then change my mind about reading it right now, the entire read state of that screwed.
Instead, it should provide a reasonably large clickable surface allowing me to mark something as read, preferably by immediately hiding -- or collapsing into a very small space -- the entry using DHTML/CSS.
Since I can't use Bloglines, can anyone recommend a newspaper-style feed reader on Windows? I've tried BlogExpress, which is friendly and streamlined, but it uses IE as its HTML browser, which is not something I want to touch.
TheOneRing.net reports on confirmed and presumed new scenes in the extended edition.
Copying and improving. They are evolving an existing design, a design that hasn't changed in 20 or 30 years. That design hasn't been frozen for so long because it's perfect, but because it's "just good enough" for people to consider and rethink.
Yep. Everyone is copying everyone else. It's the nature of design: for the next generation, always combine the best bits of everything else.
- Yes, everything's dandy, until you happen to be using two programs that don't export and import data in compatible formats.
You missed the part about the type system, then. Any program can access the data, because the data is packed in nice structuredFor example, if something wants to sort objects on an attribute "name", it doesn't need to know the type of the input: it just asks for the value of the name properties. Obviously a sorter needs to know how to compare values against each other: it needs, in short, to be able to turn anything into a string. Those things are solved using formal interfaces: if your "name" attribute is not a string object, it needs to support an interface that allows it to be turned into a string on command (just like Python's __str__(), Java's toString(), etc.). With .NET's type system and automatic boxing/unboxing you already have a rich set of types to interact with.
The challenge here is agreeing on a set of interfaces that make programs able to interact beyond the basic .NET primitives. For example, let's say the output of my program consists of image bitmaps. Something like a class with an (x, y) extent and a vector of RGB objects. All you need to share such objects is to specify the appropriate interface for clients to use. The client certainly doesn't need any of the originator program's code, just the interface.
If you think about it, such interfaces already exist in daily usage in a different format: JPEG. GIF. PNG. They're standards need for interoperability. In the same way, programs need to standardize their exchange mechanisms, and if you're saying that the solution is for "everything to be just text" (or more precisely, octet streams) then you're just moving the problem somewhere else. Ultimate, at some point that text/those octets need to become something else.
(By the way, I'm not a .NET developer.)
Basically, Monad formalizes in .NET the pipe interface between shell programs. A pipe participant is just something that implements the appropriate "commandlet" interface: it receives some input, produces some output, maybe some errors.
However, in the case of Monad the input and output can be anything, not just text. So in the example:
- get-process | where "handlecount -gt 400" | sort handlecount | out-chart processname,handlecount
The get-process command produces a sequence of processes; where filters it based on an attribute; sort sorts on an attribute, and out-chart produces a textual table of the filtered output.It's important that the input and output of these processes are structures (actually, objects, but I don't want to tickle anyone's prejudices about OOP). .NET knows at runtime about the attributes these structures can have, so you can write apps that manipulate a wide variety of object types: files, metadata-annotated documents, log entries, whatever.
Naturally input/output can be pure text, allowing all the traditional Unix commands such as grep.
Immediate benefit? If you have the right translator, there's no need to munge text output using awkward tools like tr, cut, awk and so on, just to get at the process ID column of ps or the URL column of the Apache log file.
This is better than Unix shells.
Lucas: Just because the market has shifted so dramatically. A lot of people are getting very worried about piracy. That has really eaten dramatically into the sales. It really just came down to, there may not be a market when I wanted to bring it out, which was like, three years from now. So rather than just sit by and watch the whole thing fall apart, better to bring it out early and get it over with.
Does this strike anyone else as incredibly short-sighted? Never mind that he's saying right out that the reason for putting out the DVDs are purely financial. But he also suspects that nobody will be making money on publishing movies in three years' time. He clearly doesn't care about putting out a physical box set for fans to cherish on their mantelpieces, before the time comes when publishing anything physical is no longer feasible: he's talking about money.
If you're referring to the Tabbrowser Extensions plugin, it works, and you can install it right here. It has been updated to work with the RC.
The only plugin that I so far I have not found an update to is the Googlebar.
-
I'm not fond of OOP, but it sure makes sense when you deal with visual objects, and OpenGL doesn't really feel OO. Dealing with OpenGL for Lisp or Python is easy, but sure as hell ain't pretty.
You seem to have a mistaken understanding of what Direct3D is.Direct3D does offer a retained-mode API -- a scene graph engine, to be precise -- in which language-level objects are used to represent scene objects, such as frames, lights, cameras, meshes and textures. No game, and no application that I know, uses this API. (As the interface to a scene graph engine, it's horribly convoluted and hard to use.)
What games use is the immediate-mode API, which is basically just a way to throw triangles at the video card -- no support for cameras, for example, or animation, both of which must be handled by the application, which is why you need a higher-level scene-graph engine on top of the API. In this respect, Direct3D is very much like OpenGL.
Jaws the game is about a shark trying to win by chasing boats, people etc.
It's like making a game called Jurassic Park in which you play the T-Rex. For a movie adaptation this is something of a stretch.
- More recently,
.org and .info domain registry company Afilias has sponsored developer Jan Wieck to work full time on developing a new, enterprise-class replication system for PostgreSQL called Slony-I, to be presented next month at OSCON in Portland, Ore.
Except Slony-I is a single-master/multiple-slave replication system -- hardly "enterprise-class".What's slightly noteworthy about Slony is that it has "switchover" support. If the master fails, one of the slaves become the master.
Of course, since Slony's replication is asynchronous, it means that at the point of switchover, slaves might not have received all pending changes, thus becoming out of sync with the master. Unfortunately, Slony doesn't really address this problem.
The design overview is useful reading, if rather confusing; the writer's first language is probably not English.
Not that this in any way puts BitTorrent in a bad light: First of all, Akamai is a commercial system, and Microsoft pays a lot of money to use it. Akamai is itself a system that scales statically, by providing fixed caches located around the globe; it must be manually maintained in order to scale.
BitTorrent, on the other hand, is free, and is built on a pool of dynamic caches (ie., seeders), allowing it to scale indefinitely. BitTorrent's seeding system has weaknesses, but it's one of the best solutions so far.
A: The RAID processing and caching is done on the host motherboard. Performance is so high because of today's high CPU speeds and patented RAIDCore RAID algorithms.
- The picture is being co-financed by Warner Independent, a new division of WB devoted to serious films with modest budgets.
Warner Independent? Isn't that a bit like Kraft Foods creating a new division called Mom & Pop?I have nothing against a studio deciding to do "serious films with modest budgets", but this blatant abuse of the word independent is moronic and, of course, deceiving.
Actually, Screamers isn't faithful to the original short story at all. The short story doesn't have any "screamers". It doesn't have any Shakespeare-quoting villains. Or peace negotiations.
Damn you, Dan O'Bannon, for leaving your talent behind in Alien. And curse you, Christian Duguay, for not sticking to Scanners sequels.
Are there any Xbox players with web-based front ends?
I'm obviously still on Windows, and I secretly wanted to comment on the other story. Have mercy.
Speed. First of all, I'm used to -- and pampered by, perhaps -- the wonderful performance of Windows' GUI. It's simply extremely responsive. I wrote this in a Slashdot thread recently, but nobody replied:
Question: How does FreeBSD compare?
As far as I know, Windows derives most of its speed from having display drivers live in kernel space. NVidia's XFree86 driver actually uses a kernel module, so in theory the two architectures should be roughly equal; is XFree86's internal architecture that bad compared to Windows and GDI?
FreeBSD's kernel is, according to its adherents, faster than Linux. Apparently it had an O(1) scheduler long before Linux. How well does XFree86 run on FreeBSD?
Anyone want to reply this time around? I should add that by sluggish I mean noticeably, unacceptably slow on an Athlon XP 2500+ with 1GB of RAM. If you're a Linux user it's probably not something you would notice unless you spent a few weeks on Windows and then went back. Also, I should like to point out that I turn off most performance-crippling visual bells and whistles (anti-aliasing, drop shadows, animation, fading) on Windows as well as Linux.
Consistency. Windows' GUI is also fairly consistent with respect to keyboard shortcuts, clipboard functionality, drag/drop etc. There is a whole bunch of applications that subvert Windows' natural consistency by inventing their own widgets (Microsoft Office is one example, but by no means the worst), but they are the minority.
On Linux you have GNOME and KDE and the big glaring seams between them. GNOME's file open/save/etc. dialogs are completely different (and vastly inferior to, imho) KDE's, for example. Keyboard shortcuts such as for clipboard accessing also don't seem consistent. You can cross-dress the toolkits with compatibility themes to make them appear identical, but they still behave differently.
Applications. Windows' file manager, Explorer, is not a great app by far, but it's fast and effective. Nautilus and Konqueror are bloated and slow, full of features I don't want and missing the ones I do want; for example, Nautilus, last I tried it, had a folder pane that only allowed opening and closing of folders, no interaction; and where's the click-and-drag to select multiple elements?
Speaking of file management, where's the transparent, GUI-managed support for Samba, FTP and WebDAV browsing that's also integrated into the OS so that mounts are available to other, non-GNOME/KDE apps? I'm sure it's in there somewhere, but I've never been able to find it. Windows has had network-transparent file-system-mounting for, what, 10 years? OS X has had it since its first release.
While Linux/BSD seem to have a larger quantity of apps, the quality is so-so.
For example, on Windows, I have foobar2000, a most excellent audio player blissfully free of visual bells or whistles; pure function. On Linux, it seems I have the option of XMMS (horrible Winamp clone), ZINF (horrible I-don't-know-what) and something GNOME calls "Music organizer and player", plus a whole bunch of other ugly, nerdy-looking apps with nothing to set them apart from the rest.
On Windows, I have Klient and mIRC, two excellent IRC clients; on Linux, there is X-Chat, not an excellent IRC client. On Windows, I have Media Player Classic for playing movies, another hyper-functional, minimalistic app; on Linux I have MPlayer, VLC and Kaboodle -- 'nuff said. On Windows I have Nero for CD/DVD burning, but I haven't seen anything worthwhile on Li
- To share an experience with the Jabber server and offer a note on our workaround.
With a Jabber server. I suspect you would have had greater success with the C server, btw. One nice aspect of the server architecture, incidentally, is that it can easily be clustered, meaning it is extremely scalable.- It's not really a product, per se... I mean, it's open source and free.
While I dislike having to go into a discussion about language, I'd like to point that product implies neither "non-open-source" or "non-free".- They're two different things - COUGAAR is a distributed agent architecture, Jabber is a messaging protocol. I'm not sure a comparison is really in order...
You were able to exchange one for the other, so I do think a comparison is in order; you brought it up. Both include a message routing system.Jabber is more than a messaging protocol, though. It's not a single protocol, but a set of protocols. It encompasses presence, discovery (through directory services), gatewaying, routing, conferencing, remote procedure calls, authentication -- additionally, the XMPP protocol is extensible, so there are no limits, really.
Anyway, as you pointed out, your problem was implementation-related, not necessarily architecture-related; so instead of blatantly generalizing about "Jabber ... being too slow", what you really meant is that one particular Jabber implementation was too slow for your needs.
Sorry if I'm being harsh, but I dislike people throwing out careless, vague comments that give a bad name to other people's work.
- Jabber ended up being too slow, though, so we built a more specialized message router
...
While I understand the intended meaning -- that Jabber was not suitable for your application -- I dislike (1) the implication that Jabber is somehow inherently slow (what was slow? The Jabber4R client library? The Jabber server? Which server? Or the architecture?), and (2) the fact that you are providing no new information, but merely throwing out some vague, critical remark about Jabber of no use to anyone, leading up to a shameless plug for your own unrelated product. What was your point, man?How about doing a design comparison between Cougaar and Jabber?
- I believe Gmail came directly out of somone's "free time" - I'll try to find the article...
You're probably thinking of Orkut.- One drawback with SCSI is that you'll have to deal with a number of different cable/connector formats and terminators.
You seem to be operating under the assumption that there is one interface called SCSI, which is false, and grouping them all under the term "SCSI" when discussing cabling is showing off your ignorance.If your system is a Fast SCSI system and you buy an Ultra2 SCSI hard drive, you have, by definition, incompatible devices, requiring adapter hardware or possibly a new controller. As a consumer, this is like buying a SCART DVD player to connect to your coax RF TV. Or a FireWire video camera to connect to your USB-only PC.
You could argue that this "impedance mismatch" is a problem with the SCSI standard process (why can't they master cable compatibility if the Ethernet guys can?), but this is reality -- SCSI is both a physical and a logical interface, and the physical interface is subject to the requirements/limitations of our physical reality in terms of how electrons can be transported efficiently around. Reality, and by extension hardware, is not malleable in the same sense that software is.
But then, that's why we have adapters.
- No, SCSI is "plug and then realize you hadn't shut down the computer
...
I spy a troll. You actually tried to hot-plug a hard drive, and suffered the consequences. How is this a misfeature of SCSI?Your complaint about cables is equally misguided; it is you who don't have the right equipment. Do you complain in the same way when trying to mount a CD-ROM drive with chassis screws?
Question: How does FreeBSD compare?
As far as I know, Windows derives most of its speed from having display drivers live in kernel space. NVidia's XFree86 driver actually uses a kernel module, so in theory the two architectures should be roughly equal; is XFree86's internal architecture that bad compared to Windows and GDI?
FreeBSD's kernel is, according to its adherents, faster than Linux. Apparently it had an O(1) scheduler long before Linux. How well does XFree86 run on FreeBSD?
- Probably just my lack of experience, but I have a friend who helped me with the install, and he is definitly experienced - but it just was tricky to get it working.
That's not fickle, a word which means, in this context, unstable. You just mean "hard to use".However, SCSI is arguably easier to set up than IDE/ATA. SCSI is "plug and play" (except when you have conflicting IDs), whereas ATA still has the concept of master/slave/single modes, with physical jumper settings to get things right.
The reason SCSI might be more difficult for the end user to set up is that operating system boot disks and installers frequently come with a wide range of ATA controller drivers, but only a handful of SCSI controller drivers.