Do you even know anything about this language beyond status bar text scripts and document.write? ECMAScript, the actual language we're speaking about (as opposed to the language/standard library combo JS actually is) is a sophisticated mix of functional (good for event-driven code) and procedural (good for general-purpose code) programming features augumented with prototype-based OOP (allows for a decent DOM implementation). The design is not as good as Python's (IMHO), but it's second to it in allowing programmers to write clever, concise code that does its job well. And the "standard library" that makes JS what it is, is actually DOM.
Unfortunately, the world is full of people who don't even know what functional or procedural programming means and write utter crap in JS, usually thinking that it looks similar to C, so it can be used like C (and it cannot be, because functional features will trigger "unexpected" behaviour), or not thinking at all. This doesn't mean that the language is bad. You could as well say that HTML and CSS are bad because millions of morons are abusing it constantly. But it's not HTML, CSS or JS that are bad. It's the countless "tutorials" written by morons for morons that perpetuate bad practices and monkey-like code copying without a tiniest thought about what the code actually does and how. I'm afraid, however, current technology doesn't let us make compuetrs that stab people in the face for writing crap tutorials.
MVP stands for Model-View-Presenter. What differentiates a Presenter from a Controller is that a Controller creates an appropriate model (or models) and a view of some kind, connects those together and tells them what to do. It might also do ACL checking and the likes before. Then, the view fetches data from the model(s) and displays it (for a very liberal value of "display", as might be the case with, say, an RSS feed generator). That's right: the view is an active element of the system, usually implemented as an object using some kind of a base class just like the controller and it can access the model. Of course, the model should be strictly read-only for the view - all things good and sane are lost for the application when some moron calls a method of a model that modifies data from inside the view. A good framework might employ safeguards against this, but a good design comes first to protect against such idiocy. One could argue that the view just becomes a second controller with a different set of responsibilities, and it's actually an interesting and somewhat reasonalbe point of view, but that's just what MVC really is.
The Presenter, on the other hand, does not relay the model(s) to the view and tell it what to display. Instead, it fetches *all* the data itself and spoon-feeds it to the view, which is usually a purely passive construct. As a side effect of this, the Presenter is usually involved in some presentation-related data postprocessing such as pagination and sorting, that a Controller should never do. Hence the name. On the other hand, this allows for a "dumb" view, such as those used by CakePHP - it's just a bunch of HTML files with embedded PHP snippets that display the data. Much less flexible than MVC, but also much simpler to implement and use.
Of course, neither is better than the other. They're just two somewhat different variations of the same idea, each with their own advantages and disadvantages. The only problem is that uninformed people call MVP "MVC", which is plain and simple wrong and indicates some degree of ignorance of the subject, which is never a good sign.
Personally, I'm using a hybrid solution that will invoke an MVC-style, class-based view when it exists and fall back to MVP-style spoon-fed templates otherwise.
No, a random delay just makes it harder for an attacker to determine the nect correct character. The exact theory behind eliminating the random factor eludes me, but several smart people found a way and it's supposedly correct.
I think the proper way is to "pad" the time so that it's constant. Say, if the password checking algorithm can take from 50us up to 600us, pad it to 1500us (safety margin!) with as much precision as posiible. There might be other code paths to pad, too, such as the one that fires when there's not even such a user, but you still want to display the "wrong password" message, as some systems do.
And when they pass this, ask them to define MVC. If they start describing MVP (which is used in just about every single web application framework out there and labeled "MVC" in the code and documentation), you'll know that something's wrong. If you fall for this yourself... Well, you'll know something is wrong on a yet more basic level.
You'd have to behead them first, otherwise they're going to be too buoyant. And then you'll be right where you started, just with the lawyers' heads instead of plastic pieces...
Look up the LIREC project, too
on
Teaching With Robots
·
· Score: 3, Interesting
It's an European research project that studies social interactions of robots and people, and attempts to get around the uncanny valley, among other things. They already have some quite interesting results, although I can't really elaborate on their scientific side, social robots being outside of my field of interest.
Disclaimer: I know a few LIREC members personally.
It is not if you know the teory behind finite state manichnes and their use in writing parsers. Just about every Somp Sci and software engineering department in the world includes those in the curriculum.
Actually, any other 4-op calculator implementation than a simple, formal FSM should be a red flag for the recruiter.
There's no such thing as a "basic microcontroler". There's so much variety amon microcontrollers that your question almost makes no sense.
An ATmega88, a lower-end uC, costs $0.50, measures about 10x10x3mm and consumes less than 15mA at 5V when running at full speed, which is 20MHz and less than 250uA at 1.8V, 1MHz. With a few kilobytes of RAM and a few more of flash it might look like a joke, but a skilled programmer can implement quite a lot on one and it will work on a single AAA battery for weeks. Years on a sealed AGM.
It's probably going to be removed by the means of air ducts and high flow fans. The size of a case is not directly linked to its heat removal capacity. Sure it helps with piss-poor heat management with no ducted or at least heavily directed air flow and semi-random fan selection and placement as seen in most generic ATX cases, but it's still perfectly possible to remove a huge amount of heat from a very tightly packed case. It's somewhat more expensive and requires more know-how and though wchich increases the final cost, but it's nothing for someone who can afford dual 5790s.
I guess the key is "ARM" here. Unfortunately, x86 laptops are equipped with either internally connected USB card readers (the worst of both worlds, really) or some PCI-based Ricoh crap that generates roughly 800 interrupts/s during a file transfer.
USB is a CPU-bound bus. It requires every packet to be at least partially processed by the CPU. MMC is even worse, the damn things does almost everything in software as most MMC "controllers" out there are just GPIO passthroughs. A side effect of this is that the CPU is unable to enter deeper C-states when a file transfer to/from a thumbdirve or an MMC card is in progress, wasting significant amounts of power on something so trivial.
An SSD connected to the SATA bus, on the other hand, is able to perform a bulk data transfer using DMA and wake up the CPU when all the requested data is already in the memory, to be processed at once.
Conclusion: sometimes there's more to some things than you expect, so be wary when making over-the-top dismissive comments.
What you're saying is very interesting, but in contradiction to my experience with GoogleBot's behavoiur.
I've seen GoogleBot-images do a normal crawl of the images on the site, respecting robots.txt and all, and then, start a crawl over the images it was explicitly forbidden from indexing, from the same IP (*definitely* a Google IP, not an impostor), just with the User-Agent header changed to an empty string. Nice, eh? It was way too fast and way too cordinated to be triggered by human action. And if there was actually a human involved in telling the bot to return to the site, *ahem*, "incognito" a few seconds later, I'd be more than happy to tell them to bugger off properly when they're told to.
I don't get something in your reasoning - care to explain?
When Joe Shmoe downloads Corporation X's software from TPB, installs it and makes money using it, and they find out, they send a legal letter demanding that Joe removes the software and pays up $x (for very high values of x) or gets dragged through court (and ends up paying many times $x) for violation of the license. After that, Joe Shmoe is broke and Corporation X starts lobbying for new laws against software piracy.
When FooShmoo & Co. downloads Mr FLOSS Developer's GPL-licensed software from his website, puts it in their FooBox 2.0 and sells it without distributing the source code or allowing for its proper use, and he finds out, he first asks them to comply in an informal manner, then he tries to publicize the problem hoping that FooShmoo & Co. will comply to prevent bad publicity, and only when this fails, he goes to the FSF or the likes and asks for help, which usually means a legal letter demanding that they comply, or be dragged through court (and end up complying and paying the legal fees) for violation of the license. After that, FooShmoo & Co. can go on with its business and Mr FLOSS Developer is content that his rights as an author are finally respected.
And yet, you present the latter situation in a derogatory manner. Why?
That went into evdev, I guess, which is an abstraction layer for all input devices. Most probably just a 0 changed to 1 in some device ID table to tell evdev to relay rumble events to the pad (which might not be the default to, e.g., prevent dumb pads from locking up). Just a guess, though.
1. I had never experienced the problem myself. 2. Badly designed HDDs are known to screw with journaling filesystems, it could be that reiserfs is vulnerable to this. 3. I was talking about something else than you tthough I was. 4. I asked you to stop the "fixed that for you" crap that you claim so openly to hate yourself. 5. I asked an honest, serious on-topic question (and I'm still expecting an honest, serious, on-topic response).
Where exactly among those points did I "blame the user"? At worst, it was "*maybe* blame the hardware", which is not that unreasonable. If you feel so personal about your HDDs, well, I'm sorry to have hurt your feelings,but I suspect it was just another instance of reading things that are not really there.
You're kidding, right? Tell me you're being sarcastic, please. There's nothing I love more than finding parts of my syslog in my mail spool after a crash. And then being told that to prevent that I should turn off block packing, which was one of the USPs of reiserfs in the first place.
Never, ever had reiserfs corrupt itself, even after kernel panics, power failures and the likes. Are you sure your HDDs were not playing tricks on you with false cache flush confirmations to look better in benchmarks?
Yes, well, that one caveat says it all, now doesn't it? Filesystem corruption after a crash is almost a given on reiserfs.
I was talking about outside influences - physical HDD damage, another OS screwing something up while the OS using the reiserfs partition is off, etc. Stick to your signature and do not skew my words in your favor in a pseudo-smart-assy way, will you?
And even if what you said was true (which my experience doesn't confirm), is there any other Linux filesystem that is actually capable of any serious data recovery when the standard fsck fails?
Personally, I'm using reiserfs (that is, reiser3, not reiser4) solely due to its outstanding disaster recovery capabilities. No matter what happens to the media or the filesystem itself, "reiserfsck --rebuild-tree" is going to bring back everything that was not directly overwritten or corrupted. I've had many things happen to my disks (head crashes, several gigabytes from the beginnig of the partition being overwritten by a borked OS isntaller, "rm -rf blah/ *" instead of "rm -rf blah/*" and so on), and every single time, --rebuild-tree recovered everything that still was there to be recovered. As far as I know, this is due to the fact that all the filesystem metadata is distributed evenly throughout the partition, heavily replicated and identifiable using some kind of magic hashes even when there is no higher-order structure left (so a --rebuild-tree process can just do a linear scan of the damaged partition and find all the "dangling" inodes with ease).
As far as I know, this is not possible (especially using the standard fsck utility as with reiserfs) with the ext* family of filesystems.
So, does btrfs have similar capabilities? If so, I'm going to be quite interested in testing it, even though I'm not using Ubuntu.
Surely a robot programmer who tests his safety-related code on himself and lives must be quite good at what he does? I suppose that he's going to find that video useful, should he choose to search for a new job...
Would you, as a regulator, risk that the families of the killed passengers might be able, with the help of a good lawyer, to convince the judge that such waivers were null and void and your permission to fly was illegal? That would probably mean a life on jail, and it's really not unheard of in judical world to successfully contest such a waiver.
It's easy to call people names if you're not those people and (probably) don't actually know a quack about practical and legal aspects of their work.
Sure, you're right, they're a-OK from a legal point of view, but they still are a bunch of douchebags. If nothing else, because they flood the search indexes of Amazon and Google with useless crap that matches almost anything and makes it harder to find relevant publications. This benefits absolutely no one. Actually, I don't see how it could benefit even them and Amazon, as I can't imagine anyone buying this crap for any purpose, other than maybe some extravagant and expensive kind of toilet paper.
Additionally, this doesn't seem to have anything to do with the spirit and purpose of Wikipedia, which is not as well-defined and, arguably, as important (well, from a legal point of view, it's not important at all) as the license, but it is there nontheless. People who create content and release it under permissive licenses still have their right to say that they don't appreciate some uses of their work, even though they allow it. Of course, any wise author will admit that it's just the price of making Free things, but even wise people need to rant and gripe sometimes.
The issue is the one of encryption vs. authentication vs. both at the same time, and the fact that SSL/TLS was designed to provide both at the same time only, without any sane way to provide just one of those things at a time, as opposed to, e.g., PGP.
I'm no cryptographer, just a part-time server administrator (and other things too, but this is irrelevant), but my experience, together with plain, old common sense tells me that things would be much easier for both administrators and security guys (is there a proper name for them?) if the concepts of data encryption on the wire and authentication of the other party were separated both in protocol and implementation. Besides the obvious benefit of being able to encrypt the connection without those silly, cartel-provided certificates (even without indicating anything at all to the user, so they don't get a false sense of having more security in place than there is, default encryption of the most popular protocols would do much to thwart all but the most determined wiretapping and eavesdropping attempts), such a separation into two distinct technologies should make it a lot harder to break both things at the same time, and a lot easier to fix any single one of them that someone managed to break without affecting the other.
Of course I could be wrong, and even if I'm not, there's too much inertia in technology and too much money in the SLL certificate cartels for anything to change in this direction, but at least I still have my right to rant a little bit.
Slashdot Mirror
Do you even know anything about this language beyond status bar text scripts and document.write? ECMAScript, the actual language we're speaking about (as opposed to the language/standard library combo JS actually is) is a sophisticated mix of functional (good for event-driven code) and procedural (good for general-purpose code) programming features augumented with prototype-based OOP (allows for a decent DOM implementation). The design is not as good as Python's (IMHO), but it's second to it in allowing programmers to write clever, concise code that does its job well. And the "standard library" that makes JS what it is, is actually DOM.
Unfortunately, the world is full of people who don't even know what functional or procedural programming means and write utter crap in JS, usually thinking that it looks similar to C, so it can be used like C (and it cannot be, because functional features will trigger "unexpected" behaviour), or not thinking at all. This doesn't mean that the language is bad. You could as well say that HTML and CSS are bad because millions of morons are abusing it constantly. But it's not HTML, CSS or JS that are bad. It's the countless "tutorials" written by morons for morons that perpetuate bad practices and monkey-like code copying without a tiniest thought about what the code actually does and how. I'm afraid, however, current technology doesn't let us make compuetrs that stab people in the face for writing crap tutorials.
MVP stands for Model-View-Presenter. What differentiates a Presenter from a Controller is that a Controller creates an appropriate model (or models) and a view of some kind, connects those together and tells them what to do. It might also do ACL checking and the likes before. Then, the view fetches data from the model(s) and displays it (for a very liberal value of "display", as might be the case with, say, an RSS feed generator). That's right: the view is an active element of the system, usually implemented as an object using some kind of a base class just like the controller and it can access the model. Of course, the model should be strictly read-only for the view - all things good and sane are lost for the application when some moron calls a method of a model that modifies data from inside the view. A good framework might employ safeguards against this, but a good design comes first to protect against such idiocy. One could argue that the view just becomes a second controller with a different set of responsibilities, and it's actually an interesting and somewhat reasonalbe point of view, but that's just what MVC really is.
The Presenter, on the other hand, does not relay the model(s) to the view and tell it what to display. Instead, it fetches *all* the data itself and spoon-feeds it to the view, which is usually a purely passive construct. As a side effect of this, the Presenter is usually involved in some presentation-related data postprocessing such as pagination and sorting, that a Controller should never do. Hence the name. On the other hand, this allows for a "dumb" view, such as those used by CakePHP - it's just a bunch of HTML files with embedded PHP snippets that display the data. Much less flexible than MVC, but also much simpler to implement and use.
Of course, neither is better than the other. They're just two somewhat different variations of the same idea, each with their own advantages and disadvantages. The only problem is that uninformed people call MVP "MVC", which is plain and simple wrong and indicates some degree of ignorance of the subject, which is never a good sign.
Personally, I'm using a hybrid solution that will invoke an MVC-style, class-based view when it exists and fall back to MVP-style spoon-fed templates otherwise.
No, a random delay just makes it harder for an attacker to determine the nect correct character. The exact theory behind eliminating the random factor eludes me, but several smart people found a way and it's supposedly correct.
I think the proper way is to "pad" the time so that it's constant. Say, if the password checking algorithm can take from 50us up to 600us, pad it to 1500us (safety margin!) with as much precision as posiible. There might be other code paths to pad, too, such as the one that fires when there's not even such a user, but you still want to display the "wrong password" message, as some systems do.
And when they pass this, ask them to define MVC. If they start describing MVP (which is used in just about every single web application framework out there and labeled "MVC" in the code and documentation), you'll know that something's wrong. If you fall for this yourself... Well, you'll know something is wrong on a yet more basic level.
You'd have to behead them first, otherwise they're going to be too buoyant. And then you'll be right where you started, just with the lawyers' heads instead of plastic pieces...
It's an European research project that studies social interactions of robots and people, and attempts to get around the uncanny valley, among other things. They already have some quite interesting results, although I can't really elaborate on their scientific side, social robots being outside of my field of interest.
Disclaimer: I know a few LIREC members personally.
It is not if you know the teory behind finite state manichnes and their use in writing parsers. Just about every Somp Sci and software engineering department in the world includes those in the curriculum.
Actually, any other 4-op calculator implementation than a simple, formal FSM should be a red flag for the recruiter.
There's no such thing as a "basic microcontroler". There's so much variety amon microcontrollers that your question almost makes no sense.
An ATmega88, a lower-end uC, costs $0.50, measures about 10x10x3mm and consumes less than 15mA at 5V when running at full speed, which is 20MHz and less than 250uA at 1.8V, 1MHz. With a few kilobytes of RAM and a few more of flash it might look like a joke, but a skilled programmer can implement quite a lot on one and it will work on a single AAA battery for weeks. Years on a sealed AGM.
It's probably going to be removed by the means of air ducts and high flow fans. The size of a case is not directly linked to its heat removal capacity. Sure it helps with piss-poor heat management with no ducted or at least heavily directed air flow and semi-random fan selection and placement as seen in most generic ATX cases, but it's still perfectly possible to remove a huge amount of heat from a very tightly packed case. It's somewhat more expensive and requires more know-how and though wchich increases the final cost, but it's nothing for someone who can afford dual 5790s.
I guess the key is "ARM" here. Unfortunately, x86 laptops are equipped with either internally connected USB card readers (the worst of both worlds, really) or some PCI-based Ricoh crap that generates roughly 800 interrupts/s during a file transfer.
USB is a CPU-bound bus. It requires every packet to be at least partially processed by the CPU. MMC is even worse, the damn things does almost everything in software as most MMC "controllers" out there are just GPIO passthroughs. A side effect of this is that the CPU is unable to enter deeper C-states when a file transfer to/from a thumbdirve or an MMC card is in progress, wasting significant amounts of power on something so trivial.
An SSD connected to the SATA bus, on the other hand, is able to perform a bulk data transfer using DMA and wake up the CPU when all the requested data is already in the memory, to be processed at once.
Conclusion: sometimes there's more to some things than you expect, so be wary when making over-the-top dismissive comments.
What you're saying is very interesting, but in contradiction to my experience with GoogleBot's behavoiur.
I've seen GoogleBot-images do a normal crawl of the images on the site, respecting robots.txt and all, and then, start a crawl over the images it was explicitly forbidden from indexing, from the same IP (*definitely* a Google IP, not an impostor), just with the User-Agent header changed to an empty string. Nice, eh? It was way too fast and way too cordinated to be triggered by human action. And if there was actually a human involved in telling the bot to return to the site, *ahem*, "incognito" a few seconds later, I'd be more than happy to tell them to bugger off properly when they're told to.
A guy with a Barret M107, a handful of .50 BMG bullets with "for this patent bullshit" engraved on them and an escape helicopter would help, too.
Every time I read about scumbags like this, I'm more and more convinced that this is indeed the only way.
I don't get something in your reasoning - care to explain?
When Joe Shmoe downloads Corporation X's software from TPB, installs it and makes money using it, and they find out, they send a legal letter demanding that Joe removes the software and pays up $x (for very high values of x) or gets dragged through court (and ends up paying many times $x) for violation of the license. After that, Joe Shmoe is broke and Corporation X starts lobbying for new laws against software piracy.
When FooShmoo & Co. downloads Mr FLOSS Developer's GPL-licensed software from his website, puts it in their FooBox 2.0 and sells it without distributing the source code or allowing for its proper use, and he finds out, he first asks them to comply in an informal manner, then he tries to publicize the problem hoping that FooShmoo & Co. will comply to prevent bad publicity, and only when this fails, he goes to the FSF or the likes and asks for help, which usually means a legal letter demanding that they comply, or be dragged through court (and end up complying and paying the legal fees) for violation of the license. After that, FooShmoo & Co. can go on with its business and Mr FLOSS Developer is content that his rights as an author are finally respected.
And yet, you present the latter situation in a derogatory manner. Why?
That went into evdev, I guess, which is an abstraction layer for all input devices. Most probably just a 0 changed to 1 in some device ID table to tell evdev to relay rumble events to the pad (which might not be the default to, e.g., prevent dumb pads from locking up). Just a guess, though.
Eh, what? This is what I wrote, in order:
1. I had never experienced the problem myself.
2. Badly designed HDDs are known to screw with journaling filesystems, it could be that reiserfs is vulnerable to this.
3. I was talking about something else than you tthough I was.
4. I asked you to stop the "fixed that for you" crap that you claim so openly to hate yourself.
5. I asked an honest, serious on-topic question (and I'm still expecting an honest, serious, on-topic response).
Where exactly among those points did I "blame the user"? At worst, it was "*maybe* blame the hardware", which is not that unreasonable. If you feel so personal about your HDDs, well, I'm sorry to have hurt your feelings,but I suspect it was just another instance of reading things that are not really there.
Now, what about the question I had?
You're kidding, right? Tell me you're being sarcastic, please.
There's nothing I love more than finding parts of my syslog in my mail spool after a crash. And then being told that to prevent that I should turn off block packing, which was one of the USPs of reiserfs in the first place.
Never, ever had reiserfs corrupt itself, even after kernel panics, power failures and the likes. Are you sure your HDDs were not playing tricks on you with false cache flush confirmations to look better in benchmarks?
Yes, well, that one caveat says it all, now doesn't it? Filesystem corruption after a crash is almost a given on reiserfs.
I was talking about outside influences - physical HDD damage, another OS screwing something up while the OS using the reiserfs partition is off, etc. Stick to your signature and do not skew my words in your favor in a pseudo-smart-assy way, will you?
And even if what you said was true (which my experience doesn't confirm), is there any other Linux filesystem that is actually capable of any serious data recovery when the standard fsck fails?
Personally, I'm using reiserfs (that is, reiser3, not reiser4) solely due to its outstanding disaster recovery capabilities. No matter what happens to the media or the filesystem itself, "reiserfsck --rebuild-tree" is going to bring back everything that was not directly overwritten or corrupted. I've had many things happen to my disks (head crashes, several gigabytes from the beginnig of the partition being overwritten by a borked OS isntaller, "rm -rf blah/ *" instead of "rm -rf blah/*" and so on), and every single time, --rebuild-tree recovered everything that still was there to be recovered. As far as I know, this is due to the fact that all the filesystem metadata is distributed evenly throughout the partition, heavily replicated and identifiable using some kind of magic hashes even when there is no higher-order structure left (so a --rebuild-tree process can just do a linear scan of the damaged partition and find all the "dangling" inodes with ease).
As far as I know, this is not possible (especially using the standard fsck utility as with reiserfs) with the ext* family of filesystems.
So, does btrfs have similar capabilities? If so, I'm going to be quite interested in testing it, even though I'm not using Ubuntu.
Surely a robot programmer who tests his safety-related code on himself and lives must be quite good at what he does? I suppose that he's going to find that video useful, should he choose to search for a new job...
Would you, as a regulator, risk that the families of the killed passengers might be able, with the help of a good lawyer, to convince the judge that such waivers were null and void and your permission to fly was illegal? That would probably mean a life on jail, and it's really not unheard of in judical world to successfully contest such a waiver.
It's easy to call people names if you're not those people and (probably) don't actually know a quack about practical and legal aspects of their work.
I'm getting so many packs of 15s that I would be rich if it was possible to sell them. "Disable Ads" checked since around 2007.
NSA/CIA/FBI multi-mode receivers that weren't supposed to exist (the FBI bought them back from us)
Where did you get those and how many vans full of men in black suits showed up before your door to present the buyout offer?
Sure, you're right, they're a-OK from a legal point of view, but they still are a bunch of douchebags. If nothing else, because they flood the search indexes of Amazon and Google with useless crap that matches almost anything and makes it harder to find relevant publications. This benefits absolutely no one. Actually, I don't see how it could benefit even them and Amazon, as I can't imagine anyone buying this crap for any purpose, other than maybe some extravagant and expensive kind of toilet paper.
Additionally, this doesn't seem to have anything to do with the spirit and purpose of Wikipedia, which is not as well-defined and, arguably, as important (well, from a legal point of view, it's not important at all) as the license, but it is there nontheless. People who create content and release it under permissive licenses still have their right to say that they don't appreciate some uses of their work, even though they allow it. Of course, any wise author will admit that it's just the price of making Free things, but even wise people need to rant and gripe sometimes.
Use the PTFE plumbing tape to secure screw threads. $0.10 for a few meters, works flawlessly even against very strong vibration.
The issue is the one of encryption vs. authentication vs. both at the same time, and the fact that SSL/TLS was designed to provide both at the same time only, without any sane way to provide just one of those things at a time, as opposed to, e.g., PGP.
I'm no cryptographer, just a part-time server administrator (and other things too, but this is irrelevant), but my experience, together with plain, old common sense tells me that things would be much easier for both administrators and security guys (is there a proper name for them?) if the concepts of data encryption on the wire and authentication of the other party were separated both in protocol and implementation. Besides the obvious benefit of being able to encrypt the connection without those silly, cartel-provided certificates (even without indicating anything at all to the user, so they don't get a false sense of having more security in place than there is, default encryption of the most popular protocols would do much to thwart all but the most determined wiretapping and eavesdropping attempts), such a separation into two distinct technologies should make it a lot harder to break both things at the same time, and a lot easier to fix any single one of them that someone managed to break without affecting the other.
Of course I could be wrong, and even if I'm not, there's too much inertia in technology and too much money in the SLL certificate cartels for anything to change in this direction, but at least I still have my right to rant a little bit.