Following is the email I just sent to Public Information Research, the guys that do GoogleWatch. I'll post the reply if I get one.
Hi,
I just came across the page and had a few comments to make and questions to ask.
"1. Google's immortal cookie"
Given that all browsers allow you some control over accepting cookies, and the better ones give you more fine-grained control, allowing you to reject cookies from specific domains. I would say this is a moot point.
"2. Google records everything they can: For all searches they record the cookie ID, your Internet IP address, the time and date, your search terms, and your browser configuration."
Well, the cookie tracking can be resolved as above. It's interesting to note that they don't record my IP address - at work they get my proxy's address, at home they get the addresses of the transparent caches that my ISP uses. I'd say that as transparent caches become more prevalent, that becomes less of an issue. More on this later. Browser configuration? How do they get that (apart from the easily-spoofable UA string)?
I'd also suggest that your ISP does all this as well, especially if you use their proxy, or if they use transparent caches. This is far worse becuase they will be reording *everything* you do on the web. I'd suggest this is a bigger problem right now.
"3. Google retains all data indefinitely"
Can you prove that? If true, it does suck, but they're probably well within their rights to do so. AFAIK, the US doesn't have the more-enlightened privacy laws that the EU and other countries do.
"4. Google won't say why they need this data"
Is that suprising? What do other US companies say when you ask them similar questions?
"5. Google hires spooks"
I'm sure lots of companies hire ex-NSA engineers. Perhaps they hired him because he is a competent engineer? I hope you realise that this point makes you sound like someone with a paranoia disorder of some sort.
"6. Google's toolbar is spyware"
Don't install it then?
"7. Google's cache copy is illegal"
If you don't want something cached, don't publish it on the Internet. Print publishers can't recall magazines and newspapers, why do you expect anything different on the 'Net? If it is illegal, it's probably because the US copyright laws are seriously broken. It *would be good if Google abided by the HTTP cache control headers, rather than resorting to stupid HTML meta hacks.
"8. Google is not your friend: Young, stupid script kiddies and many bloggers still think Google is "way kool,"
Thanks for the insult. You're an arrogant, paranoid, stupid, wanker. I use Google because it gets me results for random questions. I don't use Google to find a place to buy CDs online. The people out there trying to scam Google probably aren't the kind of people I want to deal with.
"9. Google is a privacy time bomb"
I'd suggest the current US administration is a much bigger, more dangerous, more volatile bomb than Google is or ever will be. If Google is a nasty monkey, the Federal US Government is a 900-pound gorilla.
I think what you find is that "leverage" is supposed to be more like "use to gain additional benefit". It is what happens when you use something, and get a bonus on top.
A good example is: "use contraception when having sex". You could quite validly say "leverage contraception when having sex". Not only do you get a good bonk, but you don't produce any more babies.
While I never normally advocate the use of Perl for anything, I've had to do what you're looking for before, and I found the easiest way was to whip up a quick Perl script using libmail-imapclient-perl or libcyrus-imap-perl which recursively sucks your mail off the server.
The advantages of doing this is that you can then save it into any format you want. I personally was using it to do a IMAP server to server copy, and it worked fantastically.
If I still had the script, I'd post it, but it was many, many harddrives ago that I saw it last.:(
Yeah, okay, you got me there. I guess I really do suck.
What confuses me is why the postser asks "Is there something like a Mozilla Administration Kit" and then goes on to answer {his|her} own question. Turkey.
I used to play around with the CCK for 4.x when it first came out and I found I could remove the the proprietary crap easily enough. I'd also be suprised if you couldn't substitute Moz in instead of NS7 with the current CCK.
How about the mozilla.org CCK? Or if it isn't sufficiently advanced, use Netscape's CCK instead.
The CCKs exist to do exactly what you want - customize the browser. Why reinvent the wheel?
This is where some basic research could have helped you before posting yet another lame Ask Slashdot question. I find Google works well for that sort of thing. Perhaps you could also start at Mozilla.org's project pages. RTFM, etc, etc, etc./mike
It depends on the thread abstractions that are used for synchronisation and thread communication. The most commonly used abstractions today (semaphores, locks, etc) date from the 1970s; there are much better ways to do it!
Well, the links you supplied do look interesting, and I've added them to my reading list, but the blocker for using more advanced thread syncing and comms is that they're not really usable in applications today.
When I'm designing software, I need to use technology that is available, proven and that the guys on my team understand, so unfortunately that counts most of the better solutions out (perhaps only for the time being). Also, you need to remember that we're talking about writing X client applications here, and so the better abstractions just aren't available anyway.
CSP seems interesting. It sounds kinda like the idea behind Java's PipedXXX streams and reader/writers. Have you got any references to other tools that support it? The two links that I found were both dead.:(
Concurrency at this level in a GUI application can greatly enhance the simplicity and maintainability of a program. This is because it's generally much easier to write a straightforward piece of imperative code than encode the same thing as a state machine, e.g.
[snip: a multi-threaded while loop and a single-threaded callback]
The callback *is* uglier, but your first example using the loop isn't terribly different from:
I'd say the suckiness of using a single thread (and hence of using callbacks) depends on the suckines of the toolkit you're using. If it has been designed properly, you'll get decent callbacks to use.
I'd also argue the callback above more clearly expresses the intention of the author than using a while loop. I think that is a huge boon to understandability and hence maintainability.
But it is! Yes, the user themselves only contributes one thread to the activity, but the program itself is often dealing with multiple activities at the same time; for instance updating itself in response to network activities or updating graphics on a time-step basis.
Okay, I was thinking more along the lines of user activity, rather than interaction. When the application is updating itself (on another thread) it isn't too hard a task to schedule a update on the GUI thread.
The most important thing it gives you, in my experience, is the sense of control.
[snip] In a callback system, you are at the mercy of the caller; you can't just wait for an event, then do the next thing, you have to encode your current state, return, and wait to be called back, whereupon you have to figure out where you just were!
I think that kind of situation is easily avoided by using seperate, non-gui, worker thread(s) to perform non-gui operations. You use the gui thread only for handling user interaction - both user events and updating the display.
The gui thread responds to user events by notifing the worker thread of anything significant. It acts as a translation layer between the user and the workers. For example, if a user selects File > Open, the gui thread prompts the user to select a file, then messages a worker thread to open the selected file. This is a powerful way of doing it because the worker thread can go off and load the file, and the gui stays responsive to further user input. It also keeps the application's code base clean, easy to understand and maintain because there is a clear separation between the gui code and the code that does the real work - the workers.
When the application needs to update the gui as a result of some change, the worker thread just queues a update event and the gui thread goes and performs the update. The gui thread obtains the state or data for the update from shared data sources. The gui thread reads the data, the workers update it.
You're still free to (mostly) structure your app how you want because the most important parts, the worker threads, are decoupled from the gui. You're also free to easily vary the gui (for example, use a different toolkit) without needing to change the whole app.
First, you should restrict such broad generalizations to an X client in order to be even remotely correct.
Ah, I thought that was exactly what I implied. I was talking about the application, which is an X client. Of course the server needs to be thread and process safe - it does display multiple applications at once.
Wrong.
You're telling me multi-threaded apps and libraries are not harder to write, debug and maintain than single-threaded ones? Sorry: *you're* wrong. Even if you use a language which is designed with threading in mind (which X isn't), it adds a *lot* of complexity.
Also, having a single GUI thread is a good design pattern.
Um, add the hedge for some applications and I'll agree with you. Otherwise you're wedged in a one-track design mind.
Hey, I said it is a good design pattern. I didn't say it is a golden hammer. Of course you only apply a pattern when it fits.
You're making your problem fit your design, rather than your design fit your problem. There's any number of interactive applications that make lots of logical sense to be multi-threaded.
No, I'm not. Nor am I saying that applications should be single threaded. What gave you that idea?
There's no reason why an application needs to have a multi-threaded GUI. This is not to say that the application should not be multi-threaded, clearly that can very useful. The reason is because user interaction effectively serialized. A user rarely, if ever, provides multiple sources of input simultaneously. In cases when they do, it's usually supplementary to the interaction already occuring - a modifier. So there is rarely any need to process user input and update the display in multiple threads because there is only one thing going on at a time.
Go read papers on the "eXene" system in the programming language "ML". A pervasively multi-threaded X client library. One widget - one thread. It makes the widget code very easy to understand - you don't have to split your code into a bazillion little callbacks.
Damm, that sounds truely awful. What about user events that traverse mutliple widgets? How do you synchronise them all? What about the scheduling overhead when someone just drags a mouse over the app's UI and fifty threads are woken up almost simultaneously? Most workstations are still uniprocessor based.
And I don't see how that avoids the bazillion little callbacks issue. You're splitting your code up into bazillion little threads instead. In any case, the callbacks aren't an issue of you've designed and written your code properly.
Ever have to break up a callback into multiple functions, triggered by timers, just so the app didn't appear to "freeze" while you were off doing something time-intensive?
No, I just use a non-GUI thread to do the intensive work, so that the GUI thread is free to play with the user.
Multi-threading interaction can make the code much easier to maintain because you don't have to worry about "starving" parts of the application for events while busy working on others - the thread scheduler handles pre-emption for you.
Yeah, you "just" need to worry about synchronization, deadlocking, and other concurreny issues instead. Muuuuuuch easier. But what you said above made no sense to me (perhaps I need more coffee) - can you explain this in more detail?
Forcing discretizations of continuous phenomena into an arbitrary serialization is just a way to kludge around a poor understanding of parallel activity.
That would be the case if user interaction was a parallel activity, but unfortunately it is not.
It isn't the app - it's the libraries the app is trying to use. They're a poor fit to the abstraction blackcoot would like to use.
Ah, so you obviously know more about the app than I do, because I don't see any evidence in the article to support that statement.
Yeah, I think having a single GUI thread per app is pretty much standard for all the environments I've programmed for.
There's absolutely no need for a display system like X to allow multiple application threads to concurrently recieve events and/or update the application's display. It would just add unnesessary complexity, making it harder to debug and maintain.
Also, having a single GUI thread is a good design pattern. All GUI work is handled by one thead, all application logic is (potentially) handled by other threads. The delineation between the application's UI and logic makes it much easier to maintain.
So yeah, blackcoot shouldn't complain that X is broken, I'd say whatever app {s}he is writing needs to get fixed.
Annotea is a LEAD (Live Early Adoption and Demonstration) project enhancing the W3C collaboration environment with shared annotations.
It provides annotation capabilities for HTML documents, and maybe XML documents, delivered in a web browser or similar UA.
Anonzilla is a project for providing Annotea capabilities for Mozilla. Check it out!
HTH /mike
Re:RPG's $10 and are extraordinarily widespread
on
Electric Armor
·
· Score: 2
So what's the actual deal then? Is it that the M1's armour is strong enough to survive several RPG hits in one location? If so, then coming up against a small squad equipped with several RPGs is still going to be problematic.
Or is a lot of the protection afforded from the design of the armour, so that most hits would be glancing blows, and the shell/grenade/whatever would just bounce off? What's stopping the enemy from hitting you from the side, where (I assume) the angle of the armour would be far greater than the front and/or rear?
In any case, for your average psychopathic general, spending a few thousand bucks on an excess of RPGs and launchers for your otherwise crapped-out army to get a few M1 kills probably sounds like a bargain. How much does an M1 go for these days?
/mike.
Re:RPG's $10 and are extraordinarily widespread
on
Electric Armor
·
· Score: 2
Heh, I can think of many other things I'd prefer to decorate with my guts, so I won't take you up on that..
If you're up for a game of OFP, however, let me know..;)
Re:RPG's $10 and are extraordinarily widespread
on
Electric Armor
·
· Score: 2
Ahh, but after playing Operation Flashpoint for many hours, I can honestly claim to have taken out both M1A1s and T80s using RPGs.
It *does* take several shots - usually between two and four, but you can do it. The secret is moving around a hell of a lot and having good cover on hand so they can't take you out when you're reloading or scavenging more rockets from your dead buddies/comrades.
"I can't imagine why anyone would actually use these."
Because pie-menus rock my world!;)
Ever played Neverwinter Nights? How about The Sims? The pie menus in those games allowed for a clean, straight-forward user interface. The great thing about pie menus is that you can get to a lot of different options in a fast, easy, simple to remember, low click manner.
It's probably no suprise that the best place to learn java is http://java.sun.com/. Why? Because of the Java Tutorial and the Java Developer's Connection.
The Tutorial will ease any programmer familiar with similar-level languages in to doing Java devlopment in a few hours, and given a couple of days to go through the pertinent parts of the Tutorial, said devloper will be able to sart accomplishing a lot. The JDC has a bunch of tips, many forums and the bug database. Getting answers to particular problems at the JDC is pretty damm easy.
The Java-specific sites are probably going to be the next best resource. Javaworld usually does well, so much so that I rarely need to go elsewhere.
Slashdot Mirror
Following is the email I just sent to Public Information Research, the guys that do GoogleWatch. I'll post the reply if I get one.
Hi,
I just came across the page and had a few comments to make and questions to ask.
"1. Google's immortal cookie"
Given that all browsers allow you some control over accepting cookies, and the better ones give you more fine-grained control, allowing you to reject cookies from specific domains. I would say this is a moot point.
"2. Google records everything they can:
For all searches they record the cookie ID, your Internet IP address, the time and date, your search terms, and your browser configuration."
Well, the cookie tracking can be resolved as above. It's interesting to note that they don't record my IP address - at work they get my proxy's address, at home they get the addresses of the transparent caches that my ISP uses. I'd say that as transparent caches become more prevalent, that becomes less of an issue. More on this later. Browser configuration? How do they get that (apart from the easily-spoofable UA string)?
I'd also suggest that your ISP does all this as well, especially if you use their proxy, or if they use transparent caches. This is far worse becuase they will be reording *everything* you do on the web. I'd suggest this is a bigger problem right now.
"3. Google retains all data indefinitely"
Can you prove that? If true, it does suck, but they're probably well within their rights to do so. AFAIK, the US doesn't have the more-enlightened privacy laws that the EU and other countries do.
"4. Google won't say why they need this data"
Is that suprising? What do other US companies say when you ask them similar questions?
"5. Google hires spooks"
I'm sure lots of companies hire ex-NSA engineers. Perhaps they hired him because he is a competent engineer? I hope you realise that this point makes you sound like someone with a paranoia disorder of some sort.
"6. Google's toolbar is spyware"
Don't install it then?
"7. Google's cache copy is illegal"
If you don't want something cached, don't publish it on the Internet. Print publishers can't recall magazines and newspapers, why do you expect anything different on the 'Net? If it is illegal, it's probably because the US copyright laws are seriously broken. It *would be good if Google abided by the HTTP cache control headers, rather than resorting to stupid HTML meta hacks.
"8. Google is not your friend:
Young, stupid script kiddies and many bloggers still think Google is "way kool,"
Thanks for the insult. You're an arrogant, paranoid, stupid, wanker. I use Google because it gets me results for random questions. I don't use Google to find a place to buy CDs online. The people out there trying to scam Google probably aren't the kind of people I want to deal with.
"9. Google is a privacy time bomb"
I'd suggest the current US administration is a much bigger, more dangerous, more volatile bomb than Google is or ever will be. If Google is a nasty monkey, the Federal US Government is a 900-pound gorilla.
Mike.
I think what you find is that "leverage" is supposed to be more like "use to gain additional benefit". It is what happens when you use something, and get a bonus on top.
A good example is: "use contraception when having sex". You could quite validly say "leverage contraception when having sex". Not only do you get a good bonk, but you don't produce any more babies.
I hope that clarifies the issue for you a bit.
/mike
While I never normally advocate the use of Perl for anything, I've had to do what you're looking for before, and I found the easiest way was to whip up a quick Perl script using libmail-imapclient-perl or libcyrus-imap-perl which recursively sucks your mail off the server.
:(
The advantages of doing this is that you can then save it into any format you want. I personally was using it to do a IMAP server to server copy, and it worked fantastically.
If I still had the script, I'd post it, but it was many, many harddrives ago that I saw it last.
/mike
If I've learnt only one thing from Dubya, it is this: shoot from the hip first, understand the problem second.
Another victory for Fascist America.
w00t.
Yeah, okay, you got me there. I guess I really do suck.
What confuses me is why the postser asks "Is there something like a Mozilla Administration Kit" and then goes on to answer {his|her} own question. Turkey.
/me goes and hides in a corner.
Hmm, what didn't it do that you wanted?
I used to play around with the CCK for 4.x when it first came out and I found I could remove the the proprietary crap easily enough. I'd also be suprised if you couldn't substitute Moz in instead of NS7 with the current CCK.
/mike
What part of the article didn't I address? Sure the Google bit was a duplication, but that's how I came acroos the CCK in the first place.
How about understanding what I posted? I find a brain works well for that sort of thing.
/mike
How about the mozilla.org CCK? Or if it isn't sufficiently advanced, use Netscape's CCK instead.
/mike
The CCKs exist to do exactly what you want - customize the browser. Why reinvent the wheel?
This is where some basic research could have helped you before posting yet another lame Ask Slashdot question. I find Google works well for that sort of thing. Perhaps you could also start at Mozilla.org's project pages. RTFM, etc, etc, etc.
Well, the links you supplied do look interesting, and I've added them to my reading list, but the blocker for using more advanced thread syncing and comms is that they're not really usable in applications today.
When I'm designing software, I need to use technology that is available, proven and that the guys on my team understand, so unfortunately that counts most of the better solutions out (perhaps only for the time being). Also, you need to remember that we're talking about writing X client applications here, and so the better abstractions just aren't available anyway.
CSP seems interesting. It sounds kinda like the idea behind Java's PipedXXX streams and reader/writers. Have you got any references to other tools that support it? The two links that I found were both dead.
The callback *is* uglier, but your first example using the loop isn't terribly different from:
mouseDraggedCallback(buttons, point) {
if (buttons > 0) {
drawAt(point);
}
}
I'd say the suckiness of using a single thread (and hence of using callbacks) depends on the suckines of the toolkit you're using. If it has been designed properly, you'll get decent callbacks to use.
I'd also argue the callback above more clearly expresses the intention of the author than using a while loop. I think that is a huge boon to understandability and hence maintainability.
Okay, I was thinking more along the lines of user activity, rather than interaction. When the application is updating itself (on another thread) it isn't too hard a task to schedule a update on the GUI thread.
I think that kind of situation is easily avoided by using seperate, non-gui, worker thread(s) to perform non-gui operations. You use the gui thread only for handling user interaction - both user events and updating the display.
The gui thread responds to user events by notifing the worker thread of anything significant. It acts as a translation layer between the user and the workers. For example, if a user selects File > Open, the gui thread prompts the user to select a file, then messages a worker thread to open the selected file. This is a powerful way of doing it because the worker thread can go off and load the file, and the gui stays responsive to further user input. It also keeps the application's code base clean, easy to understand and maintain because there is a clear separation between the gui code and the code that does the real work - the workers.
When the application needs to update the gui as a result of some change, the worker thread just queues a update event and the gui thread goes and performs the update. The gui thread obtains the state or data for the update from shared data sources. The gui thread reads the data, the workers update it.
You're still free to (mostly) structure your app how you want because the most important parts, the worker threads, are decoupled from the gui. You're also free to easily vary the gui (for example, use a different toolkit) without needing to change the whole app.
Ah, I thought that was exactly what I implied. I was talking about the application, which is an X client. Of course the server needs to be thread and process safe - it does display multiple applications at once.
You're telling me multi-threaded apps and libraries are not harder to write, debug and maintain than single-threaded ones? Sorry: *you're* wrong. Even if you use a language which is designed with threading in mind (which X isn't), it adds a *lot* of complexity.
Hey, I said it is a good design pattern. I didn't say it is a golden hammer. Of course you only apply a pattern when it fits.
No, I'm not. Nor am I saying that applications should be single threaded. What gave you that idea?
There's no reason why an application needs to have a multi-threaded GUI. This is not to say that the application should not be multi-threaded, clearly that can very useful. The reason is because user interaction effectively serialized. A user rarely, if ever, provides multiple sources of input simultaneously. In cases when they do, it's usually supplementary to the interaction already occuring - a modifier. So there is rarely any need to process user input and update the display in multiple threads because there is only one thing going on at a time.
Damm, that sounds truely awful. What about user events that traverse mutliple widgets? How do you synchronise them all? What about the scheduling overhead when someone just drags a mouse over the app's UI and fifty threads are woken up almost simultaneously? Most workstations are still uniprocessor based.
And I don't see how that avoids the bazillion little callbacks issue. You're splitting your code up into bazillion little threads instead. In any case, the callbacks aren't an issue of you've designed and written your code properly.
No, I just use a non-GUI thread to do the intensive work, so that the GUI thread is free to play with the user.
Yeah, you "just" need to worry about synchronization, deadlocking, and other concurreny issues instead. Muuuuuuch easier. But what you said above made no sense to me (perhaps I need more coffee) - can you explain this in more detail?
That would be the case if user interaction was a parallel activity, but unfortunately it is not.
Ah, so you obviously know more about the app than I do, because I don't see any evidence in the article to support that statement.
/mike
Christ, I hope they aren't out there getting laid; they might reproduce.
There's enough wankers (literally *and* metaphorically)in the world already.
Yeah, I think having a single GUI thread per app is pretty much standard for all the environments I've programmed for.
There's absolutely no need for a display system like X to allow multiple application threads to concurrently recieve events and/or update the application's display. It would just add unnesessary complexity, making it harder to debug and maintain.
Also, having a single GUI thread is a good design pattern. All GUI work is handled by one thead, all application logic is (potentially) handled by other threads. The delineation between the application's UI and logic makes it much easier to maintain.
So yeah, blackcoot shouldn't complain that X is broken, I'd say whatever app {s}he is writing needs to get fixed.
What was the URL you annotated? I can'r seem to see it..
Annotea is a W3C project. To quote from the site:
It provides annotation capabilities for HTML documents, and maybe XML documents, delivered in a web browser or similar UA.
Anonzilla is a project for providing Annotea capabilities for Mozilla. Check it out!
HTH
/mike
So what's the actual deal then? Is it that the M1's armour is strong enough to survive several RPG hits in one location? If so, then coming up against a small squad equipped with several RPGs is still going to be problematic.
/mike.
Or is a lot of the protection afforded from the design of the armour, so that most hits would be glancing blows, and the shell/grenade/whatever would just bounce off? What's stopping the enemy from hitting you from the side, where (I assume) the angle of the armour would be far greater than the front and/or rear?
In any case, for your average psychopathic general, spending a few thousand bucks on an excess of RPGs and launchers for your otherwise crapped-out army to get a few M1 kills probably sounds like a bargain. How much does an M1 go for these days?
Heh, I can think of many other things I'd prefer to decorate with my guts, so I won't take you up on that..
;)
If you're up for a game of OFP, however, let me know..
Ahh, but after playing Operation Flashpoint for many hours, I can honestly claim to have taken out both M1A1s and T80s using RPGs.
/mike
It *does* take several shots - usually between two and four, but you can do it. The secret is moving around a hell of a lot and having good cover on hand so they can't take you out when you're reloading or scavenging more rockets from your dead buddies/comrades.
Because pie-menus rock my world!
Ever played Neverwinter Nights? How about The Sims? The pie menus in those games allowed for a clean, straight-forward user interface. The great thing about pie menus is that you can get to a lot of different options in a fast, easy, simple to remember, low click manner.
Fantatsic stuff.
/mike.
Didn't you just effectively say: "Foo already exists, but I'm glad someone just made foo"?
/mike
Anyway, let's assume foo does indeed already exist in one or more forms. Got any links to them? I'd be interested in checking the alternatives out.
cheers,
Ah, I see.. Thanks! /xm
"Remember the Maine?"
/mike.
Err, no I don't, to be honest. Probably because I'm a) younger than 100 an b) not a US citizen.
Can you explain what happened to that warship?
Hah Har! Loser!
It's probably no suprise that the best place to learn java is http://java.sun.com/. Why? Because of the Java Tutorial and the Java Developer's Connection.
/mike.
The Tutorial will ease any programmer familiar with similar-level languages in to doing Java devlopment in a few hours, and given a couple of days to go through the pertinent parts of the Tutorial, said devloper will be able to sart accomplishing a lot. The JDC has a bunch of tips, many forums and the bug database. Getting answers to particular problems at the JDC is pretty damm easy.
The Java-specific sites are probably going to be the next best resource. Javaworld usually does well, so much so that I rarely need to go elsewhere.
HTH,
As soon as I start working on it again, of course. If anyone wants to lend a hand, feel free.. ;)
A joystick port, eh? Oh, good, that will help.
What about my 466? It DOES have a power supply...
;)