(I hate it when that happens. I put in everything but the conclusion.)
IMHO, access lists are only useful to allow you to fill in the little checkbox on government/military procurement forms "access lists? (y/n)" with a "y"
Only way you're gonna get Linux into government/military stuff is to have access lists. Full stop. Therefore, ACLs are very useful (vital, actually) as a patch to some standard filesystem, just so you can check the little box. As to merging them into the kernel, forget it. They really accomplish nothing, and just get in the way.
Get over ACLs... they are a waste of time and programming effort.
IMHO, access lists are only useful to allow you to fill in the little checkbox on government/military procurement forms "access lists? (y/n)" with a "y". No access lists? Gotta use NT, because it has access lists. Why do we need access lists? The spec says so. Why does... we get lost in an infinite regression.
Every attempt that I've seen to actually *use* access lists for anything useful has quickly degenerated into an unusable swamp.
Most Unix admins and users can't deal with the idea of separate groups for separate projects. You want them to try to figure out access lists?
Now, admittedly, standard Unix permissions are really lame. Unfortunately, access lists aren't the answer. Adding "capabilities" to Unix (the real way to fix the permission problem) would require enough changes that the resulting system couldn't really be called "Unix" anymore.
What is wrong with all these slashdotters that think NASA needs to be cut all together. Exploration is at the heart of what the human race does. If the same attitude was taken hundreds of years ago, the USA would never have been discovered...
If NASA had been in charge of exploring the Atlantic Ocean in the 1400s - 1500s, they'd still be taking soundings off the Azores to make sure they wouldn't run into something unexpected.
In order to explore, you must take risks.
If we want to "explore space", we need an outfit that will do it (or at least get out of the way). NASA puts bureaucratic arse-covering above exploration.
Does anybody know of a single large system that they've built that actually worked as designed and was done on time and on budget?
Everything I've heard about them is bad. "Death marches". Systems cancelled after the customer spent (mumble) millions of dollars. Severe specification downgrades. Lawsuits trying to get paid.
They're one of the US Government's biggest suppliers. Is anybody surprised?
The W3C lives in a fantasy world where we all have good WYSIWYG tools for doing all of our HTML design. Complexity doesn't matter, as the tools handle it all for us. Unfortunately, at the current state of the art, the good tools suck and the bad tools (which everybody seems to use) produce HTML of Lovecraftian horror. We're gonna be doing it (or at least cleaning it up) by hand for a long time, folks.
MathML is another one of those things that tries to be all things to all people, all at the same time. Result is yet another markup language trying to be a page description language.
As a counter suggestion, how about something based on the old eqn preprocessor for troff? Simple and easy to understand, and far more in the "content, not format" spirit than MathML. Brian Kernighan was supposedly working on something like this. Any news?
that you will have to have a MSN account to use this. Don't expect the marketing droids to ever give up.
Then there's the security aspect. "Microsoft has installed monitoring software, with man-in-the-middle cacheing for SSL, for your Web surfing and e-mail convienence."
Skroom. By Seattle standards, at least, Starbuck's is bottom shelf coffee anyway.
Of course the Manhatten Project had computers! Remember, at that time "computer" was a job description and not a piece of hardware.
Richard Feynman describes punch-card computers on the Manhatten Project in "Surely You're Joking, Mr. Feynman". Admittedly, calling them "computers" is a stretch, but they did do mathematical operations on numbers punched into cards. Output was more punched cards. They used *a lot* of cards....
I saw a news item a while back about the Administration's attempts to keep people from exporting supercomputers to China.
"Why?" ran the question. "What can they do with a supercomputer"?
"Military weather prediction" was the answer.
"What about nuclear weapon design?"
"Nuclear weapon design is no longer considered computationally significant."
Yeesh.
The most advamced computers on the Manhattan Project ran on punched cards. Most of our current inventory of nukes were designed on machines less powerful than a low-end desktop.
Fortunately, manufacture of nukes is *considerably* more difficult than design. Plutonium is spectacularly difficult to deal with.
Yup. I've seen too much of it, too. Don't forget that the programmers (the guys on the bottom) get blamed for anything that goes wrong. The managers (at all levels) have their Teflon suits on.
Now go back and assume your project is a bridge instead of a program. Nobody within hollering distance of their right mind would put up with this kind of crap. Build a bridge that way, and it will collapse. Very publicly.
What's the difference? Only about 4000 years of experience. People in the management chain have a feel for what is needed for a bridge to "work", and know that they can't interfere in the process without risking disaster.
Software is newer and much harder to quantify. A bridge either falls down or it doesn't. A computer system has zillions of "degraded" modes that it can get into and still sorta work. It can be really hard to tell if a program is meeting its goals.
Because of this, managers can get away with all manner of crap. Software engineering will not be a real engineering field until a typical "software engineer" can say something to his manager like "Testing is going to take six weeks, period. I don't care if you miss Comdex, it doesn't get released until it goes through Test, and that will take six weeks." *AND HAVE IT STICK*.
Your list of questions applies to *any* engineering field. You need to ask the same questions if you're building a bridge. Does this mean that we should try to keep the field of "engineering" from fragmenting? Sorry; it already has.
"Software engineering" (somewhat of an oxymoron, IMHO) will fragment, just like any other field, as the skill sets needed for the various aspects of programming drift apart. Would you want a pacemaker designed by a video game programmer? Would you want a video game designed to medical implant standards?
BTW, your last question is not really a matter of engineering, software or otherwise. How does a pacemaker "decrease the amount of repetitive work that humans have to do"?
Back in the early/mid 1980s[1], I got burned by one of these. It backed up a PDP-11/23 to a VHS VCR. Management[2] bought into this as our only backup for the 11/23s.
The first test I ran was simple:
1. Make a full backup
2. Delete a file
3. Restore the file from the backup
It didn't work. All it did was read through the entire tape and report "restore unsuccessful". No useful info. Bad tape? Maybe, but I tried with a couple of different tapes. My guess was that the software was only capable of handling "full partition" backup and restore, despite what the manual said. I assume (with no evidence) that *somebody* ran *some* tests before they bought into this.
To add insult to injury, they bought top- of- the- line VCRs, about US$1000 each at the time. The VCRs had been in- house for less than a week before they started disappearing[3]....
[1] Yes, we had computers then.
[2] Pointy hair is timeless.
[3] I guess this was a self-solving problem, except that we had no working backup.
I think the key word for government sites is 'accessibility'.
Bullseye.
The rules for content are simple:
The users have to be able to find it.
The users have to be able to read it.
The first item means that you have to be really careful how you lay out your site navigation. Other posters have some good suggestions here. In particular, consider how your users will try to find things. Hint -- it aint by regulation number.
It is also important to provide your data in a usable form. Thomas is a particularly bad example here. This site lists bills before the US Congress. Unfortunately, the "real" text of the bills is almost invariably in the form of a diff to a current law; it's impossible to tell what's going on without reference to the original, and even then, it's not easy.
In terms of fancy layout, etc:
Take the graphic designers out and shoot them.
Delete all the fancy "web design" tools. Anybody who uses a tool more sophisticated than Homesite will be designated a "graphic designer" and shot. Anybody can learn enough HTML to format a basic page in about 10 minutes.
All testers must connect to your pages at no more than 14400 bits/sec. Broadband connections and local Ethernets are specifically forbidden.
In particular:
Don't make assumptions about your users' hardware or software. In particular, don't assume any particular screen size or browser.
No animation, Shockwave, graphics maps, Java, Javascript, background music, etc. Duh!
User defaults are your friend; style sheets are your enemy. In particular, don't mess with fonts. Every commercial site out there tries to force me to read a tiny, san-serif font. Every usability study I've ever seen shows that serif fonts (Times Roman, for example) are more readable.
Don't use tables for layout. They don't improve readability and they slow things down. Use tables for tables, and don't make assumptions about your users' screen size or resolution.
Use graphics only when necessary and keep them small. Use the minimum color and resolution that you can get away with. Don't forget the ALT tags.
Validate your HTML. There are a number of HTML validatiors out there; find one you like and use it. Amazing how often this gets forgotten....
Above all, look at it! Look at it with every browser you can find. Don't forget the old versions. (And don't forget Lynx.) Get some blind (excuse me, Visually Impared) testers if at all possible to "look" at it with screen magnifiers and screen readers. Look at it over slow lines.
Note that, depending on the laws in your area, you may have specific requirements that won't fit these (or probably, any) guidelines (line numbering, fonts, etc). In this case, you may be limited to letting folks download a PDF file. Even in this case you should be able to post your HTML regs "for information only" and tell people to refer to the PDF for the "real" regs.
Anyway, good luck! One advantage of the current crowd of crap Webpages is that it's easy to look good.
--
The biggest advantage of end-to-end networks (also called stupid networks) is their extreme scalability. You can set up a tiny little TCP/IP network at home; it works. We have the TCP/IP Internet; it works. Anything that requires central "intellegence" (read: control) will collapse, sooner or later, as the network expands. Doesn't matter if it is caused by a simple overload, a DoS attack, a terrorist bomb, or a court order. Hit the central server and it goes down.
The problem is that folks are trying to put services (like voice) that need realtime delivery onto a network that wasn't designed for it. In a straight IP based network, each router only needs resources for the packets that it is currently handling. As soon as a packet gets sent, the router's interest in it ends. A packet can (theoretically!) take any route at all through the network, and it's the endpoint's responsibility to put everything back together.
Anything else requires additional resources for each connection going through the router. For a backbone router, this is a *lot* of connections. It also means that each connection is "nailed" to a single route through the network. Lose a router and you not only lose the packets that it is storing at the time, but all the connections that it is handling. There are ways of handling this, of course, but the solutions are expensive, in terms of both hardware and bandwidth.
In my somewhat cynical opinion, what the providers want to do is take the simple "flat rate" model that the Internet is built on and turn it into what Scott Adams calls a "confusopoly", where the customer is never sure what services she is getting or what they're supposed to cost.
Combine this with the Government's desire (all governments) to monitor and control all communications, and you have the recipe for a real mess.
They go through Napster to find cuts with "their" particular MD5 checksum. Every ripper, of course, creates bit-by-bit identical.mp3 files (needed to get the same MD5).
Looks to me like it would be useful only for detecting stuff that was downloaded from a "legitimate" source (are there any?) and put unchanged onto Napster.
As soon as Napster starts letting the record companies run bots against their servers, they're dead meat. All the record companies have to do is look for people serving stuff that *might* be theirs, and then download it to check it out. Of course, they'll have to keep downloading it to see if it has changed. Bandwidth? What bandwidth?
That said, this is the main reason that Open Source programs for end users tend to look and work just like their Microsoft counterparts. Microsoft has done the work, and it shows.
Opinion: Linux won't get any real user market penetration until it produces something that isn't available slicker, smoother, and sooner from Microsoft.
Lately there seems to be a small but politically forceful faction in the company that wants us to move to MS Exchange for our entire e-mail system and standardize on MS Outlook for the desktop
Looks like it's a matter of politics, rather than anything technical. After all, your current system works well, so why change? I'll lay odds that, if you push them for reasons to convert to Exchange, you'll get a load of managementspeak babble that translates as "because I say so!"
As a political problem, it has to be dealt with in the political arena. Technical arguments will simply get ignored. Is another group trying to take over your mail opearion? Is somebody looking to hire a bunch of shiny new Microsoft droids and fire the longhaired hippy wierdo freak Unix types?
One friend of mine opines that Microsoft sales reps give blow jobs. It's a better explanation than most as to why companies pull damfool stupid stunts like this.
--
So freenet can't do everything. Big deal; it's not intended to. HTTP sucks at doing "real" dynamic content, too; that's why chat rooms, "news tickers" and suchlike are done as Java applets.
While you can't do full database lookup things, you could do versioning fairly easily by adding an "update key" to stuff that could be updated. This would be the owner's public key and a string encrypted with the owner's private key. When a message with the appropriate tag comes in to the local server, it supercedes the old information. It might simply add a "superceded by" pointer to the old version; there are good reasons for keeping old versions around, not the least of which is to guard against post-facto censorship. To get an old version, you simply add the version number to your request.
As to something like Slashdot, note that it is not really "dynamic" information. It is a sequence of static submissions. Submissions could simply be Freenet messages. The only thing that is really dynamic is the moderation scores. These could either live on a normal website or go out as frequently updated messages (see above) from the main site. Should be fairly easy to do a Java applet that pulls it all together. (It'll be a while before browsers unserstand "freenet://" URLs:-)
BTW, I'm not familiar with the exact architecture of Freenet, but I would assume that when you put a message into the system, your local system tags it as the "definitive" version. It is then outside of the LRU cache scheme. It may take a while to get it from elsewhere in the network, but it's there.
The big problem that I see with Freenet is that 95% (at least) of the data will be pr0n and warez. The pr0n and wares kiddies are collecters and love to play "minez bigger than yourz" games. If one of them has, say, 100 pirated versions of Microsoft Office, he'll happily pump them all into Freenet just for bragging rights. Other kiddies will check them out, and like as not, relabel and retransmit them.
There's no way that I can see to stop them; basically, it's a built-in denial of service attack.
Another vote for Opera here, or at least the 3.62 version.
Look at the "progress bar". In the left side, there are three little icons. The first simply tells you if you're using a secure connection. Click on the second one, and all the images go away. Ads? I don't see any ads.... Click on the third, and all the funky backgrounds and fonts go away, and you can look at the page in your own nice comfortable defaults instead of 4-point Barfbag Condensed dark blue on black, or whatever else some clueless Web designer wants you to use.
Yeah, you can do this in IE and Netscape -- if you can figure out where in the menu heirarchy they hid them. They do *not* make it easy.
Opera isn't perfect -- in particular, the V4's do not "turn off" font coloring properly. You have your default font, but it still may be light yellow, or whatever.
Also, Opera does crash on me occasionally, when I hit a particularly vile example of HTML design. Certain bad Javascript constructs seem to force a browser crash.
Adding buttons to the main menu bar to turn images, backgrounds, etc on and off shouldn't be too hard for the Galeon/K-Meleon/Mozilla stuff. I might do it myself. (0.5:-)
Please note that this benchmark (and any benchmark, for that matter) applies only to the system and application that it's testing. Database applications vary so widely that it's very difficult to get any meaningful numbers outside of very specific areas.
As an example, I recently ran some tests that came up with the exact opposite results. My application is a large message tracking database. Query speed is secondary; insertion speed is critical. MySQL handles my test data set in 20 minutes; PostgreSQL takes over 3 hours (!). For this application, PostgreSQL is Right Straight Out.
Other notes:
1. PostgreSQL's tables took up roughly twice the space of MySQL's.
2. MySQL's lack of transactions is a real pain. I can, however, work around it (in this particular application, at least).
3. MySQL's "text indexing" is useless. The evaluation function returns every record that contains any of the search terms; there is no way I've found to require all search terms. No documentation, of course.
4. The latest beta of MySQL can use Berkeley DB tables to get real transaction handling. Unfortunately, this is even slower than PostgreSQL.
Obvious conclusion: Run your own tests and draw your own conclusions.
Note that there was no disclosure of classified material here, just violations of Policy.
If you have a job to do, you do it. If you try to go through all of the Proper Authorities, you'll have long grey whiskers by the time you get their formal rejection.
I'd be willing to bet that the "authorized" software on the computers in question was some version of Windows, Microsoft Office, and a couple of buggy, inconvienent, locally written Visual Basic programs for filling out timesheets and accessing databases. And nothing else.
I'm sure every Slashdotter has a list of extra programs that need to be installed on any Windows system to make it halfway usable. (The last "unauthorized" program that I loaded was bzip2. Big scary threat, that.)
The point of "policy" is generally to cover the arses of the Powers the Be; if anything goes wrong, it's because "somebody violated Policy". I have worked in a number of secure environments; I have never seen one where *all* the Policies were followed. Scenario: You're the only one in the office when you are hit with A Sudden Need. Do you (a) Shit in your pants, (b) Carefully collect all of the classified data from your desk (and everybody elses desk, if you're watching their stuff for them) and lock it in the safe. Don't forget to sign the logs, or (c) duck down the hall to the loo and hope that nobody notices. Policy, of course, says (b), with (a) as the only alternative. Of course, (c) would leave your classified data open to any Soviet spies[1] who happened to sneak past the armed guards at the gate.
It's not just the Government; look up Randall Schwartz to see just how bad it can get.
[1] Yeah, I know. There hasn't been a Soviet Union for ten years. The US Department of Defense and State Department (the CIA is part of the State Department) have been busily trying to put it back together, as it was the only justification for their existance.
The author is saying that complete trustworthyness is unobtainable.
Duh!
There is no magic pixie dust that you can sprinkle on e-commerce (or anything else, for that matter) to make it "secure". You'll have a hard enough time just defining what "secure" really means for a given application.
The real question is, "is it good enough?". You are the only one who can answer that. Is what you are buying appropriate for your application?
One very big red flag is your comment that you are contemplating a "considerable investment". Sounds like somebody is trying to sell you a trainload of snake oil. The basics of PKI are not that complicated.
Personally, I'll trust a CA when they agree to be liable for consequential damages, ie, "We agree to pay any damages you've suffered caused by your reliance on our certificates". I'm not holding my breath.
Slashdot Mirror
(I hate it when that happens. I put in everything but the conclusion.)
IMHO, access lists are only useful to allow you to fill in the little checkbox on government/military procurement forms "access lists? (y/n)" with a "y"
Only way you're gonna get Linux into government/military stuff is to have access lists. Full stop. Therefore, ACLs are very useful (vital, actually) as a patch to some standard filesystem, just so you can check the little box. As to merging them into the kernel, forget it. They really accomplish nothing, and just get in the way.
--
Get over ACLs... they are a waste of time and programming effort.
... we get lost in an infinite regression.
IMHO, access lists are only useful to allow you to fill in the little checkbox on government/military procurement forms "access lists? (y/n)" with a "y". No access lists? Gotta use NT, because it has access lists. Why do we need access lists? The spec says so. Why does
Every attempt that I've seen to actually *use* access lists for anything useful has quickly degenerated into an unusable swamp.
Most Unix admins and users can't deal with the idea of separate groups for separate projects. You want them to try to figure out access lists?
Now, admittedly, standard Unix permissions are really lame. Unfortunately, access lists aren't the answer. Adding "capabilities" to Unix (the real way to fix the permission problem) would require enough changes that the resulting system couldn't really be called "Unix" anymore.
--
"Those who do not understand ASN.1 are condemned to reinvent it. Badly."
--SM
Seriously, after dealing with some of the butt-ugly binary encoding schemes out there, ASN.1 looks pretty darn good.
As others have pointed out, however, ASN.1 and XML live in totally different domains. ASN.1 is not human-readable, and XML is useless for binary data.
--
What is wrong with all these slashdotters that think NASA needs to be cut all together. Exploration is at the heart of what the human race does. If the same attitude was taken hundreds of years ago, the USA would never have been discovered ...
If NASA had been in charge of exploring the Atlantic Ocean in the 1400s - 1500s, they'd still be taking soundings off the Azores to make sure they wouldn't run into something unexpected.
In order to explore, you must take risks.
If we want to "explore space", we need an outfit that will do it (or at least get out of the way). NASA puts bureaucratic arse-covering above exploration.
--
This started me thinking about Unisys.
Does anybody know of a single large system that they've built that actually worked as designed and was done on time and on budget?
Everything I've heard about them is bad. "Death marches". Systems cancelled after the customer spent (mumble) millions of dollars. Severe specification downgrades. Lawsuits trying to get paid.
They're one of the US Government's biggest suppliers. Is anybody surprised?
--
The W3C lives in a fantasy world where we all have good WYSIWYG tools for doing all of our HTML design. Complexity doesn't matter, as the tools handle it all for us. Unfortunately, at the current state of the art, the good tools suck and the bad tools (which everybody seems to use) produce HTML of Lovecraftian horror. We're gonna be doing it (or at least cleaning it up) by hand for a long time, folks.
MathML is another one of those things that tries to be all things to all people, all at the same time. Result is yet another markup language trying to be a page description language.
As a counter suggestion, how about something based on the old eqn preprocessor for troff? Simple and easy to understand, and far more in the "content, not format" spirit than MathML. Brian Kernighan was supposedly working on something like this. Any news?
--
that you will have to have a MSN account to use this. Don't expect the marketing droids to ever give up.
Then there's the security aspect. "Microsoft has installed monitoring software, with man-in-the-middle cacheing for SSL, for your Web surfing and e-mail convienence."
Skroom. By Seattle standards, at least, Starbuck's is bottom shelf coffee anyway.
--
Of course the Manhatten Project had computers! Remember, at that time "computer" was a job description and not a piece of hardware.
....
Richard Feynman describes punch-card computers on the Manhatten Project in "Surely You're Joking, Mr. Feynman". Admittedly, calling them "computers" is a stretch, but they did do mathematical operations on numbers punched into cards. Output was more punched cards. They used *a lot* of cards
--
Or you can do it the easy and expensive way, and just pay some starving Russian/Ukranian/ Belarusian/whatever techs for some bomb parts.
Anybody who doesn't have their own stash of weapons-grade plutonium by now probably doesn't want any.
--
I saw a news item a while back about the Administration's attempts to keep people from exporting supercomputers to China.
"Why?" ran the question. "What can they do with a supercomputer"?
"Military weather prediction" was the answer.
"What about nuclear weapon design?"
"Nuclear weapon design is no longer considered computationally significant."
Yeesh.
The most advamced computers on the Manhattan Project ran on punched cards. Most of our current inventory of nukes were designed on machines less powerful than a low-end desktop.
Fortunately, manufacture of nukes is *considerably* more difficult than design. Plutonium is spectacularly difficult to deal with.
--
Yup. I've seen too much of it, too. Don't forget that the programmers (the guys on the bottom) get blamed for anything that goes wrong. The managers (at all levels) have their Teflon suits on.
Now go back and assume your project is a bridge instead of a program. Nobody within hollering distance of their right mind would put up with this kind of crap. Build a bridge that way, and it will collapse. Very publicly.
What's the difference? Only about 4000 years of experience. People in the management chain have a feel for what is needed for a bridge to "work", and know that they can't interfere in the process without risking disaster.
Software is newer and much harder to quantify. A bridge either falls down or it doesn't. A computer system has zillions of "degraded" modes that it can get into and still sorta work. It can be really hard to tell if a program is meeting its goals.
Because of this, managers can get away with all manner of crap. Software engineering will not be a real engineering field until a typical "software engineer" can say something to his manager like "Testing is going to take six weeks, period. I don't care if you miss Comdex, it doesn't get released until it goes through Test, and that will take six weeks." *AND HAVE IT STICK*.
I'm not holding my breath.
--
Excuse me?
Your list of questions applies to *any* engineering field. You need to ask the same questions if you're building a bridge. Does this mean that we should try to keep the field of "engineering" from fragmenting? Sorry; it already has.
"Software engineering" (somewhat of an oxymoron, IMHO) will fragment, just like any other field, as the skill sets needed for the various aspects of programming drift apart. Would you want a pacemaker designed by a video game programmer? Would you want a video game designed to medical implant standards?
BTW, your last question is not really a matter of engineering, software or otherwise. How does a pacemaker "decrease the amount of repetitive work that humans have to do"?
--
Back in the early/mid 1980s[1], I got burned by one of these. It backed up a PDP-11/23 to a VHS VCR. Management[2] bought into this as our only backup for the 11/23s.
....
The first test I ran was simple:
1. Make a full backup
2. Delete a file
3. Restore the file from the backup
It didn't work. All it did was read through the entire tape and report "restore unsuccessful". No useful info. Bad tape? Maybe, but I tried with a couple of different tapes. My guess was that the software was only capable of handling "full partition" backup and restore, despite what the manual said. I assume (with no evidence) that *somebody* ran *some* tests before they bought into this.
To add insult to injury, they bought top- of- the- line VCRs, about US$1000 each at the time. The VCRs had been in- house for less than a week before they started disappearing[3]
[1] Yes, we had computers then.
[2] Pointy hair is timeless.
[3] I guess this was a self-solving problem, except that we had no working backup.
--
I think the key word for government sites is 'accessibility'.
Bullseye.
The rules for content are simple:
The first item means that you have to be really careful how you lay out your site navigation. Other posters have some good suggestions here. In particular, consider how your users will try to find things. Hint -- it aint by regulation number.
It is also important to provide your data in a usable form. Thomas is a particularly bad example here. This site lists bills before the US Congress. Unfortunately, the "real" text of the bills is almost invariably in the form of a diff to a current law; it's impossible to tell what's going on without reference to the original, and even then, it's not easy.
In terms of fancy layout, etc:
In particular:
Above all, look at it! Look at it with every browser you can find. Don't forget the old versions. (And don't forget Lynx.) Get some blind (excuse me, Visually Impared) testers if at all possible to "look" at it with screen magnifiers and screen readers. Look at it over slow lines.
Note that, depending on the laws in your area, you may have specific requirements that won't fit these (or probably, any) guidelines (line numbering, fonts, etc). In this case, you may be limited to letting folks download a PDF file. Even in this case you should be able to post your HTML regs "for information only" and tell people to refer to the PDF for the "real" regs.
Anyway, good luck! One advantage of the current crowd of crap Webpages is that it's easy to look good.
--
The biggest advantage of end-to-end networks (also called stupid networks) is their extreme scalability. You can set up a tiny little TCP/IP network at home; it works. We have the TCP/IP Internet; it works. Anything that requires central "intellegence" (read: control) will collapse, sooner or later, as the network expands. Doesn't matter if it is caused by a simple overload, a DoS attack, a terrorist bomb, or a court order. Hit the central server and it goes down.
The problem is that folks are trying to put services (like voice) that need realtime delivery onto a network that wasn't designed for it. In a straight IP based network, each router only needs resources for the packets that it is currently handling. As soon as a packet gets sent, the router's interest in it ends. A packet can (theoretically!) take any route at all through the network, and it's the endpoint's responsibility to put everything back together.
Anything else requires additional resources for each connection going through the router. For a backbone router, this is a *lot* of connections. It also means that each connection is "nailed" to a single route through the network. Lose a router and you not only lose the packets that it is storing at the time, but all the connections that it is handling. There are ways of handling this, of course, but the solutions are expensive, in terms of both hardware and bandwidth.
In my somewhat cynical opinion, what the providers want to do is take the simple "flat rate" model that the Internet is built on and turn it into what Scott Adams calls a "confusopoly", where the customer is never sure what services she is getting or what they're supposed to cost.
Combine this with the Government's desire (all governments) to monitor and control all communications, and you have the recipe for a real mess.
--
They go through Napster to find cuts with "their" particular MD5 checksum. Every ripper, of course, creates bit-by-bit identical .mp3 files (needed to get the same MD5).
Looks to me like it would be useful only for detecting stuff that was downloaded from a "legitimate" source (are there any?) and put unchanged onto Napster.
As soon as Napster starts letting the record companies run bots against their servers, they're dead meat. All the record companies have to do is look for people serving stuff that *might* be theirs, and then download it to check it out. Of course, they'll have to keep downloading it to see if it has changed. Bandwidth? What bandwidth?
--
You're telling me that Clippy survived this??
That said, this is the main reason that Open Source programs for end users tend to look and work just like their Microsoft counterparts. Microsoft has done the work, and it shows.
Opinion: Linux won't get any real user market penetration until it produces something that isn't available slicker, smoother, and sooner from Microsoft.
--
Lately there seems to be a small but politically forceful faction in the company that wants us to move to MS Exchange for our entire e-mail system and standardize on MS Outlook for the desktop
Looks like it's a matter of politics, rather than anything technical. After all, your current system works well, so why change? I'll lay odds that, if you push them for reasons to convert to Exchange, you'll get a load of managementspeak babble that translates as "because I say so!"
As a political problem, it has to be dealt with in the political arena. Technical arguments will simply get ignored. Is another group trying to take over your mail opearion? Is somebody looking to hire a bunch of shiny new Microsoft droids and fire the longhaired hippy wierdo freak Unix types?
One friend of mine opines that Microsoft sales reps give blow jobs. It's a better explanation than most as to why companies pull damfool stupid stunts like this.
--
So freenet can't do everything. Big deal; it's not intended to. HTTP sucks at doing "real" dynamic content, too; that's why chat rooms, "news tickers" and suchlike are done as Java applets.
:-)
While you can't do full database lookup things, you could do versioning fairly easily by adding an "update key" to stuff that could be updated. This would be the owner's public key and a string encrypted with the owner's private key. When a message with the appropriate tag comes in to the local server, it supercedes the old information. It might simply add a "superceded by" pointer to the old version; there are good reasons for keeping old versions around, not the least of which is to guard against post-facto censorship. To get an old version, you simply add the version number to your request.
As to something like Slashdot, note that it is not really "dynamic" information. It is a sequence of static submissions. Submissions could simply be Freenet messages. The only thing that is really dynamic is the moderation scores. These could either live on a normal website or go out as frequently updated messages (see above) from the main site. Should be fairly easy to do a Java applet that pulls it all together. (It'll be a while before browsers unserstand "freenet://" URLs
BTW, I'm not familiar with the exact architecture of Freenet, but I would assume that when you put a message into the system, your local system tags it as the "definitive" version. It is then outside of the LRU cache scheme. It may take a while to get it from elsewhere in the network, but it's there.
The big problem that I see with Freenet is that 95% (at least) of the data will be pr0n and warez. The pr0n and wares kiddies are collecters and love to play "minez bigger than yourz" games. If one of them has, say, 100 pirated versions of Microsoft Office, he'll happily pump them all into Freenet just for bragging rights. Other kiddies will check them out, and like as not, relabel and retransmit them.
There's no way that I can see to stop them; basically, it's a built-in denial of service attack.
--
Another vote for Opera here, or at least the 3.62 version.
.... Click on the third, and all the funky backgrounds and fonts go away, and you can look at the page in your own nice comfortable defaults instead of 4-point Barfbag Condensed dark blue on black, or whatever else some clueless Web designer wants you to use.
:-)
Look at the "progress bar". In the left side, there are three little icons. The first simply tells you if you're using a secure connection. Click on the second one, and all the images go away. Ads? I don't see any ads
Yeah, you can do this in IE and Netscape -- if you can figure out where in the menu heirarchy they hid them. They do *not* make it easy.
Opera isn't perfect -- in particular, the V4's do not "turn off" font coloring properly. You have your default font, but it still may be light yellow, or whatever.
Also, Opera does crash on me occasionally, when I hit a particularly vile example of HTML design. Certain bad Javascript constructs seem to force a browser crash.
Adding buttons to the main menu bar to turn images, backgrounds, etc on and off shouldn't be too hard for the Galeon/K-Meleon/Mozilla stuff. I might do it myself. (0.5
--
But "nonzero relevance" doesn't mean "contains all terms"! Go back to the docs and take a careful look at the examples they give.
The only use I've found for the full text search is in ordering items found by other means. Marginal utility, at best.
It would also be nice if they gave a little formula somewhere for the "relevance". What's it really measuring?
--
Yup. The results have the BEGIN/COMMIT brackets in there. You're right; it does make a really big difference.
Question is moot, anyway. We'll probably just stuff everything into a flat file and forget about "online response" (:-(.
--
Please note that this benchmark (and any benchmark, for that matter) applies only to the system and application that it's testing. Database applications vary so widely that it's very difficult to get any meaningful numbers outside of very specific areas.
As an example, I recently ran some tests that came up with the exact opposite results. My application is a large message tracking database. Query speed is secondary; insertion speed is critical. MySQL handles my test data set in 20 minutes; PostgreSQL takes over 3 hours (!). For this application, PostgreSQL is Right Straight Out.
Other notes:
1. PostgreSQL's tables took up roughly twice the space of MySQL's.
2. MySQL's lack of transactions is a real pain. I can, however, work around it (in this particular application, at least).
3. MySQL's "text indexing" is useless. The evaluation function returns every record that contains any of the search terms; there is no way I've found to require all search terms. No documentation, of course.
4. The latest beta of MySQL can use Berkeley DB tables to get real transaction handling. Unfortunately, this is even slower than PostgreSQL.
Obvious conclusion: Run your own tests and draw your own conclusions.
--
Note that there was no disclosure of classified material here, just violations of Policy.
If you have a job to do, you do it. If you try to go through all of the Proper Authorities, you'll have long grey whiskers by the time you get their formal rejection.
I'd be willing to bet that the "authorized" software on the computers in question was some version of Windows, Microsoft Office, and a couple of buggy, inconvienent, locally written Visual Basic programs for filling out timesheets and accessing databases. And nothing else.
I'm sure every Slashdotter has a list of extra programs that need to be installed on any Windows system to make it halfway usable. (The last "unauthorized" program that I loaded was bzip2. Big scary threat, that.)
The point of "policy" is generally to cover the arses of the Powers the Be; if anything goes wrong, it's because "somebody violated Policy". I have worked in a number of secure environments; I have never seen one where *all* the Policies were followed. Scenario: You're the only one in the office when you are hit with A Sudden Need. Do you (a) Shit in your pants, (b) Carefully collect all of the classified data from your desk (and everybody elses desk, if you're watching their stuff for them) and lock it in the safe. Don't forget to sign the logs, or (c) duck down the hall to the loo and hope that nobody notices. Policy, of course, says (b), with (a) as the only alternative. Of course, (c) would leave your classified data open to any Soviet spies[1] who happened to sneak past the armed guards at the gate.
It's not just the Government; look up Randall Schwartz to see just how bad it can get.
[1] Yeah, I know. There hasn't been a Soviet Union for ten years. The US Department of Defense and State Department (the CIA is part of the State Department) have been busily trying to put it back together, as it was the only justification for their existance.
--
The author is saying that complete trustworthyness is unobtainable.
Duh!
There is no magic pixie dust that you can sprinkle on e-commerce (or anything else, for that matter) to make it "secure". You'll have a hard enough time just defining what "secure" really means for a given application.
The real question is, "is it good enough?". You are the only one who can answer that. Is what you are buying appropriate for your application?
One very big red flag is your comment that you are contemplating a "considerable investment". Sounds like somebody is trying to sell you a trainload of snake oil. The basics of PKI are not that complicated.
Personally, I'll trust a CA when they agree to be liable for consequential damages, ie, "We agree to pay any damages you've suffered caused by your reliance on our certificates". I'm not holding my breath.
--