According to recent comments (continued on the next day's thread), the win32 compiler that Mozilla use is approaching the 4GB limit, after which LibXUL (which Firefox depends upon) will no longer compile.
While I think that Servo will produce a more decentralised design than Gecko and XUL, the memory limit will be reached well before that. With Windows XP support ending next year, Mozilla should consider migrating to x64 as soon as reasonably possible, keeping x32, but focusing on stripping large and extraneous code above new features.
Vas Rajlich, sitting in a "funky Internet cafe in Budapest", explained in greater detail:
It's reasonable to construct a search tree of around 10^18 positions using modern technology. The chess alpha-beta tree is thought to have at least 10^45 positions. The alpha-beta tree for the King's Gambit will be at most 10x to 100x smaller than that. So, we're still probably a good 25 or so orders of magnitude away from being able to solve something like the King's Gambit. If processing power doubles every 18 months for the next century, we'll have the resources to do this around the year 2120, plus or minus a few decades.
(Actually Vas is being overly optimistic, and we are probably overly pessimistic when we say: it will not be possible in the course of this universe. The Rybka author added the following caveat:)
You must remember that the tree for any specific 32-man position can be much smaller than we expect – if one side is immediately lost or if there is an immediate forced draw. Could the King's Gambit have a massively reduced tree? If the King's Gambit is winning for black, then this is theoretically possible. It is possible that after 2.f4 White is simply crushed instantly, no matter what he does. I very much doubt that this is the case. Everything in my chess experience tells me that any Black win would be long and tortuous. If the King's Gambit is a draw, though, then there are really no prospects for a massively reduced tree. In other words, it is (slightly) more preposterous to claim that 3.Be2 has been worked out to a draw than to claim that 3.Nf3 has been worked out to a loss.
They also state that the reason for their post being labelled as the 2nd is because they deliberately posted on "April 1st at 23:55h, i.e. five minutes before midnight – in Pago Pago." to make it less obvious. More detail in the article.
Extraordinary claims require extraordinary evidence -- no examples were provided on the page itself -- yet many of the comments above uncritically accept that this is true, only disputing the semantics.
On the page itself: "On March 31 the author of the Rybka program, Vasik Rajlich, and his family moved from Warsaw, Poland to a new appartment in Budapest, Hungary. The next day, in spite of the bustle of moving boxes and setting up phone and Internet connections Vas, kindly agreed to the following interview, which had been planned some months ago."
Another example of an April Fools post is here, which is more obvious due to its premise. The King's Gambit post (a day late) is plausible; but that's all. You wouldn't be taken seriously if you mentioned it to a grandmaster.
While chess will face difficulties as computers and chess software become more advanced, we are along way from writing chess off as we did checkers, and probably won't do for a number of decades -- and even then, not solving every position.
While I'm not sure about handing control of DNS to the UN, leaving such an important and essential resource to a non-democratic organization (and the country that hosts it taking extralegal measures to seize domains) is going to become increasingly untenable, and I wouldn't be surprised if the system fragments -- or is replaced altogether -- this decade.
I'm concerned that vested interests will increasingly attempt to push control of the net's infrastructure (in spite of being counterproductive and harmful), similar to how the world economy was put on the brink in 2008, by those who want more control and power, regardless of harm or cost. That would lead to the net becoming a shadow of what it is -- with self-censorship a norm and not the exception -- and go against the spirit of its foundations being built on common interest and openness. It sounds unlikely now, but considering how far down the domain takedown road we are, not impossible to imagine.
The press release you link to is from the Council of the European Union, primarily regarding a meeting held by the Agriculture and Fisheries (Agrifish) 'configuration' (participants are on pages 5-7). Other items on the release (page 4) unrelated to Agrifish include the environment; foreign affairs and security; trade policy; and social policy.
To be clear: Agrifish have not been involved with the Anti-counterfeiting trade agreement (ACTA). Another example of a document with ACTA in is the Foreign Affairs Council's (FAC) meeting about trade issues, with ACTA again being classed as an 'other item' (which to paraphrase, is "expected to be approved without discussion").
Thnak you for the link, by the way. Disappointing, though, that no expression of doubt about the subject was expressed in an earlier post; and that it was modded 4, Interesting.
No, that's correct. It was a deliberate design choice by Sun developers to make the CDDL incompatible with the GPL, using the MPL 1.1 license as a base. I wouldn't recommend CDDL due to being outdated and less popular than both MPL and GPL.
The MPL is an option for developers on Google Code, and (along with Firefox and Thunderbird) is used in Google Chrome and other software projects. There are also several licences which are forks of MPL 1.1 with minor changes by larger projects.
MPL2 sounds like what you're looking for, as it's designed to be as compatible with other licenses (including GPL and LGPL) by default (unless you add an exception), and doesn't impose conditions on how to link software. As with 1.1, in section 10.3 you have the option of forking the MPL2 if you need to for any reason as others have done - but if you're looking for a license which anyone can use with the minimum of hassle, MPL2 is in my opinion a sound choice.
You'll have to provide sources for Firefox's alleged instability. Here's a link to Mozilla's Firefox crash statistics. If you can link to a report about Chrome's stability, it would be very useful.
As for memory, Mozilla have been working on reducing memory in Firefox with the MemShrink project. Nicholas Nethercote's blog has the latest reports on improvements to the upcoming versions. Even then, it's been established before in testing that Chrome is a relative heavyweight when it comes to memory.
That's accurate. Google claims that Essence Digital and Unruly Media misinterpreted what Google wanted, and should have inserted Chrome advertising alongside content; not being content in itself, sponsored or otherwise.
Mod parent insightful. Sadly this is the main reason why a 13 month calendar, with 4 weeks per month wouldn't be adopted.
I had thought of a system (probably not unique) of using the above, and changing the name of days, ranging from 1 to 7day, with 8day added at the end of the last week of the year, and 9day added on leap years. So 1day would always be at the beginning of the month; on the 8th; 15th; and 22nd. You would always know what day of the week it is based on the day of the month.
Today's date would be 2011-13-26, with a symbol added at the end to denote the new date format during the transition period. New Year's Eve would be on the 29th.
The main downside I can think of is that there would be potential confusion if you had two date formats for a long period of time, so would require a large number of countries to change to the new format at the same time; and that there would be a considerable amount of resistance to change.
It's a format designed for practical use with how we work with a 7-day system; however, it's incompatible with the needs of those who depend upon a fixed day system, and changes to the idea would make the format less appealing; which is a shame, really.
Another project that's recently started is called 'Snappy', which aims to increase the responsiveness of users' interactions with Firefox. There's a thread on Mozillazine tracking updates on Snappy.
I don't think it's as bad as you make out. I get the impression that version numbers were to be depreceated and replaced with the terms Beta; Aurora and Nightly. Features would be mentioned as landing on Nightly/Aurora, appearing in users' browsers in so many weeks time. Releases themselves (every 6 weeks) aren't news in themselves. If Firefox developers communicate this clearly to reporters, then perhaps perceptions will change.
If users would still benefit from version numbers (e.g. for tech support), then I have a suggestion to make:
Next year, Firefox will be releasing version 12. On that version, there's the option of transitioning to a date-based system, with major versions following the year, and minor versions being incremented every 6 weeks. After version 11, the 1st release with this format would be 12.1; the 2nd release, 12.2; and so on. Here's how it looks like in practice:
* 10.0 January 31, 2012 * 11.0 March 13, 2012 * 12.1 April 24, 2012 * 12.2 June 5, 2012 * 12.3 July 17, 2012 * 12.4 August 28, 2012 * 12.5 October 9, 2012 * 12.6 November 20, 2012 * 13.1 January 1, 2013
Switching to a date-based system has the advantage that users will know what the current version is without having to report it, as the year corresponds to the version. Firefox in 2012 would be referred to as version 12. Reporters would focus on new and upcoming features in Firefox primarily, so that stories have a talking point and posters' comments are pertinent, primarily focused on features and improvements.
An example of an open source group who uses a similar format is Ubuntu (who base the version on the year, and the minor version on a 6 month schedule). Versions matter with this format; but there's still a sense of progression. We know what the version will be in 3 years time - even if we don't know what the features will be. Now try to imagine what Firefox's version would be with the new system, compared with the old one.
Consider that this is an issue that would involve a minor change; would benefit users and reporters (reducing confusion); and improve the quality of comments (on Firefox itself), then I think that Firefox developers will be pleasantly surprised with the results.
If they do want to focus more on development than on numbers, they would benefit by switching to a date system. I hope that some of the Firefox developers read this, as the value of changing merits the effort involved.
There's the RequestPolicy extension for Firefox (and perhaps other Gecko-based browsers). This allows you to browse websites without third-party domains loading scripts, images and other media onto the page.
The upside to this is that you'll no longer be followed by social networking websites wherever you go. The downside is that you'll have to spend time changing the settings for some websites to work, as even CSS will be blocked when hosted on a different domain - the eternal vigilance problem.
You can also install CS Lite for cookies, BetterPrivacy for Flash cookies and NoScript, which makes it difficult to be tracked. An extra browser for when you want everything enabled temporarily (such as Opera or Chromium) works well together.
I think this is a clear case here of politicians making policies, without thinking of the long-term consequences. Or if they are, then it's either a case of short-term point-scoring, masochism, or long-term power grabs.
The idea of prosecuting people for possession of actual child porn, which has already happened, is dubious. It rests on the ideas that possession is a form of encouragement to do likewise, and that there is an underlying monetary benefit for the producer of such images.
But unlike a "war on drugs", a "war on child porn" depends heavily on the context of the situation. An image may meet the definition of child porn, but if no-one is harmed in the process, has an actual crime been commited?
It's dangerous to assume the intent of those producing porn imagery, or those who receive it, as it leads to the slippery-slope of thought-crime. If thought-crime were real, then we can all be convicted in some shape or form. The distinctions of what's legal or not become meaningless, and abuses of power come soon after.
In the age of the internet, preventing distribution of anything is practically impossible, unless extreme measures are taken. To fight your enemy, you have to know them. And that means finding out why they abuse children in the first place. To do anything else is to pretend. And perhaps, by telling everyone else what to think and do, is a form of abuse in itself.
Rlz.dll, the closed-source file that pings Google on certain actions, is still there.
It appears in the latest zipped Chromium builds too (v.6830), which wasn't there in the October builds (v.3979). Chromium only uses it if it's there, and likely the same for Chrome, so you can delete it and be happy.
Why is there an EULA in the first place? The only difference between Google Chrome and Chromium is a build switch, so anyone can reject the EULA and compile their own versions, even if they can't redistribute the Chrome builds due to trademarks.
The BSD licence includes a disclaimer from liability when using the software, so no EULA is required for this. Google's online services have an EULA when you use them, but this isn't necessary for an open source browser.
Maybe, Google are concerned about their privacy policy, when consent is required for data to be collected on users. And Section 10.2 of the EULA isn't required for an open source browser, so it's possible for Chrome to include closed source code in the future, which the BSD licence permits.
This makes me feel uneasy about using Chrome. I hope that Google don't get so caught up in collecting information on users, that they miss focusing on building a good browser.
Looking at the first photo in the link, I keep looking at his right eye, it doesn't look right, as though the position of the skin is off. Based on the fourth photo, his skin around his eye was repaired and not from the donor. But it's made me think this could be a problem for face transplants, when the position of the skin around the eyes of the donor doesn't match the recipient's.
While full face transplants in the future are going to raise a lot of interest and intrigue, I think they are only going to be made in extreme circumstances, as where possible, it's probably best to keep the existing facial features than replace them unnecessarily.
A couple of items of interest displayed at Siggraph this year as well which I think have potential.
Microsoft's come up with a way of painting objects onto an object extracted from a video, then reinserted to the video that remains accurate when the camera angle's changed. Their research paper's called Unwrap Mosaics, and you can see a video on Youtube here (higher quality video on the reseach page).
I've been thinking that it was only a matter of time until editing video would become similar to editing photos, I just though it would take a lot more time, but everything is already here. They can even create realistic hair based on photos, just think what technology we'll have in the next decade, this could be in our homes by then.
While helping maintain work on an old game's source code, the thorny problem of which data storage format to use propped up, to replace the inflexible one in use with fixed references. There's two main developers, one who wants XML for flexibility, the other a binary format for speed and size.
XML was the main choice, but maintaining the files is trickier than it appears. It's one of the least "human readable" formats I've seen, much more so than HTML, where you know what each tag intrinsically means. This irks the second developer, who would otherwise have accepted a compromise, and there's a stalemate on the issue.
We have skipped around the issue and instead started work on adding other features and bugfixes. The only implementation which I did notice could work was SweetXML, though the time required to set this up wouldn't be as quick.
XML, and it's derivatives such as XAML, need to be easier to read and edit before they can become fully fledged on the web.
You have a point, there is no may in the sentence!
Though Wikipedia does mention that Arrow's impossibility theorem isn't necessarily connected to range voting, which is what the proposal was based on. See the properties section on the link below for the reference.
As you note, there's a problem with systems where you can give candidates a certain rating, there would be the tendency to rank one candidate 10 and the others 1. This system would attempt to balance the rating system with the ranked ones, limiting the extremes of rating, while giving the voter more choice than using rank only.
You would have a number of votes, based on the number of candidates and triangular numbers, and you can give a certain number of votes to each candidate. So 4 candidates, leads to 10 votes, 5 candidates, to 15, and so on.
Say there are 3 candidates, leading to 6 votes. The maximum you can give to a candidate is the same as the number of candidates, in this case 3.
For example, Lucy votes as follows: Andy 3, Barbara 2, Clive 1. She could also vote for Andy to have 3, without giving any votes to the others.
Another example, Max only cares about Clive, and would vote 6 if possible. Because he is unable to do so, this means he has to give the others consideration. As a result, he gives Clive 3, and Barbara 1 vote.
The results are tallied, and the winning order's based on the number of votes.
This system may be subject to manipulation, and could be improved upon. Comments and critiques are appreciated.
Slashdot Mirror
According to recent comments (continued on the next day's thread), the win32 compiler that Mozilla use is approaching the 4GB limit, after which LibXUL (which Firefox depends upon) will no longer compile.
It's currently at 3.5GB, and at the current rate, will reach the limit in approximately 6 months: Chart of memory usage of LibXUL during last 90 days
While I think that Servo will produce a more decentralised design than Gecko and XUL, the memory limit will be reached well before that. With Windows XP support ending next year, Mozilla should consider migrating to x64 as soon as reasonably possible, keeping x32, but focusing on stripping large and extraneous code above new features.
And here's the confirmation that it was a prank. From the article:
Vas Rajlich, sitting in a "funky Internet cafe in Budapest", explained in greater detail:
It's reasonable to construct a search tree of around 10^18 positions using modern technology. The chess alpha-beta tree is thought to have at least 10^45 positions. The alpha-beta tree for the King's Gambit will be at most 10x to 100x smaller than that. So, we're still probably a good 25 or so orders of magnitude away from being able to solve something like the King's Gambit. If processing power doubles every 18 months for the next century, we'll have the resources to do this around the year 2120, plus or minus a few decades.
(Actually Vas is being overly optimistic, and we are probably overly pessimistic when we say: it will not be possible in the course of this universe. The Rybka author added the following caveat:)
You must remember that the tree for any specific 32-man position can be much smaller than we expect – if one side is immediately lost or if there is an immediate forced draw. Could the King's Gambit have a massively reduced tree? If the King's Gambit is winning for black, then this is theoretically possible. It is possible that after 2.f4 White is simply crushed instantly, no matter what he does. I very much doubt that this is the case. Everything in my chess experience tells me that any Black win would be long and tortuous. If the King's Gambit is a draw, though, then there are really no prospects for a massively reduced tree. In other words, it is (slightly) more preposterous to claim that 3.Be2 has been worked out to a draw than to claim that 3.Nf3 has been worked out to a loss.
They also state that the reason for their post being labelled as the 2nd is because they deliberately posted on "April 1st at 23:55h, i.e. five minutes before midnight – in Pago Pago." to make it less obvious. More detail in the article.
Extraordinary claims require extraordinary evidence -- no examples were provided on the page itself -- yet many of the comments above uncritically accept that this is true, only disputing the semantics.
On the page itself:
"On March 31 the author of the Rybka program, Vasik Rajlich, and his family moved from Warsaw, Poland to a new appartment in Budapest, Hungary. The next day, in spite of the bustle of moving boxes and setting up phone and Internet connections Vas, kindly agreed to the following interview, which had been planned some months ago."
Another example of an April Fools post is here, which is more obvious due to its premise. The King's Gambit post (a day late) is plausible; but that's all. You wouldn't be taken seriously if you mentioned it to a grandmaster.
While chess will face difficulties as computers and chess software become more advanced, we are along way from writing chess off as we did checkers, and probably won't do for a number of decades -- and even then, not solving every position.
There's also the news that ICANN will help cooperate with global domain seizures (posted as a /. submission, but didn't make the front page), perhaps being preceded by this.
While I'm not sure about handing control of DNS to the UN, leaving such an important and essential resource to a non-democratic organization (and the country that hosts it taking extralegal measures to seize domains) is going to become increasingly untenable, and I wouldn't be surprised if the system fragments -- or is replaced altogether -- this decade.
I'm concerned that vested interests will increasingly attempt to push control of the net's infrastructure (in spite of being counterproductive and harmful), similar to how the world economy was put on the brink in 2008, by those who want more control and power, regardless of harm or cost. That would lead to the net becoming a shadow of what it is -- with self-censorship a norm and not the exception -- and go against the spirit of its foundations being built on common interest and openness. It sounds unlikely now, but considering how far down the domain takedown road we are, not impossible to imagine.
Could a Slashdot editor please add to the summary info about the Extended Support Release for organizations released at the same time, and the new built-in web developer tools? Even a link to a website with coverage about the new changes to Firefox would do.
http://www.consilium.europa.eu/uedocs/cms_data/docs/pressdata/en/agricult/127031.pdf
Page 43 (the last one).
The press release you link to is from the Council of the European Union, primarily regarding a meeting held by the Agriculture and Fisheries (Agrifish) 'configuration' (participants are on pages 5-7). Other items on the release (page 4) unrelated to Agrifish include the environment; foreign affairs and security; trade policy; and social policy.
To be clear: Agrifish have not been involved with the Anti-counterfeiting trade agreement (ACTA). Another example of a document with ACTA in is the Foreign Affairs Council's (FAC) meeting about trade issues, with ACTA again being classed as an 'other item' (which to paraphrase, is "expected to be approved without discussion").
The Committee of Permanent Representatives (COREPER), composed of representatives from the EU states (ambassadors, civil servants etc.), meet each week to prepare the work and tasks of the Council, and monitor and co-ordinate work and deals with the Parliament. They work as part of the European Civil Service, and are responsible for reviewing the passage of ACTA. You can read also read a recent proposal to the Permanent Representatives about ACTA.
Thnak you for the link, by the way. Disappointing, though, that no expression of doubt about the subject was expressed in an earlier post; and that it was modded 4, Interesting.
No, that's correct. It was a deliberate design choice by Sun developers to make the CDDL incompatible with the GPL, using the MPL 1.1 license as a base. I wouldn't recommend CDDL due to being outdated and less popular than both MPL and GPL.
The MPL is an option for developers on Google Code, and (along with Firefox and Thunderbird) is used in Google Chrome and other software projects. There are also several licences which are forks of MPL 1.1 with minor changes by larger projects.
MPL2 sounds like what you're looking for, as it's designed to be as compatible with other licenses (including GPL and LGPL) by default (unless you add an exception), and doesn't impose conditions on how to link software. As with 1.1, in section 10.3 you have the option of forking the MPL2 if you need to for any reason as others have done - but if you're looking for a license which anyone can use with the minimum of hassle, MPL2 is in my opinion a sound choice.
You'll have to provide sources for Firefox's alleged instability. Here's a link to Mozilla's Firefox crash statistics. If you can link to a report about Chrome's stability, it would be very useful.
As for memory, Mozilla have been working on reducing memory in Firefox with the MemShrink project. Nicholas Nethercote's blog has the latest reports on improvements to the upcoming versions. Even then, it's been established before in testing that Chrome is a relative heavyweight when it comes to memory.
That's accurate. Google claims that Essence Digital and Unruly Media misinterpreted what Google wanted, and should have inserted Chrome advertising alongside content; not being content in itself, sponsored or otherwise.
An initial report: Google’s Jaw-Dropping Sponsored Post Campaign For Chrome
Follow-up: Google: Yes, Sponsored Post Campaign Was Ours But Not What We Signed-Up For
Mod parent insightful. Sadly this is the main reason why a 13 month calendar, with 4 weeks per month wouldn't be adopted.
I had thought of a system (probably not unique) of using the above, and changing the name of days, ranging from 1 to 7day, with 8day added at the end of the last week of the year, and 9day added on leap years. So 1day would always be at the beginning of the month; on the 8th; 15th; and 22nd. You would always know what day of the week it is based on the day of the month.
Today's date would be 2011-13-26, with a symbol added at the end to denote the new date format during the transition period. New Year's Eve would be on the 29th.
The main downside I can think of is that there would be potential confusion if you had two date formats for a long period of time, so would require a large number of countries to change to the new format at the same time; and that there would be a considerable amount of resistance to change.
It's a format designed for practical use with how we work with a 7-day system; however, it's incompatible with the needs of those who depend upon a fixed day system, and changes to the idea would make the format less appealing; which is a shame, really.
That's because of the memshrink project (earlier report on /.). You can read a weekly status report on Nicholas Nethercote's blog.
Another project that's recently started is called 'Snappy', which aims to increase the responsiveness of users' interactions with Firefox. There's a thread on Mozillazine tracking updates on Snappy.
I don't think it's as bad as you make out. I get the impression that version numbers were to be depreceated and replaced with the terms Beta; Aurora and Nightly. Features would be mentioned as landing on Nightly/Aurora, appearing in users' browsers in so many weeks time. Releases themselves (every 6 weeks) aren't news in themselves. If Firefox developers communicate this clearly to reporters, then perhaps perceptions will change.
If users would still benefit from version numbers (e.g. for tech support), then I have a suggestion to make:
Next year, Firefox will be releasing version 12. On that version, there's the option of transitioning to a date-based system, with major versions following the year, and minor versions being incremented every 6 weeks. After version 11, the 1st release with this format would be 12.1; the 2nd release, 12.2; and so on. Here's how it looks like in practice:
* 10.0 January 31, 2012
* 11.0 March 13, 2012
* 12.1 April 24, 2012
* 12.2 June 5, 2012
* 12.3 July 17, 2012
* 12.4 August 28, 2012
* 12.5 October 9, 2012
* 12.6 November 20, 2012
* 13.1 January 1, 2013
Switching to a date-based system has the advantage that users will know what the current version is without having to report it, as the year corresponds to the version. Firefox in 2012 would be referred to as version 12. Reporters would focus on new and upcoming features in Firefox primarily, so that stories have a talking point and posters' comments are pertinent, primarily focused on features and improvements.
An example of an open source group who uses a similar format is Ubuntu (who base the version on the year, and the minor version on a 6 month schedule). Versions matter with this format; but there's still a sense of progression. We know what the version will be in 3 years time - even if we don't know what the features will be. Now try to imagine what Firefox's version would be with the new system, compared with the old one.
Consider that this is an issue that would involve a minor change; would benefit users and reporters (reducing confusion); and improve the quality of comments (on Firefox itself), then I think that Firefox developers will be pleasantly surprised with the results.
If they do want to focus more on development than on numbers, they would benefit by switching to a date system. I hope that some of the Firefox developers read this, as the value of changing merits the effort involved.
Based on the above comments, I've made a few tweaks to the design, and have uploaded them here:
Slashdot simplified design 2011
Works in Stylish, and should work in others that support user styles with a small tweak.
There's the RequestPolicy extension for Firefox (and perhaps other Gecko-based browsers). This allows you to browse websites without third-party domains loading scripts, images and other media onto the page.
The upside to this is that you'll no longer be followed by social networking websites wherever you go. The downside is that you'll have to spend time changing the settings for some websites to work, as even CSS will be blocked when hosted on a different domain - the eternal vigilance problem.
You can also install CS Lite for cookies, BetterPrivacy for Flash cookies and NoScript, which makes it difficult to be tracked. An extra browser for when you want everything enabled temporarily (such as Opera or Chromium) works well together.
Or, 112 should be Additium. Then, 113 would be Bogofnium, and 114 Nontotientum!
(Who thought 114 could be such a boring number? That'll keep the namers busy.)
I think this is a clear case here of politicians making policies, without thinking of the long-term consequences. Or if they are, then it's either a case of short-term point-scoring, masochism, or long-term power grabs.
The idea of prosecuting people for possession of actual child porn, which has already happened, is dubious. It rests on the ideas that possession is a form of encouragement to do likewise, and that there is an underlying monetary benefit for the producer of such images.
But unlike a "war on drugs", a "war on child porn" depends heavily on the context of the situation. An image may meet the definition of child porn, but if no-one is harmed in the process, has an actual crime been commited?
It's dangerous to assume the intent of those producing porn imagery, or those who receive it, as it leads to the slippery-slope of thought-crime. If thought-crime were real, then we can all be convicted in some shape or form. The distinctions of what's legal or not become meaningless, and abuses of power come soon after.
In the age of the internet, preventing distribution of anything is practically impossible, unless extreme measures are taken. To fight your enemy, you have to know them. And that means finding out why they abuse children in the first place. To do anything else is to pretend. And perhaps, by telling everyone else what to think and do, is a form of abuse in itself.
Rlz.dll, the closed-source file that pings Google on certain actions, is still there.
It appears in the latest zipped Chromium builds too (v.6830), which wasn't there in the October builds (v.3979). Chromium only uses it if it's there, and likely the same for Chrome, so you can delete it and be happy.
OpenOffice 3.0 was released on BitTorrent a few days ago, download link: OOo_3.0.0_Win32Intel_install_en-US.exe.torrent
The RSS torrent feed (via OpenOffice P2P Downloads) has different languages, OS versions to choose from.
Why is there an EULA in the first place? The only difference between Google Chrome and Chromium is a build switch, so anyone can reject the EULA and compile their own versions, even if they can't redistribute the Chrome builds due to trademarks.
The BSD licence includes a disclaimer from liability when using the software, so no EULA is required for this. Google's online services have an EULA when you use them, but this isn't necessary for an open source browser.
Maybe, Google are concerned about their privacy policy, when consent is required for data to be collected on users. And Section 10.2 of the EULA isn't required for an open source browser, so it's possible for Chrome to include closed source code in the future, which the BSD licence permits.
This makes me feel uneasy about using Chrome. I hope that Google don't get so caught up in collecting information on users, that they miss focusing on building a good browser.
Looking at the first photo in the link, I keep looking at his right eye, it doesn't look right, as though the position of the skin is off. Based on the fourth photo, his skin around his eye was repaired and not from the donor. But it's made me think this could be a problem for face transplants, when the position of the skin around the eyes of the donor doesn't match the recipient's.
While full face transplants in the future are going to raise a lot of interest and intrigue, I think they are only going to be made in extreme circumstances, as where possible, it's probably best to keep the existing facial features than replace them unnecessarily.
A couple of items of interest displayed at Siggraph this year as well which I think have potential.
Microsoft's come up with a way of painting objects onto an object extracted from a video, then reinserted to the video that remains accurate when the camera angle's changed. Their research paper's called Unwrap Mosaics, and you can see a video on Youtube here (higher quality video on the reseach page).
A company called Image Metrics have made a video with actress Emily O'Brien, using Light Stage technology from USC's Institute of Creative Technologies (an example of this is on a Google presentation called New Techniques for Rendering Human Performances) to create a realistic animated virtual face, that has convinced an editor on VFXWorld that they've passed the uncanny valley. Article is here.
I've been thinking that it was only a matter of time until editing video would become similar to editing photos, I just though it would take a lot more time, but everything is already here. They can even create realistic hair based on photos, just think what technology we'll have in the next decade, this could be in our homes by then.
While helping maintain work on an old game's source code, the thorny problem of which data storage format to use propped up, to replace the inflexible one in use with fixed references. There's two main developers, one who wants XML for flexibility, the other a binary format for speed and size.
XML was the main choice, but maintaining the files is trickier than it appears. It's one of the least "human readable" formats I've seen, much more so than HTML, where you know what each tag intrinsically means. This irks the second developer, who would otherwise have accepted a compromise, and there's a stalemate on the issue.
We have skipped around the issue and instead started work on adding other features and bugfixes. The only implementation which I did notice could work was SweetXML, though the time required to set this up wouldn't be as quick.
XML, and it's derivatives such as XAML, need to be easier to read and edit before they can become fully fledged on the web.
You have a point, there is no may in the sentence!
Though Wikipedia does mention that Arrow's impossibility theorem isn't necessarily connected to range voting, which is what the proposal was based on. See the properties section on the link below for the reference.
http://en.wikipedia.org/wiki/Range_voting
This is an idea for a balanced voting system.
As you note, there's a problem with systems where you can give candidates a certain rating, there would be the tendency to rank one candidate 10 and the others 1. This system would attempt to balance the rating system with the ranked ones, limiting the extremes of rating, while giving the voter more choice than using rank only.
You would have a number of votes, based on the number of candidates and triangular numbers, and you can give a certain number of votes to each candidate. So 4 candidates, leads to 10 votes, 5 candidates, to 15, and so on.
Say there are 3 candidates, leading to 6 votes. The maximum you can give to a candidate is the same as the number of candidates, in this case 3.
For example, Lucy votes as follows: Andy 3, Barbara 2, Clive 1. She could also vote for Andy to have 3, without giving any votes to the others.
Another example, Max only cares about Clive, and would vote 6 if possible. Because he is unable to do so, this means he has to give the others consideration. As a result, he gives Clive 3, and Barbara 1 vote.
The results are tallied, and the winning order's based on the number of votes.
This system may be subject to manipulation, and could be improved upon. Comments and critiques are appreciated.