Read the post again. Didn't say I used threads to handle network IO.... Non-blocking IO would be a non-issue here - the network is not the bottleneck, and it isn't there that the hundreds of threads operated.
Read the links. Event driven programming isn't about network performance. It's about the fact that thread context-switching (and, if present, lock contention) overhead subtantially degrades a server's performance under heavy load.
I used to write large-scale multithreaded network servers, where somthing like three to four hundred threads could be running at any given moment inside the server. Java's class library made this really quite easy, and it's syntax is pleasant enough to work with.
It's kinda ironic that you should say this, since threads are the wrongway to write "large-scale" network servers, and since Java 1.4 finally gives us non-blocking IO APIs to implement things the right way. (The NBIO APIs in 1.4 are, incidentally, largely a product of the work of the fellow behind the second link I gave.)
What's wrong with the Sun articles? Sun has always done an exceptional job documenting and writing tutorials for the Java API(s) and language. I credit Sun with starting the whole trend of supplying high quality, public documentation with languages and APIs.
Yeah, and this is the case anytime Sun adds any class to an existing package in the API. If you were to disallow this kind of "breakage", then you'd either have a very stagnant API or a whole lotta extraneous packages.
I'm a big fan of Ruby, and a diehard Java devotee.
But I can't forsee Ruby supplanting Java for large projects. The typing is too dynamic, and this ends up being a big headache and source of problems in larger code bases. More concertely, the lack of compile-time type checking makes it hard for Ruby to scale to big projects. You don't find out until runtime if something is type correct, and even then maybe not until some rare execution sequence occurs. Or, worse, it might be type correct in the Ruby sense (i.e., an object can receive a certain message), but not be at all type correct from the programmer's point of view, which might manifest itself in difficult-to-find bugs.
This is a problem with dynamic casting in Java/C++, too, but in those languages the dynamic type checking is the exception rather than the rule (this will get a lot better when Java introduces parametric types in 1.5). More fundamentally, though, at least those languages offer compile-time type checking support, whereas Ruby does not and cannot (since code can be dynamically injected into objects).
To do this by computer means that you have to keep the on-line ballots linked to the person's name until the polls close.
Why? It needn't be linked to the actual name. It could, for instance, be linked to a public key. Or a one-type "revocation" public key that gets issued when you cast your vote. Most likely, though, you wouldn't use vanilla pulic-key crypto for revocation, but some form of zero-knowledge authentication to further obfuscate the identity of the voter: some question would be embedded into the original vote that only the original voter would be able to provide a ZKP for at "revote time."
The other consideration is that with drives unmounted, all swap space is removed from the machine. This shouldn't be difficult in a machine that is handling even large amounts of traffic, given sufficient amounts of memory. However, in an older machine with fewer resources, it is possible to experience performance issues with extremely large amounts of traffic.
Okay, many "most players" was a bit of an exaggeration:)
But you have to admit that the actual price difference for the manufacturer is practically nothing. $100 premium for DivX was marketting, not manufacturing economics.
One real, unsolvable difficulty with both absentee ballots and internet voting is that it becomes impossible to guarantee people are voting in secret.
The best current solution of which I'm aware is allowing subsequent "in person" votes to supercede absentee votes. This is used in practice in many (most?) states.
The retort to this is that the Bad Person can keep the voter under lock-and-key until the election ends, so the voter can't recast her vote. This is possible, but certainly more logistically difficult that just being around when the absentee envelope is sealed/submit button is clicked.
I, for one, wouldn't mind paying $1-2 for a DVD which allows me to watch a movie a couple times until the coating on the disk makes it unreadable. You only have to read it once to rip it.
The biggest problem with DivX was the requirement for specific hardware.
No, I'm sorry, that's bunk. Most early DVD players came with DivX standard (I had one). If DivX had succeeded, all DVD players sold today would support DivX. It costs the hardware manufacturer at most $5 or so to include a modem and a DivX decoder.
A few weeks ago a friend of mine in the Media Lab mentioned to me that the shit was really hitting the proverbial fan because of the missing millions, and that layoffs and cutbacks were a result of this. So, as I understood it, the belt tightening was a direct result of this serious accounting mistake (oops) and not some nebulous result of the dot com slowdown.
They're just looking for the idiots who don't know what a CAL is...
Okay, I'll bite. What's a CAL? Nothing on Acronym Finder or Everything2 yields a clear answer...
FLAC vs. Monkey's
on
Non-MP3 Codecs?
·
· Score: 3, Informative
This one's easy to answer, even if the "moral" open source argument doesn't mean anything to you:
Cross platform. Monkey's Audio runs only on Windows. This is unacceptable to me. While I currently listen to my music on Windows, one day I might not. Plus, one of these days I'm going to write a streaming mp3 server for my Linux fileserver that converts from FLAC to mp3 on the fly. Can't do that with Monkey's.
Longevity. What if you have converted your entire 700 CD music collection to Monkey's Audio, and then the author quits coming out with new versions for new operating systems? Or he starts charging $10/month to use ("subscribe to") his software?
Technically competitive. There isn't that much of a performance difference. Keep in mind that the performance comparison on the Monkey's Audio site uses a very old version of FLAC (0.1, the first version from Dec 2000; FLAC is now on 1.0.2). The compression ratios are rather comparable (or so close as to not matter to me). Yes, Monkey's Audio is faster for the high quality settings, but if you look at the comparison on the FLAC site, you see that FLAC's default compression is pretty competitive in terms of compression ratios and kicks Monkey's ass in terms of speed.
We've been able to copy VHS for over a decade and they're still making movies. Does anyone really think that the movie industry will be eradicated due to copyright infringment?
You are not being objective : VHS copy is lossy, digital copy is not.
I really don't think that's the counterargument you want to make. A digital copy distributed on the Internet will be lossy too (e.g., DivX), because most folks' pipes aren't well-suited to downloading 8+ GB movies. Considering the state of the ISP/broadband industry and current last mile technologies, I think it will be quite some time before lossless movies are traded online. (Current hard drives aren't well-suited to serving a library of 8+ GB movies in the first place, but this will change with time.)
The better counterargument is that I've been able to copy VHS for over a decade (actually, closer to two decades), but I haven't been able to distribute 100,000 VHS copies to friends at essentially no cost. This is the key difference with digital: unlimited reproduction with fixed labor and bandwidth (I don't pay by the byte) costs.
I think the ASP model is thriving and will continue to thrive for applications that demand it, and will be adopted slowly for other applications. The predicted ubiquity of the thin client definitely hasn't come to pass, but you have to acknowledge the ASP successes where the model was a good fit with the application.
eBay is one of the most successful ASPs on the Internet. Sellers seem to have no problem paying a per-auction fee to eBay for hosting the auction application. You can imagine an alternative where everone paid $10 for an eBay application that sat on their Windows desktop and did a P2P search of current auctions by communicting Gnutella-style with the other eBay applications. It would suck. The ASP version kicks its ass any day of the week.
Similarlly, I used to work for a company with an ASP remote access application. To circumvent firewalls that only allow outbound connections, the company routes all connections through their servers; there's no other way to do it if you want to support connections where both endpoints are firewalled. Hence, ASP. It's easy for me to justify paying a monthly fee to use this service because the application demands it. I have to use their servers. (The company includes free support and free upgrades with the subscription fee, too, which makes it rather more attractive than Microsoft's licensing scheme.)
As for ASP MS Office... At this point, my reaction is, "What's the point?" In the absence of ubiquitous thin-client computing, I can't see at all why I'd want to pay for a subscription. There's no value in an ASP model for lots of applications, include most of Microsoft's (with obvious exceptions like Hotmail).
ASPs didn't fail. They just succeeded where it was logical for them to succeed.
Slashdot Mirror
What's wrong with the Sun articles? Sun has always done an exceptional job documenting and writing tutorials for the Java API(s) and language. I credit Sun with starting the whole trend of supplying high quality, public documentation with languages and APIs.
Yeah, and this is the case anytime Sun adds any class to an existing package in the API. If you were to disallow this kind of "breakage", then you'd either have a very stagnant API or a whole lotta extraneous packages.
1.5
But I can't forsee Ruby supplanting Java for large projects. The typing is too dynamic, and this ends up being a big headache and source of problems in larger code bases. More concertely, the lack of compile-time type checking makes it hard for Ruby to scale to big projects. You don't find out until runtime if something is type correct, and even then maybe not until some rare execution sequence occurs. Or, worse, it might be type correct in the Ruby sense (i.e., an object can receive a certain message), but not be at all type correct from the programmer's point of view, which might manifest itself in difficult-to-find bugs.
This is a problem with dynamic casting in Java/C++, too, but in those languages the dynamic type checking is the exception rather than the rule (this will get a lot better when Java introduces parametric types in 1.5). More fundamentally, though, at least those languages offer compile-time type checking support, whereas Ruby does not and cannot (since code can be dynamically injected into objects).
???
But you have to admit that the actual price difference for the manufacturer is practically nothing. $100 premium for DivX was marketting, not manufacturing economics.
The retort to this is that the Bad Person can keep the voter under lock-and-key until the election ends, so the voter can't recast her vote. This is possible, but certainly more logistically difficult that just being around when the absentee envelope is sealed/submit button is clicked.
What the heck is a "password spoofer"?
This was my question, too. I use the Rex 6000, and its touchscreen is a big saving grace in the usability department.
...here.
A few weeks ago a friend of mine in the Media Lab mentioned to me that the shit was really hitting the proverbial fan because of the missing millions, and that layoffs and cutbacks were a result of this. So, as I understood it, the belt tightening was a direct result of this serious accounting mistake (oops) and not some nebulous result of the dot com slowdown.
Hmmm, which fonts?
Right, the point is customers are being warned about it first. So it isn't wholesale slamming.
The better counterargument is that I've been able to copy VHS for over a decade (actually, closer to two decades), but I haven't been able to distribute 100,000 VHS copies to friends at essentially no cost. This is the key difference with digital: unlimited reproduction with fixed labor and bandwidth (I don't pay by the byte) costs.
eBay is still hosting the application, no matter how you interface with it.
eBay is one of the most successful ASPs on the Internet. Sellers seem to have no problem paying a per-auction fee to eBay for hosting the auction application. You can imagine an alternative where everone paid $10 for an eBay application that sat on their Windows desktop and did a P2P search of current auctions by communicting Gnutella-style with the other eBay applications. It would suck. The ASP version kicks its ass any day of the week.
Similarlly, I used to work for a company with an ASP remote access application. To circumvent firewalls that only allow outbound connections, the company routes all connections through their servers; there's no other way to do it if you want to support connections where both endpoints are firewalled. Hence, ASP. It's easy for me to justify paying a monthly fee to use this service because the application demands it. I have to use their servers. (The company includes free support and free upgrades with the subscription fee, too, which makes it rather more attractive than Microsoft's licensing scheme.)
As for ASP MS Office... At this point, my reaction is, "What's the point?" In the absence of ubiquitous thin-client computing, I can't see at all why I'd want to pay for a subscription. There's no value in an ASP model for lots of applications, include most of Microsoft's (with obvious exceptions like Hotmail).
ASPs didn't fail. They just succeeded where it was logical for them to succeed.