Here's something I've been wondering about Parrot for a while. How will extensions work? How can I extend Parrot-based languages with C, either to optimize an algorithm, or to wrap a C library?
In my opinion, Parrot needs to get this right to be useful.
I was actually just watching this movie a second ago. It didn't quite live up to my expectations.
This movie is primarily about geeks geeking out. If you've never been around that, you will probably find the movie more interesting than I did. For example, a good ten minutes were devoted to the interns discussing whether they could jump out their window to the next building in case of a fire. If you are a geek who performs thought experiments with friends/co-workers all the time, you already know what that's like.
This movie is not about sharing insights about how to develop good software. You shouldn't think of the movie as an extension of Joel's column. Opportunities for venturing into that realm are abandoned. For example, all the interns are given a stopwatch and a stack of computer books their first day. Later on, one of the interns admits that he has no idea what the stopwatch is for. Unfortunately, the movie never gives us the answer to that question. I was wondering if it had something to do with user interface design, like quantifying the irritation of having to wait around for software by starting the stopwatch when you see the hourglass. But we never find out.
There is also not much technical content. We get only a few details about the project and its technology.
The biggest disappointment was the camera work. The footage shakes around a lot, especially in shots of computer screens you're trying to read. Far too much of the film is overexposed -- Joel's face is often half-white. This happened throughout the movie, and was visually distracting. This ultimately left the film feeling somewhat amateurish.
For the good: Joel Spolsky and Paul Graham were both engaging as always. They're the kind of guys that manage to make almost every word they say intriguing. The employees and interns are likable people you don't get tired of hearing from. You get a chance to see some interesting decisions, like deciding to pay $10k for "copilot.com" instead of using the inferior name "sidepilot" (though we never hear anyone justify why having the.com is a must -- what's wrong with "copilot.fogcreek.com?")
Learn your history, The US was one of the countries that wanted repairations from Germany for a war they didn't start.
On the contrary, Wilson's primary objective in the negotiations following WWI was to create a lasting peace. The "fourteen points" were designed to achieve this. Here is an excerpt from Wilson's speech Peace Without Victory. It prophetically foreshadows the series of causes and effects that led to the rise of the Nazi party.
Victory would mean peace forced upon the loser, a victor's terms imposed upon the vanquished. It would be accepted in humiliation, under duress, at an intolerable sacrifice, and would leave a sting, a resentment, a bitter memory upon which terms of peace would rest, not permanently but only as upon quicksand. Only a peace between equals can last. Only a peace the very principle of which is equality and a common participation in a common benefit. The right state of mind, the right feeling between nations, is as necessary for a lasting peace as is the just settlement of vexed questions of territory or of racial and national allegiance.
It's true that Wilson had trouble pushing these ideas at home, but I see no evidence that there was support for reparations from the US.
The games and systems are both cheaper, because the cutting-edge gamers have moved on to bigger and better things.
You don't have to suffer through sub-par games, because time has already separated the wheat from the chaff.
There is lots of accumulated knowledge about the game on the Internet, in case you get stuck and would rather have a hint than spend hours of trial-and-error finding what you missed.
As you can probably see, the difference is minute and irrelevant.
The difference is quite significant. In a true man-in-the-middle attack, both parties are following the protocol correctly, and still there is no obvious way to verify that there is no intermediary. That's why they're so insidious. The man-in-the-middle is undetectable (unless you are clever and find a way to observe a byproduct of the attack).
A phishing attack is social engineering, because it involves tricking someone to do something that is inherently incorrect: address their communication improperly.
The kernel is under the BSD license. The inclusion of Reiserfs code in the kernel would require it to be under the GPL license instead.
Including GPL'd code does not forbid you from releasing your code under whatever license you like. You just have to make it available as GPL as well. You could distribute the non-Reiser parts of the kernel as GPL and BSD.
So what you're saying is that you wrote the problem ambiguously, and to resolve ambiguities we ought to choose the interpretation that yields a solution?
Your description of the problem does not say when k is fixed. A perfectly valid reading of the problem is to suppose that the prisoners are told that the king will decide k when the game begins.
You ought to admit that the problem was unclear, instead of insulting everyone who interprets your ambiguity the wrong way.
My post didn't call you any names, and only made light of the fact that you were using tired statements against Java while giving no supporting evidence.
I love the assumption here: that there's some threshold of decency whereby calling you an "idiot" is in a whole different league than more minor insults like "*beep* *beep* *beep* Breaking News Alert."
It's OK. I didn't think you would. I've poked some serious holes in your original, generalized statements.
What are you talking about? You've granted almost all of my original statements. That's why line-by-line would have been so boring. Let's take a trip down memory lane.
(me) Java is perceived as being slow largely because it is so slow to start up...
(you) I readily admit that a well-designed, well-written C/C++ application will usually begin user-level program execution faster than it's cold-started, stand-alone Java counterpart (i.e., when no VM is already running, starting from "cold").
So we agree that Java is slow to start up -- when no VM is already running (and I have never encountered a situation where a new program joins a running VM -- it's just not common use).
Oh, and all those qualifiers ("well-designed", well-written", "usually") is the waffling I'm talking about. Only in a diabolical example will Java beat C or C++ to user code for comparable applications. It's not like it's some special case.
(me)...and largely because it takes up so much memory
(you) I never said that Java didn't require increased memory usage.
So we agree that Java takes up more memory. Your rebuttal was "How much is "so much", hmmm?" The answer is "enough to be a problem, in my experience."
So we couldn't agree about swapping. I would modify that statement a bit anyway. I would surmise that the disk churn associated with Java is a combination of loading the JVM, performing JIT compilation, and sometimes swapping. Who knows exactly, I haven't studied it in depth. I know what I need to know: the disk churn exists, and it makes Java inferior to other solutions for desktop applications.
That's why I brought up the "technology demo" concept. If Java is as awesome as you think it is, some Java fan should write a reasonable Java desktop application that doesn't have disk churn or suck-ass latency. Your arguments about Java ring hollow when Eclipse, the shining star of the Java universe, reinforces nearly all the "specious, unfounded, tired, old statements" you complain about. Its one credit is that is finally uses native widgets instead of Swing.
At least you got this correct. I think that any reasonable, well-informed person would agree that Java is much better today than 5 years ago. I also agree that anyone that doesn't realize this MUST be stuck in the past, as one cannot do an objective comparison of Java now and Java 5 years ago and NOT come up with that conclusion.
Weren't you just complaining about unsubstantiated statements? It's ok, I don't expect you to be consistent. (ooh, I'm not calling you names, am I on the high ground now too?)
Boy oh boy... we're already to the name-calling stage, are we?
Sorry, but you can't pretend to be on the high ground. The only reason I had so much fun ripping into you is because your post was so condescending. There's nothing more amusing that someone who is condescending and wrong, and I have no moral qualms with mocking such behavior.
I'm not really interested in going line-by-line on waffling like "OK, maybe you're right that Java starts up slowly when you actually load the JVM" or "I never said the Java doesn't take more memory." You think my statements are too general? That's because they're the general experience I've had every single time I've ever used Java.
You Java people keep saying "Java's way better now! Anyone who says different is stuck in the past!" Java is no more compelling than it was 5 years ago. It's still a reasonable choice on the server where you have long-running processes on beefy boxes (this is pretty clearly the main use case that the standard JVM was optimized for). It's still not particularly useful for desktop applications.
*beep* *beep* *beep* Breaking News Alert: "This just in:... Benchmarks have been redesigned with ground-breaking new criteria: The 'Snappy-ness factor'. Details at 11:00..."
Umm, it's called latency. You can define that as "the amount of time I wait for Java to notice that I pushed a button in Swing and actually do something about it."
Java is perceived as being slow largely because it is so slow to start up, and largely because it takes up so much memory, which leads to lots of swapping.
The above statement is so generalized that it isn't worth debating. How long must we endure these specious, unfounded, tired, old statements?
Are you really in such denial that you can't even acknowledge that there is truth to these facts?
$ time./hello Hello, world!
real 0m0.041s user 0m0.001s sys 0m0.007s $ time ruby hello.rb Hello, world!
real 0m0.064s user 0m0.011s sys 0m0.010s $ time java Hello Hello, world!
real 0m0.590s user 0m0.225s sys 0m0.137s
That's the sound of your favorite language getting spanked by an interpreted language. The Ruby wasn't even byte-code compiled -- it loaded the interpreter, parsed the source file, executed the entire program, then went to go get a cup of coffee waiting for your pre-compiled class file to reach line 1 of public static void main().
Maybe you think this is some constant overhead that isn't significant in large programs. That's why I brought up the Eclipse example. Its startup time is a joke.
Do you know what a JIT is? It's a compiler that runs at runtime. "Java runs so fast because of JIT" is one side of the coin, "Java starts slow as shit because it loads and runs the compiler at runtime" is the other.
Respectable Java programmers at least acknowledge that the price they pay for the platform-independence of the JVM is increased memory usage and startup time. Idiots like you aren't even aware the tradeoff exists.
Audacity does not work well at 24 bit. It lacks multiple levels of undo
Huh? Audacity supports as much undo as you have space for. I wrote a "History" dialog that lets you jump to any previous state (which happens almost instantly). Here's a screenshot.
Just goes to show that even if you have a great technical product you'll still need the marketdriods.
No, if you've got a great technical product, you need a great technical demo to show it off.
What does Java have to show itself off on the desktop? Eclipse. Eclipse has a bunch of nice features, but its performance is a joke.
If Java is so fast, where are the popular Java desktop applications that feel snappy? Java advocates brag about the JIT, but the cost of a JIT is running the compiler at runtime. Java is perceived as being slow largely because it is so slow to start up, and largely because it takes up so much memory, which leads to lots of swapping.
But the real point of this post is that making speed your only criteria does make you sound like a blind moron. A database is much more than its speed characteristics. Other considerations are: quality of documentation, richness of data types, SQL features supported, options for locking and concurrency, options for writing procedures in the database, facilities for partitioning and controlling the growth of the data store, and much more.
If these are not considerations for you, you are probably working on toy problems that would work just fine with SQLite.
Your criticim of IMAP would be more compelling with specific examples, as opposed to broad strokes like "it's too complex."
Not that I disagree with you, I would just like to see specific examples of where IMAP went wrong. Then readers could judge for themselves whether they agree with your conclusion that IMAP is a bad protocol.
Well, noone stops you from opening and reading 'file/raw/bps', 'file/raw/endianness' etc. As long as we can agree on the common namespace for all audio files, I don't see why it won't work.
OK, but that won't work for the "cat file.mp3/raw >/dev/dsp" case.
The point of my criticism is that raw audio data isn't self-describing, so unlike text, you can't pipe it around without supplying some metadata. IMO a better solution than what you propose is to support an interface like file.mp3/wav, which is raw data, but has a WAV header to tell you how to interpret it.
This would allow application developers to just access file/raw rather than worrying about file types and conversions.
Is that raw data big-endian or little-endian? How many bits per sample? What's the sample rate? How many channels? Interleaved or no?
Will that pseudo-file support seeking? What sort of units will you seek in -- bytes, samples, frames, or seconds?
What if I try to read 3 bytes, but the frame size is 4 bytes? My 3-byte read will never return any data, even though there's data left in the file. Or maybe it will return data, but return only a partial sample.
What I'm getting at is that this stuff is more complicated than you might wish. It would be nice to say "the filesystem understands formats, now I never have to worry about them again!" But there is no canonical way to represent "raw" data -- part of what a format does is explain what that data is!
Also, there's a cost associated with converting between formats -- trying to hide that will only impair the ability of application developers to optimize for their use cases.
Yes, the submitter's jab at Windows XP is somewhat inflammatory and misguided, but so are the comments of all the self-proclaimed RT experts who always seem to come out of the woodwork at the first mention of "real-time."
The RT experts say "multimedia isn't real-time." Multimedia is absolutely real-time. If you miss a deadline for supplying the sound card with an output buffer, you get clicks and dropouts. If you miss a deadline for pulling input buffers, you lose recorded data. No, it won't launch a nuclear missile, but it is clearly a real-time operation.
The RT experts say "but multimedia doesn't need scheduling latencies that low." It's true that single digit usec latencies are beyond what most multimedia systems require, but single-digit msec responses would be extremely welcome. In fact, if you've ever followed JACK (JACK Audio Connection Kit) development, you'll discover a community of people who invest significant effort tuning their kernels and environment exactly so they can get these kinds of latencies. If you're dragging sliders on a mixer while playing back a multi-track recording, you care very much about latency. If you're using your computer as a real-time effects processor, you care very much about latency.
This is why the XP comment, while somewhat inflammatory, has some truth to it: the lower-latency your operating system, the more useful it is for these kinds of tasks. Who cares if it calls itself a "real-time" operating system or not -- what I care about it what's on my desk!
The RT experts say "no fair comparing RT Linux with Windows XP, a non-realtime system." I'm not sure why we take it as a given that this dichotomy must continue to exist. Why do we accept that general purpose operating systems can sit on an interrupt for an unbounded amount of time? If a high-priority interrupt comes in, I want it right now!
Computers are really fast these days, but latencies do not decrease in proportion to CPU speed. What good is my 20GHz Pentium VII if arbitrary drivers still grab locks for tens or hundreds of milliseconds?
Rehashing the same old lines isn't insightful, it's backward-looking. Yes, I know that "real-time is about guaranteed deadlines." But current CPUs are so fast they could probably render a mandelbrot set before they give me the CPU and I wouldn't notice. But as long as they're holding these locks, I'll never see the benefit.
Unlikely. Just because you can, doesn't mean there is any good reason to, and most desktop application developers will have absolutely no reason to bother with threads at all.
I hope you don't write desktop applications. At least not ones that I have to use. It's attitudes like this that make the majority of this generation's UIs so clunky.
The vast majority of desktop apps just sit idle most the time, and even the odd moment when they're busy it's mostly just to do basic things like redraw buttons etc.
Right... they never do things like:
disk i/o
network i/o
CPU-intensive tasks like searching a 100k web page for a string
Most desktop application functionality is inherently synchronous too (driven by user interaction), so I think very few applications will benefit from being multi-threaded.
Consider the incremental search feature in Firefox. I mention it because it's sitting in front of me, and is a prime example of why single-threaded GUI programs suck so bad. Every time I type a letter, it searches the whole web page for the one-character-longer string. If I have a large web page loaded, it takes a really long time, and practically stalls the GUI.
Yes I know that searching the whole document for every letter is the very definition of incremental search. But if the program is 50% through searching this huge HTML page, and I type another character, I want it to immediately stop what it's doing and listen to ME! But it doesn't, and instead I spend a few seconds waiting for my super-powered 2005 computer to perform a search I don't even care about.
All because people like you think that threads provide zero benefit.
You might say "but I can check in my text-processing loop to see if the user cancelled the operation!" Sure, as long as you put these pre-emption points in every single place I might want to pre-empt what you're doing. But the proof is in the pudding: apps just don't do this.
If you don't realize how sluggish GUIs are, you never used BeOS, which had the most responsive GUI I've ever used. And that was in 1999. And (coincidance!) it was heavily multithreaded.
I'm so glad I ignored all of Verizon's "special offers," tempting me to renew my contract that will expire in a month.
If Apple/Motorola do release an iPod phone, and it's good, I'll ditch Verizon in a heartbeat. And I'll send them a letter telling them how much I resent their effort to control what kind of tecnology they'll allow on their network. They want to gouge me for songs the way they gouge you for ringtones. Screw that!
What other communication services will you federate with?
We look forward to federating with any service provider who shares our belief in enabling user choice and open communications. We do believe, however, that it is important to balance openness with ensuring that we maintain a safe and reliable service that protects user privacy and blocks spam and other abuses. We are using the federation opportunity with EarthLink and Sipphone to develop a set of guidelines by which all members of the federated network can work together to ensure that we protect our users while maximizing the reach of the network. We are also eager to hear from other people in the industry about how best to build a federation model that is open, scalable, and ensures best-in-class user experiences.
Doesn't sound like the floodgates are going to be thrown open for s2s communications. Google hand-picks who they will talk to ("federate with", in their words).
Slashdot Mirror
Here's something I've been wondering about Parrot for a while. How will extensions work? How can I extend Parrot-based languages with C, either to optimize an algorithm, or to wrap a C library?
In my opinion, Parrot needs to get this right to be useful.
I was actually just watching this movie a second ago. It didn't quite live up to my expectations.
.com is a must -- what's wrong with "copilot.fogcreek.com?")
This movie is primarily about geeks geeking out. If you've never been around that, you will probably find the movie more interesting than I did. For example, a good ten minutes were devoted to the interns discussing whether they could jump out their window to the next building in case of a fire. If you are a geek who performs thought experiments with friends/co-workers all the time, you already know what that's like.
This movie is not about sharing insights about how to develop good software. You shouldn't think of the movie as an extension of Joel's column. Opportunities for venturing into that realm are abandoned. For example, all the interns are given a stopwatch and a stack of computer books their first day. Later on, one of the interns admits that he has no idea what the stopwatch is for. Unfortunately, the movie never gives us the answer to that question. I was wondering if it had something to do with user interface design, like quantifying the irritation of having to wait around for software by starting the stopwatch when you see the hourglass. But we never find out.
There is also not much technical content. We get only a few details about the project and its technology.
The biggest disappointment was the camera work. The footage shakes around a lot, especially in shots of computer screens you're trying to read. Far too much of the film is overexposed -- Joel's face is often half-white. This happened throughout the movie, and was visually distracting. This ultimately left the film feeling somewhat amateurish.
For the good: Joel Spolsky and Paul Graham were both engaging as always. They're the kind of guys that manage to make almost every word they say intriguing. The employees and interns are likable people you don't get tired of hearing from. You get a chance to see some interesting decisions, like deciding to pay $10k for "copilot.com" instead of using the inferior name "sidepilot" (though we never hear anyone justify why having the
Who said anything about security?
Web servers make assertions about content type with the "content-type" header. Whether you believe the web server is a completely separate question.
What is stupid is expecting your browser to ignore the webserver's assertions in favor of ignorant assumptions about file extensions.
On the contrary, Wilson's primary objective in the negotiations following WWI was to create a lasting peace. The "fourteen points" were designed to achieve this. Here is an excerpt from Wilson's speech Peace Without Victory. It prophetically foreshadows the series of causes and effects that led to the rise of the Nazi party.It's true that Wilson had trouble pushing these ideas at home, but I see no evidence that there was support for reparations from the US.
1995: Unisys does not require licensing, or fees to be paid, for non-commercial, non-profit GIF-based applications
1999: In all cases, a written license agreement or statement signed by an authorized Unisys representative is required from Unisys for all use, sale or distribution of any software (including so-called "freeware") and/or hardware providing LZW conversion capability.
2002: We Have the Way Out: UNIX sucks!
2005: Linux Rulez!
Bingo!
The games and systems are both cheaper, because the cutting-edge gamers have moved on to bigger and better things.
You don't have to suffer through sub-par games, because time has already separated the wheat from the chaff.
There is lots of accumulated knowledge about the game on the Internet, in case you get stuck and would rather have a hint than spend hours of trial-and-error finding what you missed.
As you can probably see, the difference is minute and irrelevant.
The difference is quite significant. In a true man-in-the-middle attack, both parties are following the protocol correctly, and still there is no obvious way to verify that there is no intermediary. That's why they're so insidious. The man-in-the-middle is undetectable (unless you are clever and find a way to observe a byproduct of the attack).
A phishing attack is social engineering, because it involves tricking someone to do something that is inherently incorrect: address their communication improperly.
The kernel is under the BSD license. The inclusion of Reiserfs code in the kernel would require it to be under the GPL license instead.
Including GPL'd code does not forbid you from releasing your code under whatever license you like. You just have to make it available as GPL as well. You could distribute the non-Reiser parts of the kernel as GPL and BSD.
So what you're saying is that you wrote the problem ambiguously, and to resolve ambiguities we ought to choose the interpretation that yields a solution?
Your description of the problem does not say when k is fixed. A perfectly valid reading of the problem is to suppose that the prisoners are told that the king will decide k when the game begins.
You ought to admit that the problem was unclear, instead of insulting everyone who interprets your ambiguity the wrong way.
Mock all you want.
...and largely because it takes up so much memory
Thanks, I'm having fun!
My post didn't call you any names, and only made light of the fact that you were using tired statements against Java while giving no supporting evidence.
I love the assumption here: that there's some threshold of decency whereby calling you an "idiot" is in a whole different league than more minor insults like "*beep* *beep* *beep* Breaking News Alert."
It's OK. I didn't think you would. I've poked some serious holes in your original, generalized statements.
What are you talking about? You've granted almost all of my original statements. That's why line-by-line would have been so boring. Let's take a trip down memory lane.
(me) Java is perceived as being slow largely because it is so slow to start up...
(you) I readily admit that a well-designed, well-written C/C++ application will usually begin user-level program execution faster than it's cold-started, stand-alone Java counterpart (i.e., when no VM is already running, starting from "cold").
So we agree that Java is slow to start up -- when no VM is already running (and I have never encountered a situation where a new program joins a running VM -- it's just not common use).
Oh, and all those qualifiers ("well-designed", well-written", "usually") is the waffling I'm talking about. Only in a diabolical example will Java beat C or C++ to user code for comparable applications. It's not like it's some special case.
(me)
(you) I never said that Java didn't require increased memory usage.
So we agree that Java takes up more memory. Your rebuttal was "How much is "so much", hmmm?" The answer is "enough to be a problem, in my experience."
So we couldn't agree about swapping. I would modify that statement a bit anyway. I would surmise that the disk churn associated with Java is a combination of loading the JVM, performing JIT compilation, and sometimes swapping. Who knows exactly, I haven't studied it in depth. I know what I need to know: the disk churn exists, and it makes Java inferior to other solutions for desktop applications.
That's why I brought up the "technology demo" concept. If Java is as awesome as you think it is, some Java fan should write a reasonable Java desktop application that doesn't have disk churn or suck-ass latency. Your arguments about Java ring hollow when Eclipse, the shining star of the Java universe, reinforces nearly all the "specious, unfounded, tired, old statements" you complain about. Its one credit is that is finally uses native widgets instead of Swing.
At least you got this correct. I think that any reasonable, well-informed person would agree that Java is much better today than 5 years ago. I also agree that anyone that doesn't realize this MUST be stuck in the past, as one cannot do an objective comparison of Java now and Java 5 years ago and NOT come up with that conclusion.
Weren't you just complaining about unsubstantiated statements? It's ok, I don't expect you to be consistent. (ooh, I'm not calling you names, am I on the high ground now too?)
Boy oh boy... we're already to the name-calling stage, are we?
Sorry, but you can't pretend to be on the high ground. The only reason I had so much fun ripping into you is because your post was so condescending. There's nothing more amusing that someone who is condescending and wrong, and I have no moral qualms with mocking such behavior.
I'm not really interested in going line-by-line on waffling like "OK, maybe you're right that Java starts up slowly when you actually load the JVM" or "I never said the Java doesn't take more memory." You think my statements are too general? That's because they're the general experience I've had every single time I've ever used Java.
You Java people keep saying "Java's way better now! Anyone who says different is stuck in the past!" Java is no more compelling than it was 5 years ago. It's still a reasonable choice on the server where you have long-running processes on beefy boxes (this is pretty clearly the main use case that the standard JVM was optimized for). It's still not particularly useful for desktop applications.
"This just in:
Umm, it's called latency. You can define that as "the amount of time I wait for Java to notice that I pushed a button in Swing and actually do something about it."
The above statement is so generalized that it isn't worth debating. How long must we endure these specious, unfounded, tired, old statements?
Are you really in such denial that you can't even acknowledge that there is truth to these facts?
$ time
Hello, world!
real 0m0.041s
user 0m0.001s
sys 0m0.007s
$ time ruby hello.rb
Hello, world!
real 0m0.064s
user 0m0.011s
sys 0m0.010s
$ time java Hello
Hello, world!
real 0m0.590s
user 0m0.225s
sys 0m0.137s
That's the sound of your favorite language getting spanked by an interpreted language. The Ruby wasn't even byte-code compiled -- it loaded the interpreter, parsed the source file, executed the entire program, then went to go get a cup of coffee waiting for your pre-compiled class file to reach line 1 of public static void main().
Maybe you think this is some constant overhead that isn't significant in large programs. That's why I brought up the Eclipse example. Its startup time is a joke.
Do you know what a JIT is? It's a compiler that runs at runtime. "Java runs so fast because of JIT" is one side of the coin, "Java starts slow as shit because it loads and runs the compiler at runtime" is the other.
Respectable Java programmers at least acknowledge that the price they pay for the platform-independence of the JVM is increased memory usage and startup time. Idiots like you aren't even aware the tradeoff exists.
Audacity does not work well at 24 bit. It lacks multiple levels of undo
Huh? Audacity supports as much undo as you have space for. I wrote a "History" dialog that lets you jump to any previous state (which happens almost instantly). Here's a screenshot.
Just goes to show that even if you have a great technical product you'll still need the marketdriods.
No, if you've got a great technical product, you need a great technical demo to show it off.
What does Java have to show itself off on the desktop? Eclipse. Eclipse has a bunch of nice features, but its performance is a joke.
If Java is so fast, where are the popular Java desktop applications that feel snappy? Java advocates brag about the JIT, but the cost of a JIT is running the compiler at runtime. Java is perceived as being slow largely because it is so slow to start up, and largely because it takes up so much memory, which leads to lots of swapping.
If speed is your only criteria about what database is best, you should probably use SQLite. The last time they benchmarked its speed, it was significantly faster than both MySQL and PostgreSQL.
But the real point of this post is that making speed your only criteria does make you sound like a blind moron. A database is much more than its speed characteristics. Other considerations are: quality of documentation, richness of data types, SQL features supported, options for locking and concurrency, options for writing procedures in the database, facilities for partitioning and controlling the growth of the data store, and much more.
If these are not considerations for you, you are probably working on toy problems that would work just fine with SQLite.
Your criticim of IMAP would be more compelling with specific examples, as opposed to broad strokes like "it's too complex."
Not that I disagree with you, I would just like to see specific examples of where IMAP went wrong. Then readers could judge for themselves whether they agree with your conclusion that IMAP is a bad protocol.
Now if only Mozilla Thunderbird used the address book as well...
Well, noone stops you from opening and reading 'file/raw/bps', 'file/raw/endianness' etc. As long as we can agree on the common namespace for all audio files, I don't see why it won't work.
/dev/dsp" case.
OK, but that won't work for the "cat file.mp3/raw >
The point of my criticism is that raw audio data isn't self-describing, so unlike text, you can't pipe it around without supplying some metadata. IMO a better solution than what you propose is to support an interface like file.mp3/wav, which is raw data, but has a WAV header to tell you how to interpret it.
This would allow application developers to just access file/raw rather than worrying about file types and conversions.
Is that raw data big-endian or little-endian? How many bits per sample? What's the sample rate? How many channels? Interleaved or no?
Will that pseudo-file support seeking? What sort of units will you seek in -- bytes, samples, frames, or seconds?
What if I try to read 3 bytes, but the frame size is 4 bytes? My 3-byte read will never return any data, even though there's data left in the file. Or maybe it will return data, but return only a partial sample.
What I'm getting at is that this stuff is more complicated than you might wish. It would be nice to say "the filesystem understands formats, now I never have to worry about them again!" But there is no canonical way to represent "raw" data -- part of what a format does is explain what that data is!
Also, there's a cost associated with converting between formats -- trying to hide that will only impair the ability of application developers to optimize for their use cases.
Yes, the submitter's jab at Windows XP is somewhat inflammatory and misguided, but so are the comments of all the self-proclaimed RT experts who always seem to come out of the woodwork at the first mention of "real-time."
The RT experts say "multimedia isn't real-time." Multimedia is absolutely real-time. If you miss a deadline for supplying the sound card with an output buffer, you get clicks and dropouts. If you miss a deadline for pulling input buffers, you lose recorded data. No, it won't launch a nuclear missile, but it is clearly a real-time operation.
The RT experts say "but multimedia doesn't need scheduling latencies that low." It's true that single digit usec latencies are beyond what most multimedia systems require, but single-digit msec responses would be extremely welcome. In fact, if you've ever followed JACK (JACK Audio Connection Kit) development, you'll discover a community of people who invest significant effort tuning their kernels and environment exactly so they can get these kinds of latencies. If you're dragging sliders on a mixer while playing back a multi-track recording, you care very much about latency. If you're using your computer as a real-time effects processor, you care very much about latency.
This is why the XP comment, while somewhat inflammatory, has some truth to it: the lower-latency your operating system, the more useful it is for these kinds of tasks. Who cares if it calls itself a "real-time" operating system or not -- what I care about it what's on my desk!
The RT experts say "no fair comparing RT Linux with Windows XP, a non-realtime system." I'm not sure why we take it as a given that this dichotomy must continue to exist. Why do we accept that general purpose operating systems can sit on an interrupt for an unbounded amount of time? If a high-priority interrupt comes in, I want it right now!
Computers are really fast these days, but latencies do not decrease in proportion to CPU speed. What good is my 20GHz Pentium VII if arbitrary drivers still grab locks for tens or hundreds of milliseconds?
Rehashing the same old lines isn't insightful, it's backward-looking. Yes, I know that "real-time is about guaranteed deadlines." But current CPUs are so fast they could probably render a mandelbrot set before they give me the CPU and I wouldn't notice. But as long as they're holding these locks, I'll never see the benefit.
I hope you don't write desktop applications. At least not ones that I have to use. It's attitudes like this that make the majority of this generation's UIs so clunky.
The vast majority of desktop apps just sit idle most the time, and even the odd moment when they're busy it's mostly just to do basic things like redraw buttons etc.
Right... they never do things like:
- disk i/o
- network i/o
- CPU-intensive tasks like searching a 100k web page for a string
Most desktop application functionality is inherently synchronous too (driven by user interaction), so I think very few applications will benefit from being multi-threaded.Consider the incremental search feature in Firefox. I mention it because it's sitting in front of me, and is a prime example of why single-threaded GUI programs suck so bad. Every time I type a letter, it searches the whole web page for the one-character-longer string. If I have a large web page loaded, it takes a really long time, and practically stalls the GUI.
Yes I know that searching the whole document for every letter is the very definition of incremental search. But if the program is 50% through searching this huge HTML page, and I type another character, I want it to immediately stop what it's doing and listen to ME! But it doesn't, and instead I spend a few seconds waiting for my super-powered 2005 computer to perform a search I don't even care about.
All because people like you think that threads provide zero benefit.
You might say "but I can check in my text-processing loop to see if the user cancelled the operation!" Sure, as long as you put these pre-emption points in every single place I might want to pre-empt what you're doing. But the proof is in the pudding: apps just don't do this.
If you don't realize how sluggish GUIs are, you never used BeOS, which had the most responsive GUI I've ever used. And that was in 1999. And (coincidance!) it was heavily multithreaded.
If enough customers leave them on account of customer-hostile policy X, they will re-evaluate X out of pure self-interest.
If customers leave them on account of X but don't say so, they have no way of making that connection.
There's nothing to lose (and a lot to gain) by telling a company why you're dissatisfied.
I'm so glad I ignored all of Verizon's "special offers," tempting me to renew my contract that will expire in a month.
If Apple/Motorola do release an iPod phone, and it's good, I'll ditch Verizon in a heartbeat. And I'll send them a letter telling them how much I resent their effort to control what kind of tecnology they'll allow on their network. They want to gouge me for songs the way they gouge you for ringtones. Screw that!