What about vulnerabilities in communication systems that cause humans to make the error?
Access to the deep system isn't required if you compromise a system humans interact with and convince the humans they have orders to do something that they're not really supposed to do.
Social Engineering. In a well-designed secure computing system, humans tend to be the weakest link.
This has little to do with what operating system is installed. At any rate, this kind of analysis should be done as part of the safety criticality assessment. Again, if they are doing all of this the right way.
The use of Windows on nuclear submarines is not a big deal without providing a lot more context. Is Windows being installed to perform a critical function? Is there an independent backup implemented in hardware? There remain a lot of questions to be answered before I care that Windows is installed on submarines, especially given the alarmist tone of the paper as a whole.
The article (mis?)cited even talks about how the systems being used don't "usually" get autonomous control of the weapons systems. (http://www.theregister.co.uk/2008/12/16/windows_for_submarines_rollout/) That's pretty vague, but not really surprisingfor a reporter.
So, is Windows on submarines a concern? Sure it is. Quite frankly, (get out your -1 mod points) for a high risk system, one in which failure can cause loss of life on a massive scale, using Linux, or any computer system is a concern.** Luckily, if engineers are doing their jobs correctly, they know how to design these systems to prevent a software failure from causing one of these events. This almost invariably means using custom software or (better) simple hardware to implement/interlock critical functions and use regular COTS software for the rest. And yes, false indications are an example of a critical function. If the software were to indicate a missile launch, for example, I would expect a way to verify that using hardware in the procedure before moving on to the next step.
** This is because any of these systems are too big to have the kinds of quality steps needed for such a system (think TRACEABLE code coverage, testing, requirements traceability, application of coding standards and other software engineering principles, all must be traceable). Maybe if Linus Torvalds and everyone who works on the Linux kernel was hired by the DOD and held to a software quality standard, like DO-178B (http://en.wikipedia.org/wiki/DO-178B)*** there would be a small chance of being able to use this software for a function that is required to prevent loss of life.
*** Having dug through DO-178B, it is not without its issues, either. But its a good starting point at least.
Imagine you had a tape of somenoe talking and you needed to tell someone what was different from the last time they spoke. One way to do that would be to listen to the language and words and compare their meanings to figure out the difference. The other way would be to just send them the new tape to replace the previous one. A similar problem happens with new versions of software. You want to send the changes but you end up having to send the whole thing.
This technology essentially writes down what the compiled code "says" inasmuch as what is required to see what is different, and then sends only that part of it.
I remember having this idea a while back and thinking that it would surely be out there already implemented. When it wasn't, I didn't follow through and try to invent it myself. I was focused on another project at the time. Never really came back to that original idea. Awesome that someone did, and that they are keeping it open so everyone can use it! Thanks, Google!
In short, I feel that the difficulty in anyone picking up something to create a game inhibits the artistic expression. No one can arise by their own will in this field like you could in art or film.
Oversimplified. Have you ever tried to put on a musical? My friends and I did it in 24 hours. Let me tell you, it was a group effort, and many of the difficulties you discuss as being unique to game development apply to any cross-disciplinary art.
People seem to forget realities like this, just like the morons who expected a discount on the new Iphone a year into their contract.
Morons? Let's see. Right now us morons have one year left on our contract. This means we've paid for about half of our phone. Now we want a new one. Most of us morons would accept starting over our 2-year contract if it meant we could get a discount. Given that our existing phone will be "paid off" in 1 year, that leaves an entire year of payments that could be applied to the new phone. If I didn't have a plan, and wanted a contract, I could get one for $200. If I wanted no contract, it would be $600. This means the contract subsidizes the phone at a rate of about $200/year. So, if I can extend for a year, why shouldn't that roughly split the middle and allow me to get an upgrade for $400, if I wanted one?*
*Yes, this doesn't discount future payments, but for the sake of argument the point is still valid.
"Why do we pay CEOs these ridiculous salaries again? It sure isn't because they're visionaries." It's because they are all power hungry sociopaths that are charismatic & good at extracting money from us.
Corollary: If you don't like it, don't buy it!
It shocks me how many people basically pay these companies exorbitant fees to: treat them terribly, defecate all over their principles, and serve them up mindless garbage that wastes their time and makes them stupid.
I don't think anyone actually knows how the numbers would turn out, but there is a lot of crap on cable that people would probably be interested in NOT paying for...
Great, why don't you give them this wonderful idea. They'll start charging me a monthly fee, and if I don't want cable, they will simply start charging me more, citing that its easier to just serve me up cable than it is to specifically turn me off.
Obviously. There is really no distinction between charging an ISP for service and forming a partnership with them to provide content. Both are just an agreement between two parties.
This is just another reason why CONTENT providers should be prohibited from making any kind of business deals with SERVICE providers. This is a perfectly reasonable anti-trust regulation and one that I've even seen written up in the editorial section of the WSJ, of all places.
This was before net neutrality was such a hot-button issue, and the article made the point that deregulation would have been much more effective if it had been done in a way to encourage competition instead of prevent it; by preventing this partnership, competition between providers would be enabled. This makes sense even without considering there higher-minded principles behind net neutrality.
Not really. I'm responding to Python advocacy. Specifically, I'm saying that Python isn't a good replacement for Fortran, pedagogically or otherwise, and the the "solution" really has less to do with any particular language and more to do with how we teach engineers computer science. Regardless, Fortran remains prominent in scientific computing for good reasons.
The choice of glue language isn't really interesting or relevant to the core of the issue, which is that engineers feel like they aren't really learning what they need in their classes. To be honest, MATLAB ends up being a much more useful glue language because it can read the output of typical Fortran codes and create all kinds of shiny graphs right out of the box.
If you want a surprise, go look at how LISP stacks up compared to C. It is better than you think
This many times has to do with the alg you are using. Then *KNOWING* what your compiler will do. I have seen a few of these comparisons over the years. Many times the example they start with was optimized for a particular language. Be careful of these comparisons many times people are just trying to prove a point that 'X is better than Y language'.
Yeah, I've seen those waste of time articles too. I'm referring to a real study of many languages that showed that a particular implementation of ANSI Common Lisp was almost as fast as C for some tasks and an order of magnitude faster than many scripting languages, and consistently beating by a small margin at others. The article didn't have a particular axe to grind about Lisp, but did mention that part of the reason for the speed was the simplicity of Lisp syntax, greatly reducing the complexity of the interpreter. Also a factor was a quite large amount of effort optimizing the compiler. I included the comment about Lisp more as an aside than anything else.
They get some procedural programming skills with maybe a little tiny bit of object-oriented stuff (without really covering OO fundamentals IMHO, which are a more advanced topic)
It seems kind of backwards when the fundamentals of a subject is considered an advanced topic.
I agree with you in principle. However, do engineers really need to understand the intricacies of ZF set theory and peano axioms to formulate and solve a differential equation? What are considered fundamentals for a given topic really depends on how you intend to use it (in a practical sense, at least). People only have limited times, and limited brains, and while it would be nice to understand _everything_ from the ground up, and first principles, sometimes you have to settle for just knowing how to effectively use a tool and focus on your own area of expertise.
I am somewhat a Python fan boy. I love it. Its freaking wonderful for prototyping and really has a great, natural flow that reminds me a lot of pseudocode I might just invent on a napkin. Great language. But its also a factor of 30 times slower than a compiled language like C.
And Fortran is able to do optimizations (due to differences in the language for evaluation of expressions) that C is unable to do. This has to do with guarantees of ordering that Fortran does not give that C does. My point is that Fortran is even faster than C. Why do you think its still around?
The physical sciences aren't using a fast language because they are bored, or obsessed with speed for the hell of it. They use them because the problems they solve are typically deep into polynomial space, like O(n^3) or O(n^4). Having something 30 times faster means they can run 30 simulations instead of just 1. It makes a big difference to them.
I think the author of this article has lost some of this perspective.
That said, what this article should have tackled is, what do we want to teach engineering students about computer science? Right now, they take a class that teaches them C++, Java, Python, or whatever. They get some procedural programming skills with maybe a little tiny bit of object-oriented stuff (without really covering OO fundamentals IMHO, which are a more advanced topic) and they are thrown into a world where they are writing code in C for embedded controllers or Fortran for computational codes. As a result, there is a huge body of code out there written by people who know how to get the job done, but don't exactly write code that is very maintainable. They relearn the lessons of CS he hard way over 10-20-30-40(?) years of experience. Are we really giving these young students (who are not CS majors) what they need? What kind of curriculum would be ideal for someone who is going to end up writing code for something like a robot control system in C?
* I didn't really look too closely at this particular source, but I've seen numerous benchmarks all saying the same thing. If you want a surprise, go look at how LISP stacks up compared to C. It is better than you think.
This guy makes some excellent points that will no doubt fall upon many deaf ears.
And to be honest its safe to ignore people like this if you are a hobbyist and don't care whether you will continue to have hardware support for your hobby machine. After all, you can just have some fun reverse engineering the drivers you need.
The only reason to care about branding for open source and free software is if you actually expect businesses to embrace it and invest resources in developing things that work with it. You know, to enable doing the kinds of things people have come to expect to be able to do with a desktop computer.
I remember a time when it was a fair challenge to get much more than vga out of xfree86 due to lack of drivers, and when many modems and ethernet cards simply didn't work in Linux. Printers same thing. Forget about a scanner or digital camera. It was a pain in the butt for anyone with aspirations to actually have a desktop useful for much more than tinkering with itself. This has always been a limitation of open source. Things have gotten much better. And for things to continue to get better, the community should put some effort into thinking about others' perceptions of open source and trying to improve them. This is how people (including executives with very little technical interest or knowledge) make decisions end up impacting our community.
Dubbed Opera Turbo, the server-side technology reduces the amount of data that must be downloaded to render a given web page. It works by scaling back the size of some images and stripping out certain content types, said Opera spokesman Thomas Ford. Some content based on Adobe Flash, for example, isn't loaded unless a user clicks a button. In essence, Turbo works by establishing a proxy server through which compressed website content is funneled to the browser. It will not work with content that's encrypted using the Secure Sockets Layer protocol and delivers a benefit only when used on connections with limited bandwidth.
A fairly interesting concept. I wonder if Firefox is working on something like this. Seems it would be a useful idea to explore at least for embedded devices or when you are tethered through a cell phone or whatnot.
A system and method for the separate manipulation of the architecture and content of a document, particularly for data representation and transformations. The system, for use by computer software developers, removes dependency on document encoding technology. A map of metacodes found in the document is produced and provided and stored separately from the document. The map indicates the location and addresses of metacodes in the document. The system allows of multiple views of the same content, the ability to work solely on structure and solely on content, storage efficiency of multiple versions and efficiency of operation.
It sounds a bit like an embedded XSLT, more or less. Maybe?
Her comments were part of a speech that discussed the ideal of impartiality and how it is an elusive goal. She was referring to a particularly bad decision made by Judge Oliver Wendell Holmes. In practice, judges from different walks of life will have different ways of seeing the world, which will, as much as they try for it not to, influence their judgment.
The context in which a comment made affects its meaning. In this case, she was not arguing that Latino women were superior, but that a diversity of viewpoints often positively influences the quality of judgements rendered.
I may get modded down for this opinion. And I am to an extent playing Devil's advocate here.
Maybe monetizing this content isn't such a bad idea. One of the biggest problems with "big media" is that they answer to their advertisers and sponsors. These are the folks that pay the bills. With content being distributed free (beer), there is absolutely NO incentive for these organizations to put out a product that is anything more than a vehicle for advertising revenue.
So, fine. Monetize it. I'm willing to pay for a truly independent press. If the newspapers continue to spew crap, then people won't buy it. But maybe, just maybe, if these so-called professionals actually put their mind to it, they could publish material worth paying for. I pay for content all the time. The Economist, WSJ, New Yorker, Harpers. I do so because it is worth it to me. And these are writers that put out good work and they deserve to get paid. Maybe the newspapers could put out content worth paying for.
If there is anything I'm worried about its not monetization of newspaper content. It is whether these organizations have the vision to actually execute a transition to an Internet world. The whole buzz about Kindles and the NYT indicates they may be --starting-- to get it. But one beauty of free markets is that if they don't do it, someone else will.
I appreciate your opinion, and I even understand your point of view. Do you understand that releasing software may be something that is not just for your benefit? There are integrators, developers and others that need this release. And you should try it, you might even like it. Depending on how many features you actually use from an office suite.
*DISCLAIMER* I haven't really been following KOffice development, but did live through the KDE 4.0 debaucle. Therefore, the following post is really about KDE more than KOffice, and assumes that KOffice is headed in a similar direction. If they aren't, then I applaud the KOffice developers' restraint. *DISCLAIMER*
I am a huge fan of KDE and a contributor who has frequently run the 4.0 HEAD. But, I disagree with KDE's philosophy here. Perhaps this ".0 release is for integrators" is fine for open source and software enthusiasts who follow the development cycle and can keep track of these kinds of norms between projects. I am willing to concede this is fine for the traditional OSS community of hackers. But, it is my opinion that if the goal is to get more widespread adoption, (and the nice things that come with it, like better hardware support) *anything* called a RELEASE should be as free of bugs as possible and one that developers feel they can stand behind. The API can be locked for developers on RC1!
The justification for this practice of putting out an overly "green".0 release has been that not enough people try RC software. So, the reality developers fight with is that the RC releases don't generate enough bug reports to make this kind of assurance happen. The.0 release is needed to do this. I am sympathetic with this point of view. That is a serious problem, especially for ambitious and integrated software products like office suites and desktop environments. But I also think its a little disengenuous to release things this way. After all, those who are downloading the.0 that didn't download the RC before are essentially being bait-and-switched. Their change in behavior (they download the.0, not the RC) demonstrates that.
So it is not surprising to me that this harms KDE's reputation a bit. And I think KDE leadership would be well-served to face up to that reality instead of deny it. I am willing to accept that this practice may be a neccessary evil to get useful bug reports so the.1 product is good. I am willing to accept that the large body of OSS end-users should change their attitudes and be willing to try RC software. After all, there is no such thing as a free lunch. The devs need help! Help them, freeloaders! I am willing even to accept that the decision to do this might be better for the project as a whole as a stop-gap measure. But I think what KDE leaders seem to refuse to acknowledge is that such a practice does come at a cost, and is at best a patch/hack to an underlying problem that will has a limited half-life of effectiveness. People will quickly learn to just skip the.0 release.
One could argue that Microsoft did this same thing with Vista and they were widely panned for doing so. And OSS advocates were among the loud voices of criticism. Other posts here talk about the prevalence of Windows 3.1 vice 3.0. Do we really want a 15 year old Microsoft project to be our gold standard? We open source application developers should try to play by the same rules as commercial software application developers. And our aim should be to, as a community, exceed their performance. Can/should we really be deferring the responsibility for quality releases (for end-users) to the distribution maintainers?
In summary, I believe this practice of having a.0 release that is _not ready_ for end-users is huge error in judgment. If this becomes the standard for OSS projects, I think it will harm our reputation. These are businesses that are already nerv
The early dentists used a drill-like device with a hard stone such as obsidian, which is capable of puncturing bone.
"It's possible some type of [herb based] anesthetic was applied prior to drilling to blunt any pain," Jiménez said.
The ornamental stones--including jade--were attached with an adhesive made out of natural resins, such as plant sap, which was mixed with other chemicals and crushed bones, Jiménez said.
If only I could think up a cliched self-referential variation on your posting to correct your English usage, I would be sure to get the coveted +5 interesting mod.
FTA, this vulnerability is addressed in newer versions of OpenSSH, not by fixing the specification, but by employing some kind of workaround to make it impractical. I didn't know that from the summary, since I don't really keep current on where OpenSSH is with their releases.
It seems like this attack has an awfully small chance of success. I am wondering if there is that small chance of success to decode a message after many days, or if because of the small chance of success, it would take multiple days before you had anything.
If this is really something that has almost no chance of working at all--period, I'm not too worried. If it is something that makes the encryption breakable in a few days, that's a pretty big deal and am surprised that it didn't get outed sooner as a flaw.
Can/should the RFC be revised to close this hole? Are there other (perhaps more obvious) examples of weakness in the RFC that have implementation-specific fixes applied?
Slashdot Mirror
What about vulnerabilities in communication systems that cause humans to make the error?
Access to the deep system isn't required if you compromise a system humans interact with and convince the humans they have orders to do something that they're not really supposed to do.
Social Engineering. In a well-designed secure computing system, humans tend to be the weakest link.
This has little to do with what operating system is installed. At any rate, this kind of analysis should be done as part of the safety criticality assessment. Again, if they are doing all of this the right way.
The use of Windows on nuclear submarines is not a big deal without providing a lot more context. Is Windows being installed to perform a critical function? Is there an independent backup implemented in hardware? There remain a lot of questions to be answered before I care that Windows is installed on submarines, especially given the alarmist tone of the paper as a whole.
The article (mis?)cited even talks about how the systems being used don't "usually" get autonomous control of the weapons systems. (http://www.theregister.co.uk/2008/12/16/windows_for_submarines_rollout/) That's pretty vague, but not really surprisingfor a reporter.
So, is Windows on submarines a concern? Sure it is. Quite frankly, (get out your -1 mod points) for a high risk system, one in which failure can cause loss of life on a massive scale, using Linux, or any computer system is a concern.** Luckily, if engineers are doing their jobs correctly, they know how to design these systems to prevent a software failure from causing one of these events. This almost invariably means using custom software or (better) simple hardware to implement/interlock critical functions and use regular COTS software for the rest. And yes, false indications are an example of a critical function. If the software were to indicate a missile launch, for example, I would expect a way to verify that using hardware in the procedure before moving on to the next step.
** This is because any of these systems are too big to have the kinds of quality steps needed for such a system (think TRACEABLE code coverage, testing, requirements traceability, application of coding standards and other software engineering principles, all must be traceable). Maybe if Linus Torvalds and everyone who works on the Linux kernel was hired by the DOD and held to a software quality standard, like DO-178B (http://en.wikipedia.org/wiki/DO-178B)*** there would be a small chance of being able to use this software for a function that is required to prevent loss of life.
*** Having dug through DO-178B, it is not without its issues, either. But its a good starting point at least.
Imagine you had a tape of somenoe talking and you needed to tell someone what was different from the last time they spoke. One way to do that would be to listen to the language and words and compare their meanings to figure out the difference. The other way would be to just send them the new tape to replace the previous one. A similar problem happens with new versions of software. You want to send the changes but you end up having to send the whole thing.
This technology essentially writes down what the compiled code "says" inasmuch as what is required to see what is different, and then sends only that part of it.
I remember having this idea a while back and thinking that it would surely be out there already implemented. When it wasn't, I didn't follow through and try to invent it myself. I was focused on another project at the time. Never really came back to that original idea. Awesome that someone did, and that they are keeping it open so everyone can use it! Thanks, Google!
Oversimplified. Have you ever tried to put on a musical? My friends and I did it in 24 hours. Let me tell you, it was a group effort, and many of the difficulties you discuss as being unique to game development apply to any cross-disciplinary art.
Morons? Let's see. Right now us morons have one year left on our contract. This means we've paid for about half of our phone. Now we want a new one. Most of us morons would accept starting over our 2-year contract if it meant we could get a discount. Given that our existing phone will be "paid off" in 1 year, that leaves an entire year of payments that could be applied to the new phone. If I didn't have a plan, and wanted a contract, I could get one for $200. If I wanted no contract, it would be $600. This means the contract subsidizes the phone at a rate of about $200/year. So, if I can extend for a year, why shouldn't that roughly split the middle and allow me to get an upgrade for $400, if I wanted one?*
*Yes, this doesn't discount future payments, but for the sake of argument the point is still valid.
Corollary: If you don't like it, don't buy it!
It shocks me how many people basically pay these companies exorbitant fees to: treat them terribly, defecate all over their principles, and serve them up mindless garbage that wastes their time and makes them stupid.
Great, why don't you give them this wonderful idea. They'll start charging me a monthly fee, and if I don't want cable, they will simply start charging me more, citing that its easier to just serve me up cable than it is to specifically turn me off.
Obviously. There is really no distinction between charging an ISP for service and forming a partnership with them to provide content. Both are just an agreement between two parties.
This is just another reason why CONTENT providers should be prohibited from making any kind of business deals with SERVICE providers. This is a perfectly reasonable anti-trust regulation and one that I've even seen written up in the editorial section of the WSJ, of all places.
This was before net neutrality was such a hot-button issue, and the article made the point that deregulation would have been much more effective if it had been done in a way to encourage competition instead of prevent it; by preventing this partnership, competition between providers would be enabled. This makes sense even without considering there higher-minded principles behind net neutrality.
Not really. I'm responding to Python advocacy. Specifically, I'm saying that Python isn't a good replacement for Fortran, pedagogically or otherwise, and the the "solution" really has less to do with any particular language and more to do with how we teach engineers computer science. Regardless, Fortran remains prominent in scientific computing for good reasons.
The choice of glue language isn't really interesting or relevant to the core of the issue, which is that engineers feel like they aren't really learning what they need in their classes. To be honest, MATLAB ends up being a much more useful glue language because it can read the output of typical Fortran codes and create all kinds of shiny graphs right out of the box.
Yeah, I've seen those waste of time articles too. I'm referring to a real study of many languages that showed that a particular implementation of ANSI Common Lisp was almost as fast as C for some tasks and an order of magnitude faster than many scripting languages, and consistently beating by a small margin at others. The article didn't have a particular axe to grind about Lisp, but did mention that part of the reason for the speed was the simplicity of Lisp syntax, greatly reducing the complexity of the interpreter. Also a factor was a quite large amount of effort optimizing the compiler. I included the comment about Lisp more as an aside than anything else.
I agree with you in principle. However, do engineers really need to understand the intricacies of ZF set theory and peano axioms to formulate and solve a differential equation? What are considered fundamentals for a given topic really depends on how you intend to use it (in a practical sense, at least). People only have limited times, and limited brains, and while it would be nice to understand _everything_ from the ground up, and first principles, sometimes you have to settle for just knowing how to effectively use a tool and focus on your own area of expertise.
Are you serious? Python?
I am somewhat a Python fan boy. I love it. Its freaking wonderful for prototyping and really has a great, natural flow that reminds me a lot of pseudocode I might just invent on a napkin. Great language. But its also a factor of 30 times slower than a compiled language like C.
(http://www.osnews.com/story/5602/Nine_Language_Performance_Round-up_Benchmarking_Math_File_I_O/page3/)*
And Fortran is able to do optimizations (due to differences in the language for evaluation of expressions) that C is unable to do. This has to do with guarantees of ordering that Fortran does not give that C does. My point is that Fortran is even faster than C. Why do you think its still around?
The physical sciences aren't using a fast language because they are bored, or obsessed with speed for the hell of it. They use them because the problems they solve are typically deep into polynomial space, like O(n^3) or O(n^4). Having something 30 times faster means they can run 30 simulations instead of just 1. It makes a big difference to them.
I think the author of this article has lost some of this perspective.
That said, what this article should have tackled is, what do we want to teach engineering students about computer science? Right now, they take a class that teaches them C++, Java, Python, or whatever. They get some procedural programming skills with maybe a little tiny bit of object-oriented stuff (without really covering OO fundamentals IMHO, which are a more advanced topic) and they are thrown into a world where they are writing code in C for embedded controllers or Fortran for computational codes. As a result, there is a huge body of code out there written by people who know how to get the job done, but don't exactly write code that is very maintainable. They relearn the lessons of CS he hard way over 10-20-30-40(?) years of experience. Are we really giving these young students (who are not CS majors) what they need? What kind of curriculum would be ideal for someone who is going to end up writing code for something like a robot control system in C?
* I didn't really look too closely at this particular source, but I've seen numerous benchmarks all saying the same thing. If you want a surprise, go look at how LISP stacks up compared to C. It is better than you think.
This guy makes some excellent points that will no doubt fall upon many deaf ears.
And to be honest its safe to ignore people like this if you are a hobbyist and don't care whether you will continue to have hardware support for your hobby machine. After all, you can just have some fun reverse engineering the drivers you need.
The only reason to care about branding for open source and free software is if you actually expect businesses to embrace it and invest resources in developing things that work with it. You know, to enable doing the kinds of things people have come to expect to be able to do with a desktop computer.
I remember a time when it was a fair challenge to get much more than vga out of xfree86 due to lack of drivers, and when many modems and ethernet cards simply didn't work in Linux. Printers same thing. Forget about a scanner or digital camera. It was a pain in the butt for anyone with aspirations to actually have a desktop useful for much more than tinkering with itself. This has always been a limitation of open source. Things have gotten much better. And for things to continue to get better, the community should put some effort into thinking about others' perceptions of open source and trying to improve them. This is how people (including executives with very little technical interest or knowledge) make decisions end up impacting our community.
The link to the "Turbo Mode" was kinda weak and just went to a Changelog, so I found this article: http://www.theregister.co.uk/2009/06/03/opera_10_beta_debut/
Dubbed Opera Turbo, the server-side technology reduces the amount of data that must be downloaded to render a given web page. It works by scaling back the size of some images and stripping out certain content types, said Opera spokesman Thomas Ford. Some content based on Adobe Flash, for example, isn't loaded unless a user clicks a button. In essence, Turbo works by establishing a proxy server through which compressed website content is funneled to the browser. It will not work with content that's encrypted using the Secure Sockets Layer protocol and delivers a benefit only when used on connections with limited bandwidth.
A fairly interesting concept. I wonder if Firefox is working on something like this. Seems it would be a useful idea to explore at least for embedded devices or when you are tethered through a cell phone or whatnot.
Unclogs your connection?
So the internet is... like a series of tubes?
http://www.google.com/patents?id=y8UkAAAAEBAJ&dq=5787449
I have no idea what this patent is saying.
Abstract:
A system and method for the separate manipulation of the architecture and content of a document, particularly for data representation and transformations. The system, for use by computer software developers, removes dependency on document encoding technology. A map of metacodes found in the document is produced and provided and stored separately from the document. The map indicates the location and addresses of metacodes in the document. The system allows of multiple views of the same content, the ability to work solely on structure and solely on content, storage efficiency of multiple versions and efficiency of operation.
It sounds a bit like an embedded XSLT, more or less. Maybe?
There is a rather informative piece on CNN of all places that talks about this comment.
http://www.cnn.com/2009/POLITICS/05/28/ifill.sotomayor/index.html
Her comments were part of a speech that discussed the ideal of impartiality and how it is an elusive goal. She was referring to a particularly bad decision made by Judge Oliver Wendell Holmes. In practice, judges from different walks of life will have different ways of seeing the world, which will, as much as they try for it not to, influence their judgment.
The context in which a comment made affects its meaning. In this case, she was not arguing that Latino women were superior, but that a diversity of viewpoints often positively influences the quality of judgements rendered.
This is the first judge (featured on Slashdot) who I've read that has written opinions that made a lick of sense.
Wow.
I may get modded down for this opinion. And I am to an extent playing Devil's advocate here.
Maybe monetizing this content isn't such a bad idea. One of the biggest problems with "big media" is that they answer to their advertisers and sponsors. These are the folks that pay the bills. With content being distributed free (beer), there is absolutely NO incentive for these organizations to put out a product that is anything more than a vehicle for advertising revenue.
So, fine. Monetize it. I'm willing to pay for a truly independent press. If the newspapers continue to spew crap, then people won't buy it. But maybe, just maybe, if these so-called professionals actually put their mind to it, they could publish material worth paying for. I pay for content all the time. The Economist, WSJ, New Yorker, Harpers. I do so because it is worth it to me. And these are writers that put out good work and they deserve to get paid. Maybe the newspapers could put out content worth paying for.
If there is anything I'm worried about its not monetization of newspaper content. It is whether these organizations have the vision to actually execute a transition to an Internet world. The whole buzz about Kindles and the NYT indicates they may be --starting-- to get it. But one beauty of free markets is that if they don't do it, someone else will.
I appreciate your opinion, and I even understand your point of view. Do you understand that releasing software may be something that is not just for your benefit? There are integrators, developers and others that need this release. And you should try it, you might even like it. Depending on how many features you actually use from an office suite.
*DISCLAIMER*
I haven't really been following KOffice development, but did live through the KDE 4.0 debaucle. Therefore, the following post is really about KDE more than KOffice, and assumes that KOffice is headed in a similar direction. If they aren't, then I applaud the KOffice developers' restraint.
*DISCLAIMER*
I am a huge fan of KDE and a contributor who has frequently run the 4.0 HEAD. But, I disagree with KDE's philosophy here. Perhaps this ".0 release is for integrators" is fine for open source and software enthusiasts who follow the development cycle and can keep track of these kinds of norms between projects. I am willing to concede this is fine for the traditional OSS community of hackers. But, it is my opinion that if the goal is to get more widespread adoption, (and the nice things that come with it, like better hardware support) *anything* called a RELEASE should be as free of bugs as possible and one that developers feel they can stand behind. The API can be locked for developers on RC1!
The justification for this practice of putting out an overly "green" .0 release has been that not enough people try RC software. So, the reality developers fight with is that the RC releases don't generate enough bug reports to make this kind of assurance happen. The .0 release is needed to do this. I am sympathetic with this point of view. That is a serious problem, especially for ambitious and integrated software products like office suites and desktop environments. But I also think its a little disengenuous to release things this way. After all, those who are downloading the .0 that didn't download the RC before are essentially being bait-and-switched. Their change in behavior (they download the .0, not the RC) demonstrates that.
So it is not surprising to me that this harms KDE's reputation a bit. And I think KDE leadership would be well-served to face up to that reality instead of deny it. I am willing to accept that this practice may be a neccessary evil to get useful bug reports so the .1 product is good. I am willing to accept that the large body of OSS end-users should change their attitudes and be willing to try RC software. After all, there is no such thing as a free lunch. The devs need help! Help them, freeloaders! I am willing even to accept that the decision to do this might be better for the project as a whole as a stop-gap measure. But I think what KDE leaders seem to refuse to acknowledge is that such a practice does come at a cost, and is at best a patch/hack to an underlying problem that will has a limited half-life of effectiveness. People will quickly learn to just skip the .0 release.
One could argue that Microsoft did this same thing with Vista and they were widely panned for doing so. And OSS advocates were among the loud voices of criticism. Other posts here talk about the prevalence of Windows 3.1 vice 3.0. Do we really want a 15 year old Microsoft project to be our gold standard? We open source application developers should try to play by the same rules as commercial software application developers. And our aim should be to, as a community, exceed their performance. Can/should we really be deferring the responsibility for quality releases (for end-users) to the distribution maintainers?
In summary, I believe this practice of having a .0 release that is _not ready_ for end-users is huge error in judgment. If this becomes the standard for OSS projects, I think it will harm our reputation. These are businesses that are already nerv
The early dentists used a drill-like device with a hard stone such as obsidian, which is capable of puncturing bone. "It's possible some type of [herb based] anesthetic was applied prior to drilling to blunt any pain," Jiménez said. The ornamental stones--including jade--were attached with an adhesive made out of natural resins, such as plant sap, which was mixed with other chemicals and crushed bones, Jiménez said.
Oh yeah, sign me up!
Were they marks of a lack of class?
If only I could think up a cliched self-referential variation on your posting to correct your English usage, I would be sure to get the coveted +5 interesting mod.
If only.
FTA, this vulnerability is addressed in newer versions of OpenSSH, not by fixing the specification, but by employing some kind of workaround to make it impractical. I didn't know that from the summary, since I don't really keep current on where OpenSSH is with their releases.
It seems like this attack has an awfully small chance of success. I am wondering if there is that small chance of success to decode a message after many days, or if because of the small chance of success, it would take multiple days before you had anything.
If this is really something that has almost no chance of working at all--period, I'm not too worried. If it is something that makes the encryption breakable in a few days, that's a pretty big deal and am surprised that it didn't get outed sooner as a flaw.
Can/should the RFC be revised to close this hole? Are there other (perhaps more obvious) examples of weakness in the RFC that have implementation-specific fixes applied?