Well since they're aliases I have to wonder what the problem is -- why would you want to keep them around?
Because the process of restoring them is non-trivial. You must search for whatever it is that was lost and restore it.
"Poof" is brilliant, optimized for the average case use. "I don't use IE bye, gone.. POOF".
You're deleting things off your dock that frequently? Does it really save you that much time to not have to drag the icon into the trash, or to right/ctrl+click -> Delete? Deleting icons off the dock is a destructive process and one which is not trivially undone, yet isn't one that I do on a daily basis. Why is there a need for an exceptionally fast means of deleting things off the dock? Perhaps you don't own a cat, but I frequently come back to my iBook to discover that my dock is missing several of its old icons...
For ~$350, you could buy yourself a PlayStation 2 and the Linux kit, and have yourself a slick looking 1TB Linux powered NFS/Samba server. Sure you could build it yourself cheaper, but think of the cool factor!
What does this mean? Using something like TinkerTool (as a convenience interface to writing the preferences) you can anchor it to the left/right edge at the bottom of the screen, so it only grows in one direction...which means applications are always in the same spot, if you anchor it to the left. Is this what you mean by 'lockable'?
No. A "locked" state would prvent accidental removal of dock icons. It would not be possible for ignorant friends using your laptop without your permission/cats/etc to accidently remove icons.
This is a poor idea, IMO. The dock is like a favorites list, not a storage location. Items don't get moved 'into' the dock, they just get pointed to from it. What do you want, items dragged out of the dock to create a new alias on the desktop? Ick.
Oh please, can we have a little less conceptual zealotry?
The reason why this would be an improvement is that, in its current incarnation, it's very easy to accidently carry out an irreversable operation; removing an item from the dock. When this happens there is no quick intuitive undo... the user is forced to hunt down whatever was accidently removed and readd it if they so desire... and this provided they actually saw what they removed by accident and therefore know immediately what needs to be replaced.
Moving the icons onto the desktop would make for a simple undo... it would also provide a sensible counterpart operation to dragging something onto the dock in the first place.
Or, if you're really such a conceptual fanatic, how about simply having icons return to the dock unless they're dragged explicitly into the trash?
The dock is, in its current incarnation, rather counterintuitive, and Tog certainly agrees:
"The Dock adds a whole new behavior: Object annihilation. Drag an object off the dock and it disappears in a virtual puff of smoke. This is the single scariest idea introduced to the Macintosh since the original bomb icon. How would you feel if you spent eight hours working on your first Macintosh document, only to have it disappear entirely when you try to move it from the dock to the desktop? Pretty disorienting, no? This is a completely unnecessary concept for the user to have to learn, particularly in such a painful way. Makes for a 'hot demo' though, doesn't it?"
When icons are dragged off the dock, instead of going *poof* they should be moved to the desktop, unless they are dragged into the trash (and of course, the trash can't be removed)
Neither the official DVD player (provided you've purchased the remote) or the stock DVDX2 (the foremost DVD player for the XBox for the uninitiated) support progressive scan playback of DVDs. There are hacked versions of DVDX2 floating around which do, but unless you've specifically found one of these chances are DVDX2 is using 480i for playback, if you're even using component output.
Also keep in mind that any XBEs you are using which are built with pirated versions of Microsoft's XDK are infringing on their copyright and are technically illegal.
I guess it's really dependent on the feature set. At the 1.6Ghz or 1.8Ghz proc speed, one can get an Opteron/A64 for a hell of a lot cheaper than the same clocked G5.
One important consideration in the G5 versus Opteron comparison is who is standing behind the product. The only tier 1 vendor who has announced Opteron systems is Sun, and those are currently vaporware.
Tier 1 designation (which is done by market analysts, and includes companies like Dell, IBM, HP, Sun, Apple) is especially important for governmental purchases, as national law dictates that unless you stipulate the purchase comes from a tier 1 vendor, in order to prevent fraud the purchase order must be put out for bid, in which case the purchase order will go to the lowest bidder, which is often undesirable as the lowest bidder will typically be disreputable and a terrible pain to deal with.
In the past at my job we have always purchased systems from tier 1 vendors, first IBM and then Sun. Recently we experimented in cost savings by purchaseing a HPC cluster from a vendor found through the bids system, and it has been nothing but a nightmare. We've decided in the future to purchase only from tier 1 vendors because of this experience, and will probably end up building our next cluster from G5s (we are an educational institution and thus receive a very generous educational discount from Apple), especially with the recent release of IBM's XL Fortran compiler for OS X.
I'm sure there are more detailed writeups on the O(1) scheduler in place in 2.6. Does anyone have any links?
http://67.163.90.104/~jim/scheduler.html
Unlike the Ars Technica article which seems to be nothing more than an overview of how schedulers work in general, this article goes into great technical detail about the actual implementation detauls of Linux's O(1) scheduler.
which uses enormous power hungry electromagnets to compress hydrogen to the point at which it fuses. Unfortunately, this means that even if it is actually capable of producing more power than it consumes (like they claim on the web site) it will be monumentally inefficient compared to more modern fusion reactor designs, like the zMachine
A better solution is IP multicasting
on
RSS & BT Together?
·
· Score: 2, Insightful
The problem with attempting to cobble BitTorrent onto an RSS feed system is that BitTorrent would still utilize a "pull" model for distributing the syndication data, but instead of directly fetching the XML document syndicators would grab a.torrent file. While this may decrease the bandwidth used, it only solves half of the problem. What really needs to be addressed is the "pull" model being used to fetch the RSS document in the first place.
A better solution would be eliminating the need for syndicators to constnantly poll waiting for RSS updates by using IP multicasting to notify syndicators of when the content of a particular RSS feed has changed. Multicast protocols which provide such announcements already exist, such as the Session Announcement Protocol which would notify those curious of updated RSS feeds. A URL to the updated feed would be provided, and afterwards whatever file transfer protocol you wish could be used to fetch the RSS feed itself, even BitTorrent.
Re:I'd rather see BitTorrent improved in more...
on
RSS & BT Together?
·
· Score: 2, Informative
I've taken a throw the baby out with the bathwater solution and have implemented BitTorrent-like download swarming with a server that stores a heirarchical filesystem and transfers that are highly server regimented:
The language is, in many places, ambigouous and misleading. The concept of a derived work is not explicitly defined, nor has specific attention been paid to dynamic versus static linking.
No definitive interpretation by a court has been made. This article is completely the interpretation of a single individual and its relevancy to a definitive interpretation within a courtroom setting is dubious at best. There exists Linus's interpretation of this matter, which would preclude the possibility of binary only kernel drivers, but shouldn't this carry over to any code which utilizes system calls in Linux? Wouldn't such code be considered a derived work and be forced to be distributed under the terms of the GPL? Consequently, it doesn't seem possible for glibc to legally be LGPL, as it utilizes the Linux system call table and is consequently a derived work of the GPL'd Linux kernel. This opens up a whole nasty can of worms...
The GPL has many bizarre concessions and terms, such as requiring those who distribute GPL software to distribute it by mail at anyone's request, charging only the cost of media.
...which is some 50 miles north of Boulder. Although there's supposedly a snowstorm coming night, right now there are no clouds in the sky whatsoever. Regardless, at present the beam is not visible, and I have heard the same thing from some Denver residents as well.
Resource collection from the moon or Mars is certainly possible, but it would make considerably more sense to use the materials mined/collected to help subsidize the operations which would be necessary for such mining/resource collection to begin with, such as the recently discussed plans to construct two large photovoltaic arrays on opposite sides of the moon and beam the power back to earth via microwaves.
I do listen to an undisputably independent radio station, Boulder Free Radio, which operates (illegally, of course) without an FCC license.
Re:I listen to my local independent radio station
on
Who Needs Radio?
·
· Score: 2, Insightful
Wow, I was somewhat taken aback to discover this as 99.5 has never mentioned it anywhere, unlike the local Clear Channel stations which always end their station ID by saying "A Clear Channel Station" That's a bit odd...
But regardless, it doesn't diminish the fact that 99.5 is a great station, as can be attested to by monique. In this age of Clear Channel homoginization, it's so nice to see a station stand out and be different, even if they are owned by a "conglomerate".
As for that "conglomerate", as AC pointed out it appears you don't quite have your facts straight either. According to 103.7 The Mountain's web site, Entercom was "a small family-owned Philadelphia company" back in 1990. Their station portfolio contains a couple dozen stations, compared to the hundreds owned by Cumulus and the thousands owned by Clear Channel. Clear Channel is a veritable monopoly at this point, controlling an order of magnitude more radio stations than their nearest competator.
So, I supposed I don't mind corporate controlled radio... as long as it's not UGLY RADIO.
We suspend development of a technology that eliminates the need for SRBs because one of our shuttles was destroyed after attempting reentry because it was damaged by an SRB?
According to this story, in the history of the shuttle program 15 flights have had tile damage due to debris falling off the external fuel tank and SRBs.
NASA's solution? Create a space plane that is entirely reusable, and doesn't require rebuilding/recycling SRBs with each mission and constructing a new external fuel tank.
So when a shuttle is destroyed by a technology known to be problematic, the House Science committee recommends... suspending effort on a project to remedy those problems?
<sarcasm>That makes a lot of sense... really</sarcasm>
I listen to my local independent radio station
on
Who Needs Radio?
·
· Score: 4, Interesting
Clear Channel stations are certainly not worth listening to. I used to think local call-in contests were bad enough, but Clear Channel has made them nationwide. Combine this with their highly censored playlists, their blind dedication to the war in Iraq coupled with sensationalist misreporting (a Clear Channel station here reported four buried vans in the desert as "Vindication for Bush: underground chemical weapons Labs were found today in Iraq") and their propensity for hiring the most moronic, annoying DJs possible, and you have the recipe for a radio station I never want to listen to.
Contrast this with our local independent station, 99.5. They don't have call-in contests, you simply sign up as a "community member" of their station and they randomly give away concert tickets. They play an enormous variety of music, and it's rare to hear the same song played more than once in a single month. They have knowledgable DJs who discuss things you never knew about the music they play in a calm, conversational manner so it's pleasant to listen to.
I conclude by saying, in the words of Frank Zappa, "KILL UGLY RADIO"
kqueue() is available on the production quality 4.x branch of FreeBSD, whereas epoll() is only available on the 2.6 development branch of Linux and also requires a 2.3 glibc compiled specifically with support for epoll(). The glibc currently in Debian unstable, for example, still doesn't support epoll.
The SIGIO comparison is somewhat fair, but keep in mind that implementing a program with SIGIO requires multiplexing I/O asynchronously, which radically alters program design. Linux 2.4 lacks a synchronous, stateful interface for I/O mulitplexing. Programs that implement synchronous I/O multiplexing can easily transition to a library for their main loop to immediately take advantage of high performance multiplexing/events mechanisms. One such library is libevent.
Anyone remember the previous IT Week article comparing Samba 2.x to Windows 2000, making just as outrageous claims and still no numbers to back it up after over a year?
There is a scant amount of information on the actual tests performed in this article.
Is this a joke? You can (and we do) easily buy five Intel dual-processor 3Mhz, 2GB RAM machines for $25K -- with three year support contracts (hint: www.dell.com). Are you actually saying that this single box will outperform those five Intel servers?
If the task is easily parallelized, such as a modelling program or other scientific computing tasks, or if the systems are serving as web or application servers for a web site, then yes, by all means buy x86.
However, for the backend database the only purpose of more machines is redundancy. Operations which modify the database will see negligable performance increases from one system alone due to the high cost of replication. Furthermore, keep in mind the increased level of optimization of DBMS like Oracle 9i on Solaris/SPARC vs. Oracle 9i on Linux/IA32 (Oracle 9i for Linux/AMD64 is still only a developer preview) So yes, when I talk price/performance of the V440 I am talking for a single system...
I configured a Dell PowerEdge 6600 with 4 * 2.0GHz Xeons, 16GB RAM (16X1GB, the cheapest option) and 4 * Ultra320 36GB drives, and included Red Hat Advanced Server (~$500). The total system cost was over $30,000. But feel free to try to get the cost of a single system comparable to the V440 under $26,000.
'Automatically updated' is a fundamentally flawed security hole in itself.
Obviously the filter rules would be cryptographically signed, so crafting malicious ones would require that you compromise Microsoft's physical security and obtain their private DSA key, or that you compromise the DSA itself. Neither of these are particularly realistic possibilities...
"However, don't ever claim that Sun's kernel is in general superior to Linux. In a lot of ways Sun's kernel is ancient and crappy compared to Linux."
I believe the word you're looking for is mature, and immature on the Linux side. Take Linux's VM implementation, which has been scrapped and rewritten from scratch multiple times within 2.4 alone. Meanwhile the Solaris VM has been fine tuned over the past decade. Solaris's time share scheduler has been O(1) for well over half a decade, whereas Linux is just now getting an O(1) time share scheduler.
"Take a look at Sun's IP stack versus Linux's, for instance."
Care to tell me how Linux is superior? You seem to be only assuming it is, and leaving the burden of proof upon me. Sorry, I put it back on you.
But just for review of some networking features: Solaris has offered stateful I/O multiplexing through the/dev/poll mechanism as well as asynchronous I/O for years. These features are only now being implemented in Linux with things like epoll(), which you'll need a 2.6 kernel and userland support in glibc to use. It will be at least a year before we can begin to expect the average Linux system to support stateful I/O multiplexing through epoll().
Or how about lvm+softraid? When will Solaris stop relying on Veritas? (and don't answer diskuite, please).
Don't answer Solstice Disk Suite? Perhaps you forget that the LVM was modeled after the Sun Volume Manager (which later became SDS) Perhaps you'd have an argument if you were championing FreeBSD's vinum, which was modeled after the Veritas Volume Manager, however you're trying to champion a technology which mimics the Solaris implementation yet saying to discount that very implementation. Pathetic...
"Or how about good integrated netfilter-like code?"
Sorry, people aren't going to be using their $20,000 systems as routers for their cable modems.
"While we're on it, let's talk hardware. The price/performance ratios on UltraSparcs make Xeons look like a super bargain, not to mention Athlons.
Keep in mind that no one in their right mind is going to shell out $26,000 for a system without a warranty. The V440 comes with 3 years of parts and on-site labor.
I'd certainly like to see you configure an equivalent system (the 1.28GHz UltraSPARC IIIi is equivalent to a 1.8GHz Opteron) from a vendor that offers at least a year of parts and on-site labor.
"It's way past late for them to have closed up the Sparc shop and moved everything over to this cheaper commodity platform that can pump more mips or flops per dollar than Sun can. And how freaking long did it take them to adopt PCI?"
The earliest Sparc systems I know of supporting PCI were Ultra 5s, released in 1995, about the same time most PC systems were starting to feature PCI.
"Of course, now most of my Suns have 64/66 PCI busses, while my latest Intels are doing PCI-X..."
Unless you're talking about the Opteron, the scalability and throughput of x86 systems is severely limited by the interconnect used between CPUs. P4 Xeons essentially share the FSB between processors, greatly limiting the amount of bus bandwidth that can be simultaneously utilized by multiple processors. With the P4, keep in mind also that the P4 does not cache operations, only micro-ops in its trace cache, so whenever the trace cache becomes tainted (by, say, mispredicing a branch) the P4 must fall back on retrieving the original opcodes out of main memory, saturating the front side bus (this is why Intel has been aggressively stepping up the bus speed of the P4)
For use as a high performance server, Linux does not rival Solaris in
Automatically updated distributed netfilter rules allows systems to automatically block exploitation attempts without requiring any user intervention or a reboot. While this is only a stopgap measure until patches can actually be applied, it virtually eliminates the exploitability of input validation vulnerabilities as soon as they are discovered.
Hats off to Microsoft for being the first to truly promote this approach. Let's hope we see others like Sun step up and attempt to do the same.
is a scheduler on the same caliber as Solaris, so that the kernel can utilize multiple schedulers simultaneously. Linux currently ships with only a timeshare scheduler, but Solaris supports a number of different schedulers which can all operate simultaneously. Administrators can also move processes between different schedulers on the fly as well. A Fair Share Scheduler, for example, would be nice so that resources on large systems can be partitioned effectively as to prevent certain processes from monopolizing system resources.
The CPU/RAM hotplug support would be nice... glad to see Linux trying to catch up to where Solaris was years ago. Just kidding:)
Slashdot Mirror
Because the process of restoring them is non-trivial. You must search for whatever it is that was lost and restore it.
You're deleting things off your dock that frequently? Does it really save you that much time to not have to drag the icon into the trash, or to right/ctrl+click -> Delete? Deleting icons off the dock is a destructive process and one which is not trivially undone, yet isn't one that I do on a daily basis. Why is there a need for an exceptionally fast means of deleting things off the dock? Perhaps you don't own a cat, but I frequently come back to my iBook to discover that my dock is missing several of its old icons...
For ~$350, you could buy yourself a PlayStation 2 and the Linux kit, and have yourself a slick looking 1TB Linux powered NFS/Samba server. Sure you could build it yourself cheaper, but think of the cool factor!
No. A "locked" state would prvent accidental removal of dock icons. It would not be possible for ignorant friends using your laptop without your permission/cats/etc to accidently remove icons.
Oh please, can we have a little less conceptual zealotry?
The reason why this would be an improvement is that, in its current incarnation, it's very easy to accidently carry out an irreversable operation; removing an item from the dock. When this happens there is no quick intuitive undo... the user is forced to hunt down whatever was accidently removed and readd it if they so desire... and this provided they actually saw what they removed by accident and therefore know immediately what needs to be replaced.
Moving the icons onto the desktop would make for a simple undo... it would also provide a sensible counterpart operation to dragging something onto the dock in the first place.
Or, if you're really such a conceptual fanatic, how about simply having icons return to the dock unless they're dragged explicitly into the trash?
The dock is, in its current incarnation, rather counterintuitive, and Tog certainly agrees:
Neither the official DVD player (provided you've purchased the remote) or the stock DVDX2 (the foremost DVD player for the XBox for the uninitiated) support progressive scan playback of DVDs. There are hacked versions of DVDX2 floating around which do, but unless you've specifically found one of these chances are DVDX2 is using 480i for playback, if you're even using component output.
Also keep in mind that any XBEs you are using which are built with pirated versions of Microsoft's XDK are infringing on their copyright and are technically illegal.
One important consideration in the G5 versus Opteron comparison is who is standing behind the product. The only tier 1 vendor who has announced Opteron systems is Sun, and those are currently vaporware.
Tier 1 designation (which is done by market analysts, and includes companies like Dell, IBM, HP, Sun, Apple) is especially important for governmental purchases, as national law dictates that unless you stipulate the purchase comes from a tier 1 vendor, in order to prevent fraud the purchase order must be put out for bid, in which case the purchase order will go to the lowest bidder, which is often undesirable as the lowest bidder will typically be disreputable and a terrible pain to deal with.
In the past at my job we have always purchased systems from tier 1 vendors, first IBM and then Sun. Recently we experimented in cost savings by purchaseing a HPC cluster from a vendor found through the bids system, and it has been nothing but a nightmare. We've decided in the future to purchase only from tier 1 vendors because of this experience, and will probably end up building our next cluster from G5s (we are an educational institution and thus receive a very generous educational discount from Apple), especially with the recent release of IBM's XL Fortran compiler for OS X.
I'm sure there are more detailed writeups on the O(1) scheduler in place in 2.6. Does anyone have any links? http://67.163.90.104/~jim/scheduler.html Unlike the Ars Technica article which seems to be nothing more than an overview of how schedulers work in general, this article goes into great technical detail about the actual implementation detauls of Linux's O(1) scheduler.
which uses enormous power hungry electromagnets to compress hydrogen to the point at which it fuses. Unfortunately, this means that even if it is actually capable of producing more power than it consumes (like they claim on the web site) it will be monumentally inefficient compared to more modern fusion reactor designs, like the zMachine
A better solution would be eliminating the need for syndicators to constnantly poll waiting for RSS updates by using IP multicasting to notify syndicators of when the content of a particular RSS feed has changed. Multicast protocols which provide such announcements already exist, such as the Session Announcement Protocol which would notify those curious of updated RSS feeds. A URL to the updated feed would be provided, and afterwards whatever file transfer protocol you wish could be used to fetch the RSS feed itself, even BitTorrent.
http://pdtp.org/
...which is some 50 miles north of Boulder. Although there's supposedly a snowstorm coming night, right now there are no clouds in the sky whatsoever. Regardless, at present the beam is not visible, and I have heard the same thing from some Denver residents as well.
Resource collection from the moon or Mars is certainly possible, but it would make considerably more sense to use the materials mined/collected to help subsidize the operations which would be necessary for such mining/resource collection to begin with, such as the recently discussed plans to construct two large photovoltaic arrays on opposite sides of the moon and beam the power back to earth via microwaves.
I do listen to an undisputably independent radio station, Boulder Free Radio, which operates (illegally, of course) without an FCC license.
But regardless, it doesn't diminish the fact that 99.5 is a great station, as can be attested to by monique. In this age of Clear Channel homoginization, it's so nice to see a station stand out and be different, even if they are owned by a "conglomerate".
As for that "conglomerate", as AC pointed out it appears you don't quite have your facts straight either. According to 103.7 The Mountain's web site, Entercom was "a small family-owned Philadelphia company" back in 1990. Their station portfolio contains a couple dozen stations, compared to the hundreds owned by Cumulus and the thousands owned by Clear Channel. Clear Channel is a veritable monopoly at this point, controlling an order of magnitude more radio stations than their nearest competator.
So, I supposed I don't mind corporate controlled radio... as long as it's not UGLY RADIO.
According to this story, in the history of the shuttle program 15 flights have had tile damage due to debris falling off the external fuel tank and SRBs.
NASA's solution? Create a space plane that is entirely reusable, and doesn't require rebuilding/recycling SRBs with each mission and constructing a new external fuel tank.
So when a shuttle is destroyed by a technology known to be problematic, the House Science committee recommends... suspending effort on a project to remedy those problems?
<sarcasm>That makes a lot of sense... really</sarcasm>
Clear Channel stations are certainly not worth listening to. I used to think local call-in contests were bad enough, but Clear Channel has made them nationwide. Combine this with their highly censored playlists, their blind dedication to the war in Iraq coupled with sensationalist misreporting (a Clear Channel station here reported four buried vans in the desert as "Vindication for Bush: underground chemical weapons Labs were found today in Iraq") and their propensity for hiring the most moronic, annoying DJs possible, and you have the recipe for a radio station I never want to listen to. Contrast this with our local independent station, 99.5. They don't have call-in contests, you simply sign up as a "community member" of their station and they randomly give away concert tickets. They play an enormous variety of music, and it's rare to hear the same song played more than once in a single month. They have knowledgable DJs who discuss things you never knew about the music they play in a calm, conversational manner so it's pleasant to listen to. I conclude by saying, in the words of Frank Zappa, "KILL UGLY RADIO"
"best price performance" and "Apple" in their minds?
The SIGIO comparison is somewhat fair, but keep in mind that implementing a program with SIGIO requires multiplexing I/O asynchronously, which radically alters program design. Linux 2.4 lacks a synchronous, stateful interface for I/O mulitplexing. Programs that implement synchronous I/O multiplexing can easily transition to a library for their main loop to immediately take advantage of high performance multiplexing/events mechanisms. One such library is libevent.
There is a scant amount of information on the actual tests performed in this article.
If the task is easily parallelized, such as a modelling program or other scientific computing tasks, or if the systems are serving as web or application servers for a web site, then yes, by all means buy x86.
However, for the backend database the only purpose of more machines is redundancy. Operations which modify the database will see negligable performance increases from one system alone due to the high cost of replication. Furthermore, keep in mind the increased level of optimization of DBMS like Oracle 9i on Solaris/SPARC vs. Oracle 9i on Linux/IA32 (Oracle 9i for Linux/AMD64 is still only a developer preview) So yes, when I talk price/performance of the V440 I am talking for a single system...
I configured a Dell PowerEdge 6600 with 4 * 2.0GHz Xeons, 16GB RAM (16X1GB, the cheapest option) and 4 * Ultra320 36GB drives, and included Red Hat Advanced Server (~$500). The total system cost was over $30,000. But feel free to try to get the cost of a single system comparable to the V440 under $26,000.
Sorry, Dell is the wrong answer!
Obviously the filter rules would be cryptographically signed, so crafting malicious ones would require that you compromise Microsoft's physical security and obtain their private DSA key, or that you compromise the DSA itself. Neither of these are particularly realistic possibilities...
I believe the word you're looking for is mature, and immature on the Linux side. Take Linux's VM implementation, which has been scrapped and rewritten from scratch multiple times within 2.4 alone. Meanwhile the Solaris VM has been fine tuned over the past decade. Solaris's time share scheduler has been O(1) for well over half a decade, whereas Linux is just now getting an O(1) time share scheduler.
"Take a look at Sun's IP stack versus Linux's, for instance."
Care to tell me how Linux is superior? You seem to be only assuming it is, and leaving the burden of proof upon me. Sorry, I put it back on you.
But just for review of some networking features: Solaris has offered stateful I/O multiplexing through the /dev/poll mechanism as well as asynchronous I/O for years. These features are only now being implemented in Linux with things like epoll(), which you'll need a 2.6 kernel and userland support in glibc to use. It will be at least a year before we can begin to expect the average Linux system to support stateful I/O multiplexing through epoll().
Or how about lvm+softraid? When will Solaris stop relying on Veritas? (and don't answer diskuite, please).
Don't answer Solstice Disk Suite? Perhaps you forget that the LVM was modeled after the Sun Volume Manager (which later became SDS) Perhaps you'd have an argument if you were championing FreeBSD's vinum, which was modeled after the Veritas Volume Manager, however you're trying to champion a technology which mimics the Solaris implementation yet saying to discount that very implementation. Pathetic...
"Or how about good integrated netfilter-like code?"
Sorry, people aren't going to be using their $20,000 systems as routers for their cable modems.
"While we're on it, let's talk hardware. The price /performance ratios on UltraSparcs make Xeons look like a super bargain, not to mention Athlons.
Please show me a system with better price/performance than the V440: http://store.sun.com/catalog/doc/BrowsePage.jhtml? cid=104994&parentId=48589
Keep in mind that no one in their right mind is going to shell out $26,000 for a system without a warranty. The V440 comes with 3 years of parts and on-site labor.
I'd certainly like to see you configure an equivalent system (the 1.28GHz UltraSPARC IIIi is equivalent to a 1.8GHz Opteron) from a vendor that offers at least a year of parts and on-site labor.
"It's way past late for them to have closed up the Sparc shop and moved everything over to this cheaper commodity platform that can pump more mips or flops per dollar than Sun can. And how freaking long did it take them to adopt PCI?"
The earliest Sparc systems I know of supporting PCI were Ultra 5s, released in 1995, about the same time most PC systems were starting to feature PCI.
"Of course, now most of my Suns have 64/66 PCI busses, while my latest Intels are doing PCI-X..."
Unless you're talking about the Opteron, the scalability and throughput of x86 systems is severely limited by the interconnect used between CPUs. P4 Xeons essentially share the FSB between processors, greatly limiting the amount of bus bandwidth that can be simultaneously utilized by multiple processors. With the P4, keep in mind also that the P4 does not cache operations, only micro-ops in its trace cache, so whenever the trace cache becomes tainted (by, say, mispredicing a branch) the P4 must fall back on retrieving the original opcodes out of main memory, saturating the front side bus (this is why Intel has been aggressively stepping up the bus speed of the P4)
For use as a high performance server, Linux does not rival Solaris in
Automatically updated distributed netfilter rules allows systems to automatically block exploitation attempts without requiring any user intervention or a reboot. While this is only a stopgap measure until patches can actually be applied, it virtually eliminates the exploitability of input validation vulnerabilities as soon as they are discovered. Hats off to Microsoft for being the first to truly promote this approach. Let's hope we see others like Sun step up and attempt to do the same.
is a scheduler on the same caliber as Solaris, so that the kernel can utilize multiple schedulers simultaneously. Linux currently ships with only a timeshare scheduler, but Solaris supports a number of different schedulers which can all operate simultaneously. Administrators can also move processes between different schedulers on the fly as well. A Fair Share Scheduler, for example, would be nice so that resources on large systems can be partitioned effectively as to prevent certain processes from monopolizing system resources. The CPU/RAM hotplug support would be nice... glad to see Linux trying to catch up to where Solaris was years ago. Just kidding :)