I believe people interact with periodical articles in a fundamentally different way to normal email, and that email newsletters lead people into trying to handle both of them in the same way, resulting in chaos
I agree. I did a similar input reduction on my inbox a year or two ago. Nielsen received a special exception ticket, but not without some ironic reflection on the lack of usability options he provides to his readers. I understand the argument against too many options, but in this case they are not mutually interfering, so I think he's making a mistake by adhering so strongly to his Viewpoint.
That page describes exactly what's wrong with qmail, by the way..
Rejecting at RCPT TO is a completely valid thing to do. Going through all of those hoops to make it happen is offputting for 99% of mail admins. Some of us remember when all UNIX software was like this (autoconf is for wimps!), and it doesn't bother us much. But the vast majority of people who install MTAs these days are not going to make the effort -- by the time they have the knowledge necessary, they already have a preferred MTA that is good enough....and that's just for adding one simple feature. Navigating qmail.org to pick out the patches that are of interest to you (from the hundreds of varying quality and duplication and/or conflict) to make your own tarfile for use on your systems is completely out of the question for most people (which makes a lot of sense in many situations, supportability and administrative succession being important after all).
Some of us have the liberty of not worrying about that and/or imposing our will (hopefully informed by acquired and still valid experience) on others. In most other situations, qmail is a hard sell. Which is sad, becuase I think qmail is one of the best examples of how to design qualty software, and I wish more people would use it to learn and teach from....and it's also a great MTA.
It occurs to me that qmail is probably the betamax of MTAs. It was a technically solid option, but required a larger initial investment, wasn't spread or marketed effectively, and was eventually made irrelevant by DVDs. Only the purists and iconoclasts hung on despite the overwhelming inertia, and they are best remembered for their disillusioned sputtered claims of superiority. Hmm. Maybe it's time to start reading up on exim.
The last line tells qmail-send to flush the queue, and since the bad messages are now touched into ancient history, qmail will stop trying to deliver them. Qmail is up and delivering the whole time.
There are other occasions when stopping qmail is necessary though.. I usually stop qmail-send and keep qmail-smtpd receiving.
But I definitely sympathize with your position.. Qmail is great, but SOMEONE ELSE'S qmail build sounds like a nightmareto support. I've never had to deal with that situation, but I'd just reassess the requirements and drop in my own binary and config to fit the need. This is a problem with the distribution style and community around qmail...and it can probably be blamed on djb's ideology.
I have heard good things about Exim, but I've never run into an insoluble problem with qmail, so I haven't had a motivation to look into it deeply. I did spend some time looking into Postfix once, but I was put off by the "drop-in replacement for sendmail" design style. It felt awkward to me, and again I had no motivation to desert qmail.
In the old days (up to and including the early 90s), the job of an MTA was a complicated one. You had to accept and deliver mail via several different protocols, using various types of gateways, etc.
By the early 90s, the Internet itself was almost completely settled on SMTP, but internal mail hosts weren't necessarily. I remember spending a few days reworking sendmail.cf for address rewriting to deliver gatewayed SMTP mail to an internal Lotus Notes server.
The beauty of sendmail was that there was almost always a way to do whatever screwed up thing you needed it to do. The downside, of course, was that that level of capability came at the expense of complexity.
M4: Configuring sendmail with M4 was for newbies back then. Yes, it worked most of the time for simple cases, but when you actually needed to do something more difficult than setting up a smarthost gateway, it fell on its face. Sendmail.cf was complex, but we are smart people, are we not? All those lines did something, and they were well documented. It wasn't a lunch-break job to make significant changes...but I agree with the submitter -- it was a valid litmus test of an admin's experience (and self-confidence).
Sendmail always had security problems, again due to its complexity. Sometime in the mid 90s, the reality of the situation became clear: SMTP wins, and any code that isn't for supporting SMTP is extra code that might be the cause of security problems. Sendmail was too big to die (and later, Sendmail, Inc. had other clear reasons for sticking to their path), but other MTAs emerged.
My favorite then (and still now) is qmail. I've been running qmail on hundreds of servers since 1996, and I appreciate almost everything about it. The codebase is small, well-written, fast, and once you figure out how everything works together, simple. Qmail requires a certain level of experience to admin -- there hasn't been a new version released since 1998 or so(?), and changing the config to handle spam filtering, etc, requires a solid understanding of UNIX and sometimes the ability to read a diff and decide if the patch author does things properly.
Qmail gets overlooked often because the website is completely impenetrable to most. There are other decent MTAs that do a much better job of promoting themselves. But qmail is still an excellent choice for UNIX admins who know their stuff...and no MTA is a good choice for a UNIX admin that doesn't know their stuff.
This comes up every few months in one forum or another, and there usually seems to be a 50/50 split between the purists and the... "pragmatists" (I'm being generous).
To see that the slashdot population (or at least the pop with moderation privs today) has finally mustered up a solid consensus in favor of standards-based design is excellent news.
Sure, there are the outlying "my boss says only IE matters" and "tables were good enough for 1996, so they're good enough for me" folks, but they're just faux-nostalgic fear-of-change types. Attrition is inevitable.
This is the best and most interesting news I've read on slashdot in a long time.
I agree -- that bit of the article seemed rather poorly researched.
But, looking back at the real history, there are a few reasons it didn't attract wider usage several years ago.
Something like XMLHttpRequest had been on the minds of many people for a few years. While we diddled around about how to do it in a general cross-platform way, Microsoft went ahead and added their idea of how it should work. Unfortunately, it was available in WinIE only, and they wrapped it up in their ActiveX framework, which most web developers knew better than to get messed up with.
The Mozilla people saw through the shadows though, and it was added to the tree before Mozilla 1.0...if you remember how long the wait was for that release, you can understand why it looks like Mozilla was playing catch up.
After that, it was a marketing failure (coupled with a few years of total web stagnation). MS only seemed to think it was important enough for WinIE, and Mozilla adoption was slow. Back then, it wasn't considered ridiculous for web developers to use WinIE for anything other than testing, but ActiveX was (correctly) considered evil.
So to those of you who claim that it's been around forever and JJG doesn't deserve any credit for calling it "AJAX" and making it famous... You're all wet. Marketing failures are still failures. Just because Uranium has been around since the dawn of time doesn't mean nuclear fission isn't a potent technology.
PS: To be pedantic, the "XMLHttpRequest class" was invented by Mozilla. The ActiveX object "Microsoft.XMLHTTP", and the associated interface was invented by MS. (Which might explain why a return code of "4" means "completed, everything OK"..., but I digress.)
Re:Computer from scratch...
on
Makers
·
· Score: 1
You left out the steps where you:
refine petroleum to make plastic for IC bodies
mine metal ores to make IC legs and board traces
grow SiO2 crystals to etch into IC dies
etc.
Given that the manufacturing of a pencil is this complicated, the phrase "from scratch" ceases to have much meaning for anything more complex than, say, fruit salad.
(And the Sun, birds, and bees might have a thing or two to say about that...)
Residential power distribution methods vary, but most single phase lines are about 7200VAC.. 240VAC is supplied to the house via a pair of 120VAC lines, 180degrees out of phase from each other. Breaker panels send one of the feeders to each half of the breakers in the house, which is why it's possible to lose power to only half of your house...
Commercial distribution is three phase 120/240VAC, 120/208VAC or 480VAC, depending on the customer.
Other than that...your BPL "broadcast domain" *might* be larger than your house, depending on how the BPL networks are designed.
Maybe you're thinking of the old X10 problem, where two houses (sometimes more) would be on the same secondary winding of a step down transformer, so signals would be shared between them.
I don't know exactly how BPL networks are designed, but the data has to traverse multiple high and low voltage lines and cross multiple transformers...so there have to be repeaters/bridges/routers (or things that resemble them) along the way, and the opportunity exists to isolate network branches wherever desired.
The least expensive design would look like first-gen cable internet, but it's at least possible that they've learned from those mistakes...
Their taxes must be awfully complicated, running parallel businesses with different regulatory compliances.
I think the days are over when big companies with lots of cash can pretend to be wholly ignorant of things in the computer world, hoping the judge will be too. It's too easy to find expert witnesses that make you look like idiots and/or liars. Time for a policy change, methinks.
You have to wonder about a profession that encourages its practitioners to feign ignorance.
Just be careful, because WWW-RW and WWW+RW each only work in certain browsers, and if you accidentally browse to the wrong kind of website because you didn't notice the stupid 2-pixel difference, CompUSA isn't going to give you your time back.
Better yet, instead of requiring a new manual process..
Keep the current system, but give each article an "update waiting period", based on the article's recent volatility. An article that never gets changed might be 24 hours. An active one might be 30 minutes. A very active one might be 5 minutes.
Whenever an article is modified, the new version doesn't become the "current" version until the waiting period has passed. The article police will have a window in which to fix things, and the vandalism incentive (instant gratification) will go way down.
A simple version of this idea (all articles have the same update waiting period) could be implemented very quickly. A more complex version (period based on volatility) might not even add any value. Either way, no additional processes or people or work would be required, and the problem would be largely solved.
The reason it took five years to build Mozilla is that in the early days of the web, the primary developers of the leading browser (Mosaic) went private (Netscape) and abandoned their original open source project. Then as the web exploded, they were the only ones positioned to keep up with the changes (and drive some of them with proprietary extensions to HTML, etc).
Microsoft entered the game and made some smart (and some illegal) moves, while Netscape was grossly mismanaged and unresponsive. Eventually, they were persuaded from within to open the source to Navigator, but it was a horrific mess and made volunteer participants *very* hard to find.
By now, a browser was not a simple application. It was a big project, and the decision to "start over" on Mozilla was some serious drama. A couple of false starts later, a development model that worked coalesced into existence, but even then it took the focus of the Firefox project to bring a popular product to market.
Point being: if Mosaic had continued to be developed instead of abandoned at the beginning of the explosion of the web, it wouldn't have taken any time to "catch up" with IE6. Even if the original team hadn't been able to find a working development model, someone else would have and forked the codebase to get there.
But you're right. The lack of marketing-driven deadlines does allow for superior product, eventually. Imagine if the Internet was developed "in time for the Christmas shopping season, and 4th quarter earnings!"
You can't "crack" a hash, by definition. If you could, md5 would the most incredible compression algorithm ever discovered.
A hash is considered weak if it has collisions: when more than one plaintext results in an identical hash value. Hashes are usually used for verification, so non-unique results are a critical failure.
Attacks against hashed passwords are done by brute force. The mitigation against this attack is to use a salted hash, which adds a few bytes of randomness to the password.
The extra bits of randomness make it exponentially (^16, ^24, ^32, usually) more difficult to pregenerate a hash results dictionary. However, they don't make it any harder to brute force a single password, after the hashed version is obtained.
They make and sell copies of famous statues for those who can't conquer the countries that own the originals. You can get them with or without the fig leaf.
The NYT used a figged copy of the Farnese Atlas for their story photo.
It's lame, but pretty much everyone everywhere does the same thing when given a chance.
Think of all the things people could do with the energy they'd save if they just didn't bother to get offended by unimportant things...
Apple introduced Desktop Accessories in 1984. At the time, MacOS (then just called the "System") wasn't multitasking, so DAs were a way to run "something else" without closing your running application.
Some examples: Calculator, Alarm Clock (later, the clock moved to the menu bar), Key Caps (so you could find all the non-standard keyboard characters like the Yen symbol, etc), Puzzle, Scrapbook (like multiple, persistent copy buffers), Notepad (like Stickies), Chooser (to select printers and networks), etc. Yup, 1984.
They all lived under the Apple menu, and could be used at any time. They required some unusual constraints to WRITE, however...but Apple provided some decent sample code and shareware developers wrote hundreds more of them.
After MacOS became preemptively multitasking, the only reason DAs stuck around is that users expected them. There was no longer a good reason to code within the DA frameworks, (and by then you could put any app you wanted into the Apple menu, so that was no longer unique..)
Dashboard is not a knock-off. It's a reintroduction of Apple's own good idea from twenty years ago. As for the naming choice -- well, I think it's dumb...but it doesn't make sense to claim that that's stolen either. There is no more generic term for a small, useful thing. Widgets will be more powerful than DAs and easier to write, but that's a function of the intervening time, not stolen inspiration.
Dashboard is also interesting because the applets (see?) are like Desk Accessories, but the use model appears to be Apple's first admission that virtual desktops might be a GOOD IDEA that users are capable of understanding (when presented in a very animated-so-you-know-whats-happening-at-all-times kind of way). That's a big step for Apple HIG!
Next stop, multi-button mouses, STANDARD!
I only worry that with Expose and Dashboard, Apple might decide that users are all tapped out in the weird-things-that-happen-to-my-desktop department and never implement virtual desktops themselves.
(Though I'm pretty happy with Virtue. Look it up on version tracker.)
FYI, that's "MAEs", as in MAE-East, MAE-West(!), and MAE-Central.
MAE stands for Metropolitan Area Exchange, and they used to be hugely important parts of the primary backbone of the NSF Internet, along with other peering points called NAPs.
They still route a lot of traffic, but as a percentage of the whole, much less than ten years ago.
"MAE" appears to now be a trademark of MCI, and they claim it is not an acronym...but that's revisionist history, at best. I was there.
Doesn't it seem like "exploiting customers by fraudulent means" should carry a heavier sentence than this?
Microsoft has smart lawyers, and California's lawyers apparently rolled over and played dead, after making a good show of pursuing the case after most others had dropped it.
But let's look at this...Microsoft's lawyers negotiated a settlement whereby:
1. claimants have to produce and file an old receipt for purchase of software. (dropoff percentage upward of 75%, for sure)
2. claimants receive a VOUCHER FOR FUTURE PURCHASES of computer stuff. (dropoff percentage at least 50%)
3. claimants have to send all that paperwork to a claim management company to get their real money (dropoff percentage at least 30% -- would be much higher, but any customer who is this far along can be presumed to be motivated...)
and lastly, the icing on the cake:
4. two-thirds of unclaimed funds are donated, by Microsoft, to California schools in the form of computer hardware and software. The software, of course, has zero incremental cost to Microsoft except in lost sales to CA schools, but even more importantly...there is no donation better spent than a donation to kids. Get them early, get them for life.
What ever happened to: "You screwed the plaintiffs over. Make full restitution now or go to jail."?
Slashdot Mirror
While we're asking rhetorical questions, how do you find time in your busy life to be offended by words, much less letters?
I believe people interact with periodical articles in a fundamentally different way to normal email, and that email newsletters lead people into trying to handle both of them in the same way, resulting in chaos
I agree. I did a similar input reduction on my inbox a year or two ago. Nielsen received a special exception ticket, but not without some ironic reflection on the lack of usability options he provides to his readers. I understand the argument against too many options, but in this case they are not mutually interfering, so I think he's making a mistake by adhering so strongly to his Viewpoint.
I ended up forcing alertbox into an RSS feed via feed43.com. The feed should be accessible by anyone: http://feed43.com/3442002452423878.xml
Like for everything else in qmail, there's a patch..
m l
...and that's just for adding one simple feature. Navigating qmail.org to pick out the patches that are of interest to you (from the hundreds of varying quality and duplication and/or conflict) to make your own tarfile for use on your systems is completely out of the question for most people (which makes a lot of sense in many situations, supportability and administrative succession being important after all).
...and it's also a great MTA.
To reject mail at RCPT TO, I use John Simpson's patch to the validrcptto patch:
http://qmail.jms1.net/patches/validrcptto.cdb.sht
That page describes exactly what's wrong with qmail, by the way..
Rejecting at RCPT TO is a completely valid thing to do. Going through all of those hoops to make it happen is offputting for 99% of mail admins. Some of us remember when all UNIX software was like this (autoconf is for wimps!), and it doesn't bother us much. But the vast majority of people who install MTAs these days are not going to make the effort -- by the time they have the knowledge necessary, they already have a preferred MTA that is good enough.
Some of us have the liberty of not worrying about that and/or imposing our will (hopefully informed by acquired and still valid experience) on others. In most other situations, qmail is a hard sell. Which is sad, becuase I think qmail is one of the best examples of how to design qualty software, and I wish more people would use it to learn and teach from.
It occurs to me that qmail is probably the betamax of MTAs. It was a technically solid option, but required a larger initial investment, wasn't spread or marketed effectively, and was eventually made irrelevant by DVDs. Only the purists and iconoclasts hung on despite the overwhelming inertia, and they are best remembered for their disillusioned sputtered claims of superiority. Hmm. Maybe it's time to start reading up on exim.
Dude.
The web browser was invented in Switzerland.
It was improved in Illinois,
commercialized in Silicon Valley,
strangled in Redmond,
and ressurected from scrap DNA by multiple teams worldwide.
You do the equivalent in qmail:
/var/qmail/queue/mess ../info ; xargs touch -c -t 200001010000 )
devise some method of determining good/bad messages in the queue,
mark them for deletion
tell qmail to do it
e.g., in BSD:
cd
grep -rl "BADMESSAGES" . | ( cd
killall -ALRM qmail-send
The last line tells qmail-send to flush the queue, and since the bad messages are now touched into ancient history, qmail will stop trying to deliver them. Qmail is up and delivering the whole time.
There are other occasions when stopping qmail is necessary though.. I usually stop qmail-send and keep qmail-smtpd receiving.
But I definitely sympathize with your position.. Qmail is great, but SOMEONE ELSE'S qmail build sounds like a nightmareto support. I've never had to deal with that situation, but I'd just reassess the requirements and drop in my own binary and config to fit the need. This is a problem with the distribution style and community around qmail...and it can probably be blamed on djb's ideology.
I have heard good things about Exim, but I've never run into an insoluble problem with qmail, so I haven't had a motivation to look into it deeply. I did spend some time looking into Postfix once, but I was put off by the "drop-in replacement for sendmail" design style. It felt awkward to me, and again I had no motivation to desert qmail.
In the old days (up to and including the early 90s), the job of an MTA was a complicated one. You had to accept and deliver mail via several different protocols, using various types of gateways, etc.
By the early 90s, the Internet itself was almost completely settled on SMTP, but internal mail hosts weren't necessarily. I remember spending a few days reworking sendmail.cf for address rewriting to deliver gatewayed SMTP mail to an internal Lotus Notes server.
The beauty of sendmail was that there was almost always a way to do whatever screwed up thing you needed it to do. The downside, of course, was that that level of capability came at the expense of complexity.
M4: Configuring sendmail with M4 was for newbies back then. Yes, it worked most of the time for simple cases, but when you actually needed to do something more difficult than setting up a smarthost gateway, it fell on its face. Sendmail.cf was complex, but we are smart people, are we not? All those lines did something, and they were well documented. It wasn't a lunch-break job to make significant changes...but I agree with the submitter -- it was a valid litmus test of an admin's experience (and self-confidence).
Sendmail always had security problems, again due to its complexity. Sometime in the mid 90s, the reality of the situation became clear: SMTP wins, and any code that isn't for supporting SMTP is extra code that might be the cause of security problems. Sendmail was too big to die (and later, Sendmail, Inc. had other clear reasons for sticking to their path), but other MTAs emerged.
My favorite then (and still now) is qmail. I've been running qmail on hundreds of servers since 1996, and I appreciate almost everything about it. The codebase is small, well-written, fast, and once you figure out how everything works together, simple. Qmail requires a certain level of experience to admin -- there hasn't been a new version released since 1998 or so(?), and changing the config to handle spam filtering, etc, requires a solid understanding of UNIX and sometimes the ability to read a diff and decide if the patch author does things properly.
Qmail gets overlooked often because the website is completely impenetrable to most. There are other decent MTAs that do a much better job of promoting themselves. But qmail is still an excellent choice for UNIX admins who know their stuff...and no MTA is a good choice for a UNIX admin that doesn't know their stuff.
This comes up every few months in one forum or another, and there usually seems to be a 50/50 split between the purists and the ... "pragmatists" (I'm being generous).
To see that the slashdot population (or at least the pop with moderation privs today) has finally mustered up a solid consensus in favor of standards-based design is excellent news.
Sure, there are the outlying "my boss says only IE matters" and "tables were good enough for 1996, so they're good enough for me" folks, but they're just faux-nostalgic fear-of-change types. Attrition is inevitable.
This is the best and most interesting news I've read on slashdot in a long time.
> If something is really weird, why is it supernatural?
Everyone in an English-speaking country should be required to take one year of high school Latin before graduating.
I agree -- that bit of the article seemed rather poorly researched.
But, looking back at the real history, there are a few reasons it didn't attract wider usage several years ago.
Something like XMLHttpRequest had been on the minds of many people for a few years. While we diddled around about how to do it in a general cross-platform way, Microsoft went ahead and added their idea of how it should work. Unfortunately, it was available in WinIE only, and they wrapped it up in their ActiveX framework, which most web developers knew better than to get messed up with.
The Mozilla people saw through the shadows though, and it was added to the tree before Mozilla 1.0...if you remember how long the wait was for that release, you can understand why it looks like Mozilla was playing catch up.
After that, it was a marketing failure (coupled with a few years of total web stagnation). MS only seemed to think it was important enough for WinIE, and Mozilla adoption was slow. Back then, it wasn't considered ridiculous for web developers to use WinIE for anything other than testing, but ActiveX was (correctly) considered evil.
So to those of you who claim that it's been around forever and JJG doesn't deserve any credit for calling it "AJAX" and making it famous... You're all wet. Marketing failures are still failures. Just because Uranium has been around since the dawn of time doesn't mean nuclear fission isn't a potent technology.
PS: To be pedantic, the "XMLHttpRequest class" was invented by Mozilla. The ActiveX object "Microsoft.XMLHTTP", and the associated interface was invented by MS. (Which might explain why a return code of "4" means "completed, everything OK"..., but I digress.)
You left out the steps where you:
Given that the manufacturing of a pencil is this complicated, the phrase "from scratch" ceases to have much meaning for anything more complex than, say, fruit salad.
(And the Sun, birds, and bees might have a thing or two to say about that...)
Residential power distribution methods vary, but most single phase lines are about 7200VAC.. 240VAC is supplied to the house via a pair of 120VAC lines, 180degrees out of phase from each other. Breaker panels send one of the feeders to each half of the breakers in the house, which is why it's possible to lose power to only half of your house...
Commercial distribution is three phase 120/240VAC, 120/208VAC or 480VAC, depending on the customer.
Other than that...your BPL "broadcast domain" *might* be larger than your house, depending on how the BPL networks are designed.
Maybe you're thinking of the old X10 problem, where two houses (sometimes more) would be on the same secondary winding of a step down transformer, so signals would be shared between them.
I don't know exactly how BPL networks are designed, but the data has to traverse multiple high and low voltage lines and cross multiple transformers...so there have to be repeaters/bridges/routers (or things that resemble them) along the way, and the opportunity exists to isolate network branches wherever desired.
The least expensive design would look like first-gen cable internet, but it's at least possible that they've learned from those mistakes...
> Glad my dad fought in WWWII so these greedy politicians can ...
:-)
WWWII? Is that like Web2.0?? No one told me there was fighting involved..!
fedex.org must be a non-profit as well.
Their taxes must be awfully complicated, running parallel businesses with different regulatory compliances.
I think the days are over when big companies with lots of cash can pretend to be wholly ignorant of things in the computer world, hoping the judge will be too. It's too easy to find expert witnesses that make you look like idiots and/or liars. Time for a policy change, methinks.
You have to wonder about a profession that encourages its practitioners to feign ignorance.
or WWW+RW.
Just be careful, because WWW-RW and WWW+RW each only work in certain browsers, and if you accidentally browse to the wrong kind of website because you didn't notice the stupid 2-pixel difference, CompUSA isn't going to give you your time back.
Better yet, instead of requiring a new manual process..
Keep the current system, but give each article an "update waiting period", based on the article's recent volatility. An article that never gets changed might be 24 hours. An active one might be 30 minutes. A very active one might be 5 minutes.
Whenever an article is modified, the new version doesn't become the "current" version until the waiting period has passed. The article police will have a window in which to fix things, and the vandalism incentive (instant gratification) will go way down.
A simple version of this idea (all articles have the same update waiting period) could be implemented very quickly. A more complex version (period based on volatility) might not even add any value. Either way, no additional processes or people or work would be required, and the problem would be largely solved.
The reason it took five years to build Mozilla is that in the early days of the web, the primary developers of the leading browser (Mosaic) went private (Netscape) and abandoned their original open source project. Then as the web exploded, they were the only ones positioned to keep up with the changes (and drive some of them with proprietary extensions to HTML, etc).
Microsoft entered the game and made some smart (and some illegal) moves, while Netscape was grossly mismanaged and unresponsive. Eventually, they were persuaded from within to open the source to Navigator, but it was a horrific mess and made volunteer participants *very* hard to find.
By now, a browser was not a simple application. It was a big project, and the decision to "start over" on Mozilla was some serious drama. A couple of false starts later, a development model that worked coalesced into existence, but even then it took the focus of the Firefox project to bring a popular product to market.
Point being: if Mosaic had continued to be developed instead of abandoned at the beginning of the explosion of the web, it wouldn't have taken any time to "catch up" with IE6. Even if the original team hadn't been able to find a working development model, someone else would have and forked the codebase to get there.
But you're right. The lack of marketing-driven deadlines does allow for superior product, eventually. Imagine if the Internet was developed "in time for the Christmas shopping season, and 4th quarter earnings!"
You can't "crack" a hash, by definition. If you could, md5 would the most incredible compression algorithm ever discovered.
A hash is considered weak if it has collisions: when more than one plaintext results in an identical hash value. Hashes are usually used for verification, so non-unique results are a critical failure.
Attacks against hashed passwords are done by brute force. The mitigation against this attack is to use a salted hash, which adds a few bytes of randomness to the password.
The extra bits of randomness make it exponentially (^16, ^24, ^32, usually) more difficult to pregenerate a hash results dictionary. However, they don't make it any harder to brute force a single password, after the hashed version is obtained.
Good google tip...
But it's not clear that the OP is looking for a CDMP3 player. I suppose he might be, but I think an alarm clock that stores MP3s would be way cooler.
The Mitsubishi site doesn't appear to have any real content on it about this product, but here's another review:
r ojector-8482.htm
http://www.techworthy.com/Blog/Mitsubishi-PocketP
Some people use "N/A" to mean "not available".
Others use it to mean "not applicable"...which are really two very different things.
Sometimes, this causes me great consternation.
They make and sell copies of famous statues for those who can't conquer the countries that own the originals. You can get them with or without the fig leaf.
The NYT used a figged copy of the Farnese Atlas for their story photo.
It's lame, but pretty much everyone everywhere does the same thing when given a chance.
Think of all the things people could do with the energy they'd save if they just didn't bother to get offended by unimportant things...
Erm, no. It's a European thing.
Prudes.
Apple introduced Desktop Accessories in 1984. At the time, MacOS (then just called the "System") wasn't multitasking, so DAs were a way to run "something else" without closing your running application.
Some examples: Calculator, Alarm Clock (later, the clock moved to the menu bar), Key Caps (so you could find all the non-standard keyboard characters like the Yen symbol, etc), Puzzle, Scrapbook (like multiple, persistent copy buffers), Notepad (like Stickies), Chooser (to select printers and networks), etc. Yup, 1984.
They all lived under the Apple menu, and could be used at any time. They required some unusual constraints to WRITE, however...but Apple provided some decent sample code and shareware developers wrote hundreds more of them.
After MacOS became preemptively multitasking, the only reason DAs stuck around is that users expected them. There was no longer a good reason to code within the DA frameworks, (and by then you could put any app you wanted into the Apple menu, so that was no longer unique..)
Dashboard is not a knock-off. It's a reintroduction of Apple's own good idea from twenty years ago. As for the naming choice -- well, I think it's dumb...but it doesn't make sense to claim that that's stolen either. There is no more generic term for a small, useful thing. Widgets will be more powerful than DAs and easier to write, but that's a function of the intervening time, not stolen inspiration.
Dashboard is also interesting because the applets (see?) are like Desk Accessories, but the use model appears to be Apple's first admission that virtual desktops might be a GOOD IDEA that users are capable of understanding (when presented in a very animated-so-you-know-whats-happening-at-all-times kind of way). That's a big step for Apple HIG!
Next stop, multi-button mouses, STANDARD!
I only worry that with Expose and Dashboard, Apple might decide that users are all tapped out in the weird-things-that-happen-to-my-desktop department and never implement virtual desktops themselves.
(Though I'm pretty happy with Virtue. Look it up on version tracker.)
FYI, that's "MAEs", as in MAE-East, MAE-West(!), and MAE-Central.
MAE stands for Metropolitan Area Exchange, and they used to be hugely important parts of the primary backbone of the NSF Internet, along with other peering points called NAPs.
They still route a lot of traffic, but as a percentage of the whole, much less than ten years ago.
"MAE" appears to now be a trademark of MCI, and they claim it is not an acronym...but that's revisionist history, at best. I was there.
http://www.mae.net/faq/
Doesn't it seem like "exploiting customers by fraudulent means" should carry a heavier sentence than this?
Microsoft has smart lawyers, and California's lawyers apparently rolled over and played dead, after making a good show of pursuing the case after most others had dropped it.
But let's look at this...Microsoft's lawyers negotiated a settlement whereby:
1. claimants have to produce and file an old receipt for purchase of software. (dropoff percentage upward of 75%, for sure)
2. claimants receive a VOUCHER FOR FUTURE PURCHASES of computer stuff. (dropoff percentage at least 50%)
3. claimants have to send all that paperwork to a claim management company to get their real money (dropoff percentage at least 30% -- would be much higher, but any customer who is this far along can be presumed to be motivated...)
and lastly, the icing on the cake:
4. two-thirds of unclaimed funds are donated, by Microsoft, to California schools in the form of computer hardware and software. The software, of course, has zero incremental cost to Microsoft except in lost sales to CA schools, but even more importantly...there is no donation better spent than a donation to kids. Get them early, get them for life.
What ever happened to: "You screwed the plaintiffs over. Make full restitution now or go to jail."?