You can't prove or disprove (or refute) an opinion. The author of that sentence in wikipedia was expressing his opinion. Since there is no absolute metric by which you can define a 'design flaw', this is simply an opinion piece.
What specific functionality does having the process list exposed through a file-system-like facade give you that the various windows process discovery tools done?
This is not a facetious question, I'm quite serious. Is it just that you can treat it like a directory, or is there something it actually gives you that you like better?
Now maybe you're just pulling arbitrary numbers out of the sky... but $100k per year is not that much money.
It'll mean you get to own a middle-class home and own a car, and take a nice trip once per year.
But you'll never be able to own your house outright, or spend a month or two in europe per year travelling. And you certainly wont be able to save up enough money to retire before 50.
Money buys freedom and opportunity at the high end, and it buys security and safety at the low end.
Again, you may have just been pulling numbers, and not meant those specific numbers. But there is a qualitative difference in lifestyle between $100k and $500k.
And even if you disagree with that, a few years at Microsoft then and you can save up enough money to start the next company, and be able to carry off your savings for a few years.
And even if you disagree with that, then think about the lifestyle of a Fellow at a company like MS. He basically gets to work on whatever he wants, not tied to the product releases. Not a bad setup.
"Tabbed browsing is a gimic that steals screen space and makes me move my hands from the keyboard to the mouse."
I've got to disagree with you on this.
Right now, I've got 34 tabs open in Opera (this being one), and its a _much_ more compact layout than 34+ items on the Task Bar. That many items would force vertical scrolling on the task bar, but fits just fine within my opera window with no scrolling.
In addition, I almost never use the mouse to use multiple tabs. Why would you? Just use CTRL+TAB to cycle through the Opera windows (same shortcut key combo as pretty much every other multi-document windows app).
Combine tabbed browsing with session saving, and I dont even have to finish reading my articles in one sitting. I just close Opera when I'm done and when I re-open it next, it leaves me precisely where I was when I closed it, with all 30+ tabs open.
Lastly, if you hate the mouse (like I do), you'll love Opera for its incredibly comprehensive keyboard shortcuts. In addition to nearly every action available in Opera having a keyboard shortcut, its completely customizeable to your hearts content.
In other words, Opera rules.:) FireFox is a poor imitation.
1. You either use the migration tool included with your new mail product, or you write a script to walk through the users and export their data one at a time.
2. Contacts are included in my earlier post example.
3. Calendar items are included in my earlier post. iCal support (kind of) is in Outlook since XP version, but its not implemented very well. Probably your best bet is to use a 3rd party plugin, like this:
Better iCal support is scheduled for Outlook 2007 released later this year, for what thats worth.
4. Actually, a spreadsheet is not the most useful format to export it in. PST file is the most portable, as nearly every other mail product on the planet knows how to import from it.
And I'm not sure what format you're talking about when you say 'plain email files', unless you mean just a text representation of the email. With that you'd have to then write software to parse out the individual fields and import it to another format, and that doesnt really buy you anything compared to PST or CSV, other than an extra step of software to write. But even if you did have that, it still wouldnt help you with calendar, tasks, contacts, etc etc.
5. I cant speak to that, but a lack of good competitive clients to Outlook doesnt mean the information isnt out there.
Heck, there's even information in there about how it maps to X.400 and the wire-level protocol.
After looking through it for a few minutes (first time I've done that in years), its possible that its just very complicated, probably much more complicated than IMAP. So there's a real diminishing level of return on your investment, given that Outlook is free if you own Exchange (so no cost advantage to writing your own client), plus its a mature and well-developed piece of software. Starting your own would put your a decade behind MS on the client. Of course, if you started one in the Outlook 95 time-frame, that wouldnt have been the case.
How do you figure? How does the client-server protocol Outlook uses to connect to Exchange lock me in?
As long as I can fully export all of my Outlook/Exchange data into a number of different formats, pretty much at will, then I'm not locked in.
File Import and Export Export to a File [Choose:]
Comma Separated Values (DOS)
Comma Separated Values (Windows)
Microsoft Access
Microsoft Excel
Person Folders File (.pst)
Tab Separated Values (DOS)
Tab Separated Values (Windows) -- select pst, as every other mail/pim on the planet can import from it Select the Folder to Export From:
Select All
Include Subfolders
All that a (semi) proprietary protocol does it makes it harder to use an arbitrary mail client with Exchange. But if you do that, then you're degrading your experience, as there's nothing out there that works as well and has the same feature set as Outlook+Exchange.
If using whatever client is important to you, then use a standards protocol like IMAP, and accept the reduced functionality.
Also, although MAPI is technically a proprietary protocol, it is well understood and well documented by Microsoft. It's not open, but its not undocumented, by any stretch of the imagination.
Because IMAPS would not give you the full feature set of Outlook/Exchange (Calendar, Tasks, Public Folders, shared calendars, delegation, Contacts, Journal, Notes, etc)
RPC over HTTPS replaces the on-LAN mapi connectivity that gives you the full set of Outlook/Exchange features, as its basically mapi via rpc tunneled over https.
It's a much better experience than using IMAP, as you're always online, even if your machine is not connected to anything. And then when you are connected, a background thread continuously synchronizes between Outlook and Exchange.
For mobile/laptops users, Outlook 2003 and Cached Exchange Mode (the offline/synchronized thing) is one of the greatest things ever invented.
Outlook is only a shell of an app without Exchange.
But if you own Exchange you automatically own Outlook for all your licensed users (ie, included in the price of the CALs).
So the only market for this is people who want an Outlook-like application, but are using it in a workgroup environment, without Exchange.
Seems like a niche. If you want the full power, you use Exchange & Sharepoint with office. But if you have Exchange, you already own Outlook. And if you own outlook, why would you use Evolution?
Given your description, I hope no one ever forgets their password. Would suck as a business to lose the person's entire history of email because of this.
Most corporate based encryption systems escrow a global admin key pair for just this situation.
And, other than the public/private key situation, most other email systems let you do all these things as well.
On Exchange, for example, you can delegate permissions at any level of granularity you desire. A person could have the ability to create new Exchange accounts, for example, but not modify any existing ones.
In addition, if you're granted full ACL controls to your directories, you can effectively lock out the admins by setting the ACLs appropriately. That way, the only way they can get access is by taking ownership of the files, which leaves big fat tracks all over the system.
Now I'll grant you, the public/private keypair and signing business is -very- cool, and I'd love to see more of it. But its also how MS is doing the BitLocker drive encryption, so that's nice to see.
You can scale out an Exchange infrastructure arbitrarily wide at _any point in the stack_. If your bottleneck is in your MTAs, then setup more dedicated MTA boxes. Is the MAPI/RPC front-end bottlenecked, or how about OWA? Well, you can build out layers of servers that do just those.
Need real heavy POP3/IMAP servers? Can build out those too.
Oh and you want geographically dispersed site-to-site replication? Thats well supported too:
I realize that many organizations do it, and it works okay, but you're basically doing something that the software makers are telling you doesnt work real well. You shouldnt be surprised then if it doesnt work real well.
My question then is, if you're having users put PST files on file servers, why not just give them 1GB+ mailboxes on exchange, and consolidate your storage space?
Would simplify the administration (all mail is in one place, instead of two), and eliminate performance issues.
If your people already know Access, then you're already half way there.
Setup an MS SQL Server 2005 server, and give a DB to anyone developing one of these apps.
They can use Access in ADP (Access Data Project) mode, which is basically just the Access front end, and an MS SQL optimized back-end.
That way, all the easy to use & develop forms, queries, and reports are still there, but IT controls the DBs, and so can do backups, data integrity, assurance, etc.
It's really quite a good solution, that we've used in our organization, if your people are comfortable and productive with Access.
The other upside is that if it ever does need to be made a production app, since the DB is already on a real db server, and you know the data is in good shape with good table structures (since IT helped), its not too bad to slap a VB or ASP.NET front end on it.
" That would apply to automobiles too; buy a clean-burning, efficient vehicle, and you should pay less tax than the guy in the 9 mpg H2."
How does this make sense?
You want to charge people more for the privilege of already paying more for gas? I drive a Dodge Ram 1500 4x4 Hemi, and get 10-11 mpg. I _already_ pay far more than most other people to drive my truck.
Yet because my truck is brand new, it puts out very little emissions. A '95 accord that hasnt been well maintained will likely put out hugely more emissions. Yet I should be punished because I burn more gas (yet put out far fewer emissions)?
If you want to economically disincentivise emissions, then tax emissions, not gas consumption.
Unfortunately, in reality this ends up being a regressive tax. The people who can afford the least will tend to have the oldest, most poorly maintained cars. And those are the cars that are the worst polluters.
While doing a very low carbohydrate diet, I consumed no more than ~20 grams of carbohydrates per day, and switched over to Ketosis (confirmed by the pee strips that measure ketone bodies in your urine).
I did that for several months, and did not go into a coma nor die.
In fact, the amazing thing was how steady and never-ending my energy was on that diet. No up down spikes from high glycemic foods that rapidly transform into glucose and then are rapidly converted by an insulin spike.
The other thing to remember is that there is a significant overhead for each database call.
It has to grab a connection from the pool (or God help you create a new one, which is very slow), cross the network, search the query plan cache (and create a new plan if there isnt one cached), and then run the plan.
Then its got to serialize all the results (though most modern DB client libraries use highly compact and efficient result transports), and ship them back across the network, then deserialize them into some sort of object store in memory on the webserver.
The only part of this that is actually running the query (ie, limited to the speed at which the db server can produce query results) is the 'run the plan' part.
The rest is all overhead. And often on simple single table selects, the overhead takes longer than the query itself. So now you've got 60%+ of your time wasted on overhead, and you want to run hundreds of those queries, rather than one?
One of the general rules of thumb in a properly layered application is that round-trips to the database is one of the most expensive things you can do. And its not expensive because the queries themselves take much time, its because the round tripping across the network is slow, and all the overhead is slow.
This is also why db caching on the webserver (or app servers) provides such hugely dramatic peformance or scalability improvements.
If you find you cant tune (ie, index, partition, or schema design/redesign) even the most hideously large queries involving many tables and millions of records into sub-second response times, regardless of your db skills, then it may be time for a new database server.
If your 'experts' are writing any queries (other than used for reporting purposes, where you dont need real-time results) that take 20 seconds, then by definition they are not db experts.
You can write 12+ table joins queries that are selecting 5-10 rows out of those 12 tables with many millions of records total in a highly transactional (ie, lots of inserts & deletes) environment, with nearly instataneous responses.
In fact, thats one of the primary points of a proper RDBMS. The length of time your queries take to execute grows at a tiny fraction of the rate of the size of the datasets. Properly indexed & partitioned tables, properly designed schemas, and properly written queries are very insensitive to the size of the dataset underneath.
Depends on the user type. A business can run non-admin in a large percentage of the cases, or at worst, give out both regular and admin accounts to users that need them (for installation of custom software, etc).
Our organization does, and has since we deployed XP Pro in the org. Devs, IT folks, and others that prove they wont abuse it are also granted la accounts in addition to their regular work accounts, for when they really really need local admin on the box.
Home users are going to struggle the most with things like Games and the like. It's completely possible to run 100% as a non-admin in windows, but you often need to be a pro on the platform to work with some of the unusual situations.
"On the other hand your approach still does not solve my bigger problem: an effective way of remote administering windows machines even on crappy (GPRS or worse) lines (yes i had to admin cisco routers on 1200-2400bps) lines not that long ago (4 years).."
Have you tried:
1. Remote Desktop. Works fine and snappy over a 56k dial-up modem (as long as you've got it set to a modem-setting on the quality).
2. Administration Tools & Support Tools. Nearly every tool MS makes will work against the local machine or any arbitrary remote machine. Since its doing RPC over the network (ie, no gui or user interface of any sort), its fast and works okay over slow connections.
"...or do you let them use an OS that is usable as a limited user and give them the admin password so they can do admin tasks when needed, and trust your employees to do the right thing?"
This is exactly and precisely what we do... on Windows.
People like this who have a legitimate business need (installing WebShots does not count) get two accounts.
- an unprivileged domain user account la - an account in the local Administrators group on their machine
Ideally, you also put all the la accounts in a domain group and specifically restrict that group from accessing anything interesting on the domain (Exchange, file servers, intranet, etc), to create a disincentive for doing day-to-day work on their la account.
So they use their account 99% of the time, and when they need to install something, they do RunAs with their la accounts, and do what they need to do.
MS doesnt 'have everyone running as admin'. Thats purely an organizational choice, and there's no logical reason to do so.
It's not hard, but I'll lay it out here.
1. Create an la account on the local machine or the domain, for each person who needs local admin rights. Make sure this account has no privileges to Exchange, the File Servers, the corporate intranet, etc (ie, so they physically cannot use it for day to day work).
This way, people work in their non-priv'd account for day to day work, but periodically can use RunAs with their la account to install new software, start/stop services, etc etc.
This is how we run our ~250 user financial services organization, and the people who need it (and who havent proved they cant handle it) get la accounts.
My work is as a developer, and I have _zero_ problems doing development on my machine. I do so in both Visual Studio (have to be a member of the VS Debugger group), and Eclipse/Tomcat. I can even start & stop tomcat with no problems from my regular account, since Tomcat is running in userspace on a high port.
There are a small number of apps we use that require very minor permissions modifications pushed out via GPO to work, but you only have to do this research once for the entire organization, then you slap it in GPO and its done forever.
Slashdot Mirror
You can't prove or disprove (or refute) an opinion. The author of that sentence in wikipedia was expressing his opinion. Since there is no absolute metric by which you can define a 'design flaw', this is simply an opinion piece.
What specific functionality does having the process list exposed through a file-system-like facade give you that the various windows process discovery tools done?
This is not a facetious question, I'm quite serious. Is it just that you can treat it like a directory, or is there something it actually gives you that you like better?
Now maybe you're just pulling arbitrary numbers out of the sky ... but $100k per year is not that much money.
It'll mean you get to own a middle-class home and own a car, and take a nice trip once per year.
But you'll never be able to own your house outright, or spend a month or two in europe per year travelling. And you certainly wont be able to save up enough money to retire before 50.
Money buys freedom and opportunity at the high end, and it buys security and safety at the low end.
Again, you may have just been pulling numbers, and not meant those specific numbers. But there is a qualitative difference in lifestyle between $100k and $500k.
And even if you disagree with that, a few years at Microsoft then and you can save up enough money to start the next company, and be able to carry off your savings for a few years.
And even if you disagree with that, then think about the lifestyle of a Fellow at a company like MS. He basically gets to work on whatever he wants, not tied to the product releases. Not a bad setup.
"Tabbed browsing is a gimic that steals screen space and makes me move my hands from the keyboard to the mouse."
:) FireFox is a poor imitation.
I've got to disagree with you on this.
Right now, I've got 34 tabs open in Opera (this being one), and its a _much_ more compact layout than 34+ items on the Task Bar. That many items would force vertical scrolling on the task bar, but fits just fine within my opera window with no scrolling.
In addition, I almost never use the mouse to use multiple tabs. Why would you? Just use CTRL+TAB to cycle through the Opera windows (same shortcut key combo as pretty much every other multi-document windows app).
Combine tabbed browsing with session saving, and I dont even have to finish reading my articles in one sitting. I just close Opera when I'm done and when I re-open it next, it leaves me precisely where I was when I closed it, with all 30+ tabs open.
Lastly, if you hate the mouse (like I do), you'll love Opera for its incredibly comprehensive keyboard shortcuts. In addition to nearly every action available in Opera having a keyboard shortcut, its completely customizeable to your hearts content.
In other words, Opera rules.
1. You either use the migration tool included with your new mail product, or you write a script to walk through the users and export their data one at a time.
= /library/en-us/mapi/html/83f1e307-095b-4d27-a3ec-f f4aa22f471a.asp
2. Contacts are included in my earlier post example.
3. Calendar items are included in my earlier post. iCal support (kind of) is in Outlook since XP version, but its not implemented very well. Probably your best bet is to use a 3rd party plugin, like this:
http://outlook2ical.sourceforge.net/
Better iCal support is scheduled for Outlook 2007 released later this year, for what thats worth.
4. Actually, a spreadsheet is not the most useful format to export it in. PST file is the most portable, as nearly every other mail product on the planet knows how to import from it.
And I'm not sure what format you're talking about when you say 'plain email files', unless you mean just a text representation of the email. With that you'd have to then write software to parse out the individual fields and import it to another format, and that doesnt really buy you anything compared to PST or CSV, other than an extra step of software to write. But even if you did have that, it still wouldnt help you with calendar, tasks, contacts, etc etc.
5. I cant speak to that, but a lack of good competitive clients to Outlook doesnt mean the information isnt out there.
For example, here is a link to the MAPI SDK which includes the full API:
http://msdn.microsoft.com/library/default.asp?url
Heck, there's even information in there about how it maps to X.400 and the wire-level protocol.
After looking through it for a few minutes (first time I've done that in years), its possible that its just very complicated, probably much more complicated than IMAP. So there's a real diminishing level of return on your investment, given that Outlook is free if you own Exchange (so no cost advantage to writing your own client), plus its a mature and well-developed piece of software. Starting your own would put your a decade behind MS on the client. Of course, if you started one in the Outlook 95 time-frame, that wouldnt have been the case.
Install SpamBayes:
http://spambayes.sourceforge.net/
It's fantastic, trainable, and most of all:
Doesnt require setting up an elaborate set of MTAs and mail servers. It plugs right into Outlook as a COM add-in, and works in real-time.
It's one of the best ones out there, due to its bayesian trainability, plus its python based and open-source. Can't beat it.
If all you're missing is good indexed search, then install Lookout for Outlook.
It's a separate product for now, but MS purchased Lookout a while back, so it'll likely be integrated into Outlook 2007.
http://www.lookoutsoft.com/Lookout/download.html
It's basically google desktop for Outlook, its fast, and it works great.
How do you figure? How does the client-server protocol Outlook uses to connect to Exchange lock me in?
As long as I can fully export all of my Outlook/Exchange data into a number of different formats, pretty much at will, then I'm not locked in.
File
Import and Export
Export to a File
[Choose:]
Comma Separated Values (DOS)
Comma Separated Values (Windows)
Microsoft Access
Microsoft Excel
Person Folders File (.pst)
Tab Separated Values (DOS)
Tab Separated Values (Windows)
-- select pst, as every other mail/pim on the planet can import from it
Select the Folder to Export From:
Select All
Include Subfolders
All that a (semi) proprietary protocol does it makes it harder to use an arbitrary mail client with Exchange. But if you do that, then you're degrading your experience, as there's nothing out there that works as well and has the same feature set as Outlook+Exchange.
If using whatever client is important to you, then use a standards protocol like IMAP, and accept the reduced functionality.
Also, although MAPI is technically a proprietary protocol, it is well understood and well documented by Microsoft. It's not open, but its not undocumented, by any stretch of the imagination.
Because IMAPS would not give you the full feature set of Outlook/Exchange (Calendar, Tasks, Public Folders, shared calendars, delegation, Contacts, Journal, Notes, etc)
RPC over HTTPS replaces the on-LAN mapi connectivity that gives you the full set of Outlook/Exchange features, as its basically mapi via rpc tunneled over https.
It's a much better experience than using IMAP, as you're always online, even if your machine is not connected to anything. And then when you are connected, a background thread continuously synchronizes between Outlook and Exchange.
For mobile/laptops users, Outlook 2003 and Cached Exchange Mode (the offline/synchronized thing) is one of the greatest things ever invented.
This just seems so silly.
Outlook is only a shell of an app without Exchange.
But if you own Exchange you automatically own Outlook for all your licensed users (ie, included in the price of the CALs).
So the only market for this is people who want an Outlook-like application, but are using it in a workgroup environment, without Exchange.
Seems like a niche. If you want the full power, you use Exchange & Sharepoint with office. But if you have Exchange, you already own Outlook. And if you own outlook, why would you use Evolution?
Given your description, I hope no one ever forgets their password. Would suck as a business to lose the person's entire history of email because of this.
Most corporate based encryption systems escrow a global admin key pair for just this situation.
And, other than the public/private key situation, most other email systems let you do all these things as well.
On Exchange, for example, you can delegate permissions at any level of granularity you desire. A person could have the ability to create new Exchange accounts, for example, but not modify any existing ones.
In addition, if you're granted full ACL controls to your directories, you can effectively lock out the admins by setting the ACLs appropriately. That way, the only way they can get access is by taking ownership of the files, which leaves big fat tracks all over the system.
Now I'll grant you, the public/private keypair and signing business is -very- cool, and I'd love to see more of it. But its also how MS is doing the BitLocker drive encryption, so that's nice to see.
Yes.....
a nge/guides/E2k3HighAvGuide/99353155-7908-4d44-a609 -48199919f188.mspx?mfr=true
a nge/guides/E2k3DataRepl/bedf62a9-dff7-49a8-bd27-b2 f1c46d5651.mspx?mfr=true
Because no one at Microsoft has ever thought of how to do clustering in Exchange server:
http://www.microsoft.com/technet/prodtechnol/exch
You can scale out an Exchange infrastructure arbitrarily wide at _any point in the stack_. If your bottleneck is in your MTAs, then setup more dedicated MTA boxes. Is the MAPI/RPC front-end bottlenecked, or how about OWA? Well, you can build out layers of servers that do just those.
Need real heavy POP3/IMAP servers? Can build out those too.
Oh and you want geographically dispersed site-to-site replication? Thats well supported too:
http://www.microsoft.com/technet/prodtechnol/exch
The options are nearly limitless.
Putting PST files on the network is a known 'bad thing', and MS specifically tells you not to do it, that its unstable, and they dont support it.
http://support.microsoft.com/kb/297019/
I realize that many organizations do it, and it works okay, but you're basically doing something that the software makers are telling you doesnt work real well. You shouldnt be surprised then if it doesnt work real well.
My question then is, if you're having users put PST files on file servers, why not just give them 1GB+ mailboxes on exchange, and consolidate your storage space?
Would simplify the administration (all mail is in one place, instead of two), and eliminate performance issues.
If your people already know Access, then you're already half way there.
Setup an MS SQL Server 2005 server, and give a DB to anyone developing one of these apps.
They can use Access in ADP (Access Data Project) mode, which is basically just the Access front end, and an MS SQL optimized back-end.
That way, all the easy to use & develop forms, queries, and reports are still there, but IT controls the DBs, and so can do backups, data integrity, assurance, etc.
It's really quite a good solution, that we've used in our organization, if your people are comfortable and productive with Access.
The other upside is that if it ever does need to be made a production app, since the DB is already on a real db server, and you know the data is in good shape with good table structures (since IT helped), its not too bad to slap a VB or ASP.NET front end on it.
" That would apply to automobiles too; buy a clean-burning, efficient vehicle, and you should pay less tax than the guy in the 9 mpg H2."
How does this make sense?
You want to charge people more for the privilege of already paying more for gas? I drive a Dodge Ram 1500 4x4 Hemi, and get 10-11 mpg. I _already_ pay far more than most other people to drive my truck.
Yet because my truck is brand new, it puts out very little emissions. A '95 accord that hasnt been well maintained will likely put out hugely more emissions. Yet I should be punished because I burn more gas (yet put out far fewer emissions)?
If you want to economically disincentivise emissions, then tax emissions, not gas consumption.
Unfortunately, in reality this ends up being a regressive tax. The people who can afford the least will tend to have the oldest, most poorly maintained cars. And those are the cars that are the worst polluters.
Thats not true at all.
The only part of your body which absolutely requires glucose as an energy source is your brain, and it doesnt require all that much.
The rest of your body can be converted over to burning Ketones if you consume close to zero carbohydrates.
Here's a quick read at wikipedia, you can find more information online if you hunt:
http://en.wikipedia.org/wiki/Ketosis
While doing a very low carbohydrate diet, I consumed no more than ~20 grams of carbohydrates per day, and switched over to Ketosis (confirmed by the pee strips that measure ketone bodies in your urine).
I did that for several months, and did not go into a coma nor die.
In fact, the amazing thing was how steady and never-ending my energy was on that diet. No up down spikes from high glycemic foods that rapidly transform into glucose and then are rapidly converted by an insulin spike.
I believe he was referring to Object Databases (as opposed to Relational Databases).
Wikipedia has a decent summary of this here:
http://en.wikipedia.org/wiki/Object_database
What you're talking about (at least my understanding) are Object-Relational Mapping tools, like Apache OJB, Hibernate, etc.
Someone can correct me if I've misunderstood, but I think thats what the parent meant.
The other thing to remember is that there is a significant overhead for each database call.
It has to grab a connection from the pool (or God help you create a new one, which is very slow), cross the network, search the query plan cache (and create a new plan if there isnt one cached), and then run the plan.
Then its got to serialize all the results (though most modern DB client libraries use highly compact and efficient result transports), and ship them back across the network, then deserialize them into some sort of object store in memory on the webserver.
The only part of this that is actually running the query (ie, limited to the speed at which the db server can produce query results) is the 'run the plan' part.
The rest is all overhead. And often on simple single table selects, the overhead takes longer than the query itself. So now you've got 60%+ of your time wasted on overhead, and you want to run hundreds of those queries, rather than one?
One of the general rules of thumb in a properly layered application is that round-trips to the database is one of the most expensive things you can do. And its not expensive because the queries themselves take much time, its because the round tripping across the network is slow, and all the overhead is slow.
This is also why db caching on the webserver (or app servers) provides such hugely dramatic peformance or scalability improvements.
If you find you cant tune (ie, index, partition, or schema design/redesign) even the most hideously large queries involving many tables and millions of records into sub-second response times, regardless of your db skills, then it may be time for a new database server.
If your 'experts' are writing any queries (other than used for reporting purposes, where you dont need real-time results) that take 20 seconds, then by definition they are not db experts.
You can write 12+ table joins queries that are selecting 5-10 rows out of those 12 tables with many millions of records total in a highly transactional (ie, lots of inserts & deletes) environment, with nearly instataneous responses.
In fact, thats one of the primary points of a proper RDBMS. The length of time your queries take to execute grows at a tiny fraction of the rate of the size of the datasets. Properly indexed & partitioned tables, properly designed schemas, and properly written queries are very insensitive to the size of the dataset underneath.
Depends on the user type. A business can run non-admin in a large percentage of the cases, or at worst, give out both regular and admin accounts to users that need them (for installation of custom software, etc).
Our organization does, and has since we deployed XP Pro in the org. Devs, IT folks, and others that prove they wont abuse it are also granted la accounts in addition to their regular work accounts, for when they really really need local admin on the box.
Home users are going to struggle the most with things like Games and the like. It's completely possible to run 100% as a non-admin in windows, but you often need to be a pro on the platform to work with some of the unusual situations.
This stuff is so silly ... if you're using your box correctly, and not running as admin, this whole thing is meaningless and amusing.
"On the other hand your approach still does not solve my bigger problem: an effective way of remote administering windows machines even on crappy (GPRS or worse) lines (yes i had to admin cisco routers on 1200-2400bps) lines not that long ago (4 years) .."
Have you tried:
1. Remote Desktop. Works fine and snappy over a 56k dial-up modem (as long as you've got it set to a modem-setting on the quality).
2. Administration Tools & Support Tools. Nearly every tool MS makes will work against the local machine or any arbitrary remote machine. Since its doing RPC over the network (ie, no gui or user interface of any sort), its fast and works okay over slow connections.
Bah. Stupid /. plain text mode that suppresses brackets.
That should be:
UserName - an unprivileged domain user account
laUserName - an account in the local Administrators group on their machine
"...or do you let them use an OS that is usable as a limited user and give them the admin password so they can do admin tasks when needed, and trust your employees to do the right thing?"
... on Windows.
This is exactly and precisely what we do
People like this who have a legitimate business need (installing WebShots does not count) get two accounts.
- an unprivileged domain user account
la - an account in the local Administrators group on their machine
Ideally, you also put all the la accounts in a domain group and specifically restrict that group from accessing anything interesting on the domain (Exchange, file servers, intranet, etc), to create a disincentive for doing day-to-day work on their la account.
So they use their account 99% of the time, and when they need to install something, they do RunAs with their la accounts, and do what they need to do.
Simple as pie.
MS doesnt 'have everyone running as admin'. Thats purely an organizational choice, and there's no logical reason to do so.
It's not hard, but I'll lay it out here.
1. Create an la account on the local machine or the domain, for each person who needs local admin rights. Make sure this account has no privileges to Exchange, the File Servers, the corporate intranet, etc (ie, so they physically cannot use it for day to day work).
This way, people work in their non-priv'd account for day to day work, but periodically can use RunAs with their la account to install new software, start/stop services, etc etc.
This is how we run our ~250 user financial services organization, and the people who need it (and who havent proved they cant handle it) get la accounts.
My work is as a developer, and I have _zero_ problems doing development on my machine. I do so in both Visual Studio (have to be a member of the VS Debugger group), and Eclipse/Tomcat. I can even start & stop tomcat with no problems from my regular account, since Tomcat is running in userspace on a high port.
There are a small number of apps we use that require very minor permissions modifications pushed out via GPO to work, but you only have to do this research once for the entire organization, then you slap it in GPO and its done forever.