Apple Mail must be a hell of a lot better than the last time I used desktop-stored mail, then. (Netscape 4 under Solaris 2.5.1 and Outlook Express that shipped with IE4).
We're talking literally half a day per search sometimes.
I'm not buying a mac just to avoid Gmail, either.
That still, of course, presents the classic problem: how to synchronize a 2000MB mailbox across machines. I can burn it to a DVD every day before I leave work, but that seems like a lot of work.
Before GMail, I had that fixed with IMAP. That was when my mailbox was about 1200MB long. My ISP ran something from IPSwitch. Not bad. I could search my mailbox in only 15-20 minutes.
Unfortunately, that means that it can take over an hour to find an email I don't match on the first try.
Oh, and if you think I'm gonna run my mail server, you got another thing comin' bub. That's two hours out of my life that I'd rather save for something else.
FWIW, I prefer Photoshop's way of doing things.. But then again, I'm not really a GUI guy. As long as I can click something that opens a terminal window or a web browser, I'm generally happy.
But I HATE the way Acroread wants to lump all my PDFs together... I swear it worked better 7-8 years ago.
Of course, it also used 1000 times less RAM then as well.
I can't even buy a harddrive that will transfer 2GB/sec. Let alone have the CPU power to perform meaningful searches.
So, if not web mail -- then what? A Java front end that queries a fancy back-end? Well, maybe I suggest, that that is more-or-less what webmail is... just without the Java?
Second paragraph -- good point, AC. I forgot about including air-derived polluting elements and was purely calculating based on the weight and density of gasoline consumed per mile driven.
> especially considering most cars pump out around 1 pound of emissions per mile.
Surely you must mean 1 pound of dirty air. Otherwise, back-of-the-napkin math indicates that most cars use... more than 1/8th of a gallon of gas per mile, and so get less than 8 mpg?... or they violate the first law of thermodynamics.
I see absolutely nothing wrong with that code, other than you have to be a decent programmer to hack on it...and understand many details about TCP implementation.
Which is totally reasonable, considering what it does! It's a not a recipe database, it's a freakin' protocol stack!
Ballmer, in the temple, with the chair, at Tenagra.
The beast at Tenagra.
Stallman, with the hippy hair and the odor at Tenagra.
The Beast and Ballmer and Stallman at Tenagra.
Ballmer in the stomach.
The Beast and Stallman on the Ocean.
Re:The more I learn about JavaScript...
on
GWT in Action
·
· Score: 1
> I think Javascript gets a bad rap because you have to worry about browser compatibility. > But if you ever use it while only targetting a single browser, it's a dream to work with, > and all of the annoyances go away.
I use JavaScript frequently, and have for years. I don't write much for the browser any more, but I often use JavaScript for general purpose projects.
I'm a hardcore C hacker, know enough LISP to write macros for emacs, and I totally agree with your assessment. About the only thing I REALLY don't like is the way it handles inheritance and class hierarchies. I think Smalltalk did a better job there.
I suppose constants and macros would be features worth adding, too... but then, some of the macros I have seen in C make me wish they had never been invented.
But the S-expression-like syntax in JavaScript (var a = {prop: value, prop2: value2}) totally rocks. As do the scoping rules, WITH THE EXCEPTION of it's idiot rule of "oh-its-not-initialized-so-lets-make-it-a-global". I would prefer an error.
Oh, and vian looks neat! Ever thought about writing something like dialog/xdialog/cdialog for the browser? You could use your same screen interface. I think that would be awesome.
Re:The more I learn about JavaScript...
on
GWT in Action
·
· Score: 1
> Rhino compiles down to Java bytecode which is then JITed by the JVM. If you want performance, use Rhino
Now that IS interesting, I wasn't aware of that. Thanks!
ATM, Spidermonkey seems to perform VERY well for my needs. I have used NJS in the past and been satistfied with it (from a speed perspective) as well.
Of course, when I profile my javascript code... only a VERY SMALL amount of time is spent in the JavaScript interpreter. Wall time is mostly consumed doing pesky things like I/O. So I tend to concern myself, first and foremost, with correctness and ease-of-coding. Spidermonkey's guts are a little heady but not really all that bad. Design-type comments would be nice, though.;)
I may change my tune later this month, however, when I try to write multithreaded JavaScript programs.
Have you ever seen C libs embedded in Rhino, maybe built with gcj? I'm no Java guy but I have written enough JNI crap that I could probably cobble together an interface between Rhino and my backend C libs.
Re:The more I learn about JavaScript...
on
GWT in Action
·
· Score: 1
> I'm almost tempted to suggest that someone build a webserver platform around a JavaScript interpreter.
Netscape did that, back in the "four days", google up "server-side javascript".
> Well, almost. The problem with JavaScript is that it's horribly slow to execute.
Bullshit. The types of JOBS people usually try to do with JavaScript may be slow, however. Or the native methods that the javascript programs are using might be... But that's a far cry from making it a slow language. It's not substancially slower or faster than any similar functional or imperitave language I can think of (Pascal, Object-Oriented Turing, Miranda, LISP) for comparable jobs. Although LISP probably kicks its ass if your job is heavily recursive.
> But then, you still have that problem, even if it's JavaScript generated from Java code.
I don't know what you're talking about here. JavaScript is completely unreladed to Java.
That said, there is a JavaScript interpreter written in Java called Rhino. But if you were looking for speed, I would certainly look at a C implementation (like spidermonkey or NJS) first.
I know a certain network operator that had to buy a bunch of cesium clocks when they were upgrading from AMPS to TDMA. This was because the T in TDMA stands for "Time", and the timeslice needs minor monkey business when the phone is far from the tower, because of SOL propagation delay. To do TDMA with a sufficiently small slice to be useful, you need VERY accurate clocks.
And this probably still true today, as GSM is a TDM scheme.
Kind of spooky, though. Blogger.com knows who I am... I don't recall ever creating an account with them. Maybe once, on my laptop, 3 years ago... but not from this machine. I wonder what their authentication is tied to?? Google?
The big difference between a Japanese car plant and a Domestic plant is the attitude of the workers. The Americans are not strict enough with the workers, who are fat and lazy because they do not do morning calesthenics. American workers arrive late, leave early, and stay home when they are sick.
This was never more clearly shown than in 1986 when Assan Motors bought a plant in the United States. Under Japanese management, the plant was able to produce 15,000 cars in a month, which made it the equal of any Japanese plant. All they had to do was work more like the Japanese (i.e. be diligent and cooperative), listen to Mr. Mom, and keep a Gung Ho attitude.
Slashdot Mirror
Right. That's why in Quebec the signs are all printed in landscape mode. Portait mode requires too many hyphens.
> Not bad for Babelfish.
Pretty good, exactly. Sounds just like a Quebecker trying to speak english!
IIRC, iDEN PTT works through the BSS, which is both the very antithesis of a mesh, and an easy entry point for CALEA.
Or am I missing something?
> What's your Blortle number?
69
It's dark enough for him to see the Crab Nebula with the naked eye!
If you are talking to suits and mean *BSD, just pronounce it UNIX.
For all intents and purposes, it is anyhow.
Apple Mail must be a hell of a lot better than the last time I used desktop-stored mail, then. (Netscape 4 under Solaris 2.5.1 and Outlook Express that shipped with IE4).
We're talking literally half a day per search sometimes.
I'm not buying a mac just to avoid Gmail, either.
That still, of course, presents the classic problem: how to synchronize a 2000MB mailbox across machines. I can burn it to a DVD every day before I leave work, but that seems like a lot of work.
Before GMail, I had that fixed with IMAP. That was when my mailbox was about 1200MB long. My ISP ran something from IPSwitch. Not bad. I could search my mailbox in only 15-20 minutes.
Unfortunately, that means that it can take over an hour to find an email I don't match on the first try.
Oh, and if you think I'm gonna run my mail server, you got another thing comin' bub. That's two hours out of my life that I'd rather save for something else.
OH!
Like Photoshop, instead of the Gimp?
FWIW, I prefer Photoshop's way of doing things.. But then again, I'm not really a GUI guy. As long as I can click something that opens a terminal window or a web browser, I'm generally happy.
But I HATE the way Acroread wants to lump all my PDFs together... I swear it worked better 7-8 years ago.
Of course, it also used 1000 times less RAM then as well.
That's nothing. I've used Eudora, never liked it, AND I don't know what MDI is. (Some Windows GUI package I assume?)
I like Gmail.
Why do I like Gmail?
I can search 2GB of email in about a second.
I can't even buy a harddrive that will transfer 2GB/sec. Let alone have the CPU power to perform meaningful searches.
So, if not web mail -- then what? A Java front end that queries a fancy back-end? Well, maybe I suggest, that that is more-or-less what webmail is... just without the Java?
First paragraph -- agreed.
Second paragraph -- good point, AC. I forgot about including air-derived polluting elements and was purely calculating based on the weight and density of gasoline consumed per mile driven.
> especially considering most cars pump out around 1 pound of emissions per mile.
... more than 1/8th of a gallon of gas per mile, and so get less than 8 mpg? ... or they violate the first law of thermodynamics.
Surely you must mean 1 pound of dirty air. Otherwise, back-of-the-napkin math indicates that most cars use
> can you divide by partial zero?
Of course you can. That's the Fundamental Theorem of Calculus.
> I'm not associated with Whole Tomato, but if anyone from WT sees this, can I have a free subscription :-)
Sure thing. You'll need to send me your credit card number for, ah.. age verification.. though.
...I'd give him a raise!
I see absolutely nothing wrong with that code, other than you have to be a decent programmer to hack on it...and understand many details about TCP implementation.
Which is totally reasonable, considering what it does! It's a not a recipe database, it's a freakin' protocol stack!
Ballmer, in the temple, with the chair, at Tenagra.
The beast at Tenagra.
Stallman, with the hippy hair and the odor at Tenagra.
The Beast and Ballmer and Stallman at Tenagra.
Ballmer in the stomach.
The Beast and Stallman on the Ocean.
> I think Javascript gets a bad rap because you have to worry about browser compatibility.
. I would prefer an error.
> But if you ever use it while only targetting a single browser, it's a dream to work with,
> and all of the annoyances go away.
I use JavaScript frequently, and have for years. I don't write much for the browser any more, but I often use JavaScript for general purpose projects.
I'm a hardcore C hacker, know enough LISP to write macros for emacs, and I totally agree with your assessment. About the only thing I REALLY don't like is the way it handles inheritance and class hierarchies. I think Smalltalk did a better job there.
I suppose constants and macros would be features worth adding, too... but then, some of the macros I have seen in C make me wish they had never been invented.
But the S-expression-like syntax in JavaScript (var a = {prop: value, prop2: value2}) totally rocks. As do the scoping rules, WITH THE EXCEPTION of it's idiot rule of "oh-its-not-initialized-so-lets-make-it-a-global"
Oh, and vian looks neat! Ever thought about writing something like dialog/xdialog/cdialog for the browser? You could use your same screen interface. I think that would be awesome.
> Rhino compiles down to Java bytecode which is then JITed by the JVM. If you want performance, use Rhino
;)
Now that IS interesting, I wasn't aware of that. Thanks!
ATM, Spidermonkey seems to perform VERY well for my needs. I have used NJS in the past and been satistfied with it (from a speed perspective) as well.
Of course, when I profile my javascript code... only a VERY SMALL amount of time is spent in the JavaScript interpreter. Wall time is mostly consumed doing pesky things like I/O. So I tend to concern myself, first and foremost, with correctness and ease-of-coding. Spidermonkey's guts are a little heady but not really all that bad. Design-type comments would be nice, though.
I may change my tune later this month, however, when I try to write multithreaded JavaScript programs.
Have you ever seen C libs embedded in Rhino, maybe built with gcj? I'm no Java guy but I have written enough JNI crap that I could probably cobble together an interface between Rhino and my backend C libs.
> I'm almost tempted to suggest that someone build a webserver platform around a JavaScript interpreter.
Netscape did that, back in the "four days", google up "server-side javascript".
> Well, almost. The problem with JavaScript is that it's horribly slow to execute.
Bullshit. The types of JOBS people usually try to do with JavaScript may be slow, however. Or the native methods that the javascript programs are using might be... But that's a far cry from making it a slow language. It's not substancially slower or faster than any similar functional or imperitave language I can think of (Pascal, Object-Oriented Turing, Miranda, LISP) for comparable jobs. Although LISP probably kicks its ass if your job is heavily recursive.
> But then, you still have that problem, even if it's JavaScript generated from Java code.
I don't know what you're talking about here. JavaScript is completely unreladed to Java.
That said, there is a JavaScript interpreter written in Java called Rhino. But if you were looking for speed, I would certainly look at a C implementation (like spidermonkey or NJS) first.
What network is this?
I know a certain network operator that had to buy a bunch of cesium clocks when they were upgrading from AMPS to TDMA. This was because the T in TDMA stands for "Time", and the timeslice needs minor monkey business when the phone is far from the tower, because of SOL propagation delay. To do TDMA with a sufficiently small slice to be useful, you need VERY accurate clocks.
And this probably still true today, as GSM is a TDM scheme.
That's freakin' hilarious.
Kind of spooky, though. Blogger.com knows who I am... I don't recall ever creating an account with them. Maybe once, on my laptop, 3 years ago... but not from this machine. I wonder what their authentication is tied to?? Google?
I'm sorry, but you're wrong.
The big difference between a Japanese car plant and a Domestic plant is the attitude of the workers. The Americans are not strict enough with the workers, who are fat and lazy because they do not do morning calesthenics. American workers arrive late, leave early, and stay home when they are sick.
This was never more clearly shown than in 1986 when Assan Motors bought a plant in the United States. Under Japanese management, the plant was able to produce 15,000 cars in a month, which made it the equal of any Japanese plant. All they had to do was work more like the Japanese (i.e. be diligent and cooperative), listen to Mr. Mom, and keep a Gung Ho attitude.
You know, SCOX already sounds like "suck cocks". I'm not sure they SHOULD change it.
LOL - that was the first thing that cross my mind as well.
That's funny, that's the very first thing that popped into my head when I read TFS.
Of course, I have FAR more experience with MOS Technology than Cisco. I don't know if that's sad or not.
No, spanning tree works independently of the router type.
You only need wood routers if you're serving up pr0n.