If a spammer or phisher would reverse engineer a protocol, it's very unlikely they would publish about it, since that would help their competition. It is possible that spammers or phishers will use the results of reverse engineering of course, but if your protection against malicious activities consists of a secret protocol then you should consider implementing real security instead of blaming the reverse engineering.
In any case it's clear that Skype doesn't want third party clients to interoperate with their own, so instead of getting into a cat and mouse game it would be more useful to improve existing open source VOIP clients so Skype can be replaced altogether.
Do you have any documentation for that? As far as I know, the only plan for a new nuclear plant is near the existing one in Borssele, which is near Belgium but about as far away from Germany as you can get in the Netherlands. There are plans for two new coal plants near the German border though, which (unless there is a nuclear disaster) are far worse in terms of pollution.
Unless you're playing the game with a light gun, the game cannot read pixels from the screen, only from the emulated machine's video RAM. And the frame in video RAM is usually in some kind of color indexed format, maybe even in a tiled video mode, so there is already a step in the emulator to convert the video RAM contents to a simple frame buffer in RGB or YUV format. This frame represents what the video output plug of the emulated machine would output. Then you can apply an upscale algorithm to it if you want to display it on a higher resolution. For the best performance, upload the unscaled RGB/YUV frame to a texture and do the upscaling with a pixel shader.
You don't need direct access to the GPU, you can use pixel shaders instead. To capture the frame buffer, you can run the game in DOSBox, QEMU or VirtualBox, which are open source. So, get to work!;)
Pixel resamplers have the same problem: if you have a sprite moving over a background which has some colors in common with the sprite, the scale algorithm will detect the wrong edges and you'll see artifacts. However, even though it is not perfect the result is still acceptable to most people.
A pixel scaler is an algorithm that makes a different resolution output image, for example upscaling 320x240 to 640x480. Most existing pixel scalers look at neighboring pixels (2x2 or 3x3 area) to decide how to replace one input pixel with NxN output pixels.
A vectorizer is an algorithm that creates a vector representation of an image input as pixels. You can then use that vector representation to render at a higher resolution (any zoom factor, not just integer values), but you could do other things such as rendering at the same resolution but with anti-aliasing or even scaling down.
I'm starting to get the impression that it can be safe or inexpensive, but not both at the same time. For example, modern reactor designs are said to be much safer than the old ones, yet reactors built 40 years ago are still running all over the world. Replacing them would improve safety, but it is very expensive.
I think this is a generic problem with metrics: the things that are easy to measure do not necessarily correspond with the things you want to know. While citations have some relation to the scientific value of publications, it is not an extremely strong correlation. And since citations play a major role in performance evaluation of researchers, there is motivation to game the system.
On the other hand, you cannot directly measure some property that is not clearly defined. Is it better to measure something that is inaccurate or to not measure at all? In my opinion it is useful to measure but you should be very careful in interpreting the results. For example, if you measure the lines of code in a project, the result is useful to determine how much effort it takes to maintain the code, but as an indicator of productivity it is so flawed that it is better to ignore it.
What I gathered from the previous articles is that Bionic includes headers that are automatically generated from the Linux kernel headers with a statement added by Google that those generated headers contain no copyrightable material. What glibc does is compile against the unmodified Linux kernel headers, which must be present in some directory on the machine doing the build. So glibc includes the kernel headers by means of the C #include preprocessor directive, not by copying text fragments from them into the library package. I haven't looked at the Bionic sources, so I haven't verified this myself; it is based on statements in the articles.
What I wonder is why Google would not simply compile their libc against the Linux kernel source, like glibc does. That would avoid the legal uncertainty. Is there anyone familiar with the Android internals who can shed some light on this?
Most US cell phones are free or almost free. The fact that you're getting a free phone in exchange for paying thousands of dollars over two years for service seems to be lost on most consumers here.
In Europe most people buy subsidized phones too. But unless you want a very expensive phone + plan, it will add up to hundreds of euros, not thousands, over two years. Buying phone and service separately is slightly cheaper, but not spectacularly.
Americans also regularly pay over $100 per month for cable TV... and there are ads on almost every channel (often taking up a full third of every hour of programming!), not to mention pay-per-view channels.
Where I live (the Netherlands), the cable networks were owned by the local governments until the 90s. When the networks were sold, it was done under strict conditions about pricing and availability of channels. I think I pay about 16 euros/month for about 30 channels of analog TV.
Indeed, how do Americans fall for this stuff while people in other nations seem to be able to get better deals? Are we really just that dumb?
Regulation is part of the difference. It seems many Americans are allergic to government involvement, but it does help competition if for example carriers are forced to migrate your existing phone number if you switch from one carrier to another. And the fact that you can switch carriers at all while keeping the same handset is also a consequence of regulation.
Another difference is the way people look at contracts and laws. In the USA, it's all about the letter of the law, while in much of Europe it's about the spirit of the law. I'm exaggerating a bit here, but if you sign a contract that is a bad deal for you, in the USA you would be considered stupid for signing it and you would be stuck with it, while in Europe the other party would be considered to have offered you an unfair deal. It could lead to bad PR and parts of the contract could be declared void by a judge.
In negotiations, the party who has more power will get the better deal. If there is a transparent market with many sellers, the buyer has the power. Telecom is a market with few sellers due to the huge infrastructure investments needed and the carriers are doing everything they can to make the market less transparent by offering complex plans that are hard to compare (subsidized phones are part of that, voice/text/data bundles as well). If you add lock-in, the power is very much on the side of the carriers unless there are other factors pushing in favor of the consumers.
"Renewable" doesn't mean "perpetual", it means "lasts as long as the sun". The sun won't last forever, but probably well over a billion years, while oil will likely be depleted in under 100 years (and maybe far sooner than that).
I guess I haven't read enough about how malware works lately. If the connection is initiated from the victim's PC then port scanning is already useless.
It is perfectly reasonable for anyone coming in virtual contact with your data to request that you prove that your data is sanitary.
One of the rules in computer security is to never trust the client. A server should always fully validate the data regardless of what assurances the client gives about it, so it is pointless to send those assurances in the first place.
From TFA: "A bank could ask customers to sign up for a program that would scan their PC for signs of infection during online sessions"
I think "program" here means an initiative by the bank that a customer can optionally participate in, rather than an executable running on the customer's PC. It might be a port scan done from the bank's servers.
Still I doubt this is actually useful: if these scans becomes common practice, malware can stay undetected by not responding or faking another protocol/application unless the contact is initiated in a particular way that only the malware control network can perform. For example a TCP connection would only be accepted if preceded by a port knocking sequence that is computed from the victim's IP address and a private key, making it impossible for the bank to replay that sequence when scanning another PC.
I am not convinced that "opting out of behavioral advertising" is the same as "do not track". The page describing the opt-out initiative contains the following sentence:
In some cases, automated systems will continue to collect other data about browser visits but that data will no longer be used to deliver interest-based advertising to the user.
This suggests that tracking might still happen, but the ads served will not be based on the collected information if you opt out. That does not sound like much of an improvement in online privacy.
Android uses a Linux kernel, but everything on top of that is completely different from desktop Linux systems (even the libc is different). iOS uses a Darwin kernel and shares some frameworks with OS X, but important parts like UIKit are very different. MeeGo uses Linux + Qt and is the closest of the three to its desktop equivalent, but even there the window management and the apps are different from the desktop.
It might make sense to use the Windows kernel on a phone, but not the high level UI or existing Windows apps. So if apps have to be redesigned and rewritten anyway, the question is whether it really matters that the kernel is shared.
How relevant will TV, radio, Blu-ray etc be in 2020? CD sales are already being replaced by digital downloads and while a lot of people continue to listen to the radio, they often do so by streaming it over the net. I see no reason why the future would be different for video.
What does pee me off however, is that the DVDs seem to have episodes out of sequence and the disks are littered with promos for other SG episodes, movies, etc -- plus the obligatory, unskippable copyright warnings. When I get time, I *will* rip these disks to DVDR so I don't have to sit through all that crap!
It might be easier to fix the player: unskippable sections are a misfeature and any user friendly player should ignore that flag. On a computer you can use for example VLC. I don't know what devices are available that obey the user's commands rather than the disc author's, but I'm guessing that at least the ones with open source firmware will (or have fixes available in the community).
Firmware is the software that runs on the device (PCI card, USB device etc), not on the CPU. This is unrelated to binary blobs like the NVIDIA driver, which do run on the CPU.
The VPRO documentary was first broadcast on November 23. I don't know when the interviews in it were made, it might be some months before. In the interviews Felisa says she does not have proof of life using arsenic instead of phosphor yet. So I'm guessing that she does have proof now and will present it in the press conference.
I think that the development process should be selected to match the particular project and the stage it is in. There is no perfect process that applies to every project, or even to one project forever. A team of 4 in a single room working on a demo for a new product idea will have very different requirements from a team of 20 working in two locations on an improved version of a product that is already in production...
There are two conflicting goals: to avoid breaking the main branch (trunk) and to get changes out to the other developers soon. A broken main branch wastes the time of other developers on the project. But integrating changes late has its own inefficiencies: Problems in the modifications will only be raised after the work is done. It is more likely for one set of modifications to conflict with another set if both are being developed in parallel for a longer time. Other developers might have to wait for a full set of changes to arrive while they only need a subset, or they might start merging the subset from each other's development branches, creating a confusing mix of versions.
Committing directly into trunk can be acceptable and even desirable depending on the project. It depends on how likely commits are to break the code: How many developers are there? How many mistakes do they make? (a combination of experience and carefulness) Is there decent test coverage before committing? How fragile is the code base; are there many unexpected side effects? And it depends on how much damage a broken main branch does: How long does it typically take to find and fix a problem? How modular is the code base: will a bug in one part be a nuisance to developers working on another part? And it also depends on how much there is to gain from early merging: Is the project in the start-up phase where it is likely that other developers are waiting for new core functionality, or is the code base mature and are most changes done on the edges of the program? Are all design decisions made before code is written or are developers doing design and implementation work at the same time?
If they learned from their mistakes and adopted safer coding practices and added infrastructure that enforces proper security on the code then the review has paid off. On the other hand, if they only fixed the security bugs that were pointed out and continued coding the way they did before then it will never be secure since there won't be enough reviewers to keep up with all the new bugs being added.
Yes, things would have been worse if this source was not open, but that doesn't necessarily mean the code is good enough now.
Slashdot Mirror
If a spammer or phisher would reverse engineer a protocol, it's very unlikely they would publish about it, since that would help their competition. It is possible that spammers or phishers will use the results of reverse engineering of course, but if your protection against malicious activities consists of a secret protocol then you should consider implementing real security instead of blaming the reverse engineering.
In any case it's clear that Skype doesn't want third party clients to interoperate with their own, so instead of getting into a cat and mouse game it would be more useful to improve existing open source VOIP clients so Skype can be replaced altogether.
Do you have any documentation for that? As far as I know, the only plan for a new nuclear plant is near the existing one in Borssele, which is near Belgium but about as far away from Germany as you can get in the Netherlands. There are plans for two new coal plants near the German border though, which (unless there is a nuclear disaster) are far worse in terms of pollution.
Unless you're playing the game with a light gun, the game cannot read pixels from the screen, only from the emulated machine's video RAM. And the frame in video RAM is usually in some kind of color indexed format, maybe even in a tiled video mode, so there is already a step in the emulator to convert the video RAM contents to a simple frame buffer in RGB or YUV format. This frame represents what the video output plug of the emulated machine would output. Then you can apply an upscale algorithm to it if you want to display it on a higher resolution. For the best performance, upload the unscaled RGB/YUV frame to a texture and do the upscaling with a pixel shader.
You don't need direct access to the GPU, you can use pixel shaders instead. To capture the frame buffer, you can run the game in DOSBox, QEMU or VirtualBox, which are open source. So, get to work! ;)
Pixel resamplers have the same problem: if you have a sprite moving over a background which has some colors in common with the sprite, the scale algorithm will detect the wrong edges and you'll see artifacts. However, even though it is not perfect the result is still acceptable to most people.
A pixel scaler is an algorithm that makes a different resolution output image, for example upscaling 320x240 to 640x480. Most existing pixel scalers look at neighboring pixels (2x2 or 3x3 area) to decide how to replace one input pixel with NxN output pixels.
A vectorizer is an algorithm that creates a vector representation of an image input as pixels. You can then use that vector representation to render at a higher resolution (any zoom factor, not just integer values), but you could do other things such as rendering at the same resolution but with anti-aliasing or even scaling down.
Nuclear power can be safe and inexpensive, [...]
I'm starting to get the impression that it can be safe or inexpensive, but not both at the same time. For example, modern reactor designs are said to be much safer than the old ones, yet reactors built 40 years ago are still running all over the world. Replacing them would improve safety, but it is very expensive.
I think this is a generic problem with metrics: the things that are easy to measure do not necessarily correspond with the things you want to know. While citations have some relation to the scientific value of publications, it is not an extremely strong correlation. And since citations play a major role in performance evaluation of researchers, there is motivation to game the system.
On the other hand, you cannot directly measure some property that is not clearly defined. Is it better to measure something that is inaccurate or to not measure at all? In my opinion it is useful to measure but you should be very careful in interpreting the results. For example, if you measure the lines of code in a project, the result is useful to determine how much effort it takes to maintain the code, but as an indicator of productivity it is so flawed that it is better to ignore it.
The first recorded bubble was almost 400 years ago, so I doubt this will be the last bubble.
What I gathered from the previous articles is that Bionic includes headers that are automatically generated from the Linux kernel headers with a statement added by Google that those generated headers contain no copyrightable material. What glibc does is compile against the unmodified Linux kernel headers, which must be present in some directory on the machine doing the build. So glibc includes the kernel headers by means of the C #include preprocessor directive, not by copying text fragments from them into the library package. I haven't looked at the Bionic sources, so I haven't verified this myself; it is based on statements in the articles.
What I wonder is why Google would not simply compile their libc against the Linux kernel source, like glibc does. That would avoid the legal uncertainty. Is there anyone familiar with the Android internals who can shed some light on this?
Most US cell phones are free or almost free. The fact that you're getting a free phone in exchange for paying thousands of dollars over two years for service seems to be lost on most consumers here.
In Europe most people buy subsidized phones too. But unless you want a very expensive phone + plan, it will add up to hundreds of euros, not thousands, over two years. Buying phone and service separately is slightly cheaper, but not spectacularly.
Americans also regularly pay over $100 per month for cable TV... and there are ads on almost every channel (often taking up a full third of every hour of programming!), not to mention pay-per-view channels.
Where I live (the Netherlands), the cable networks were owned by the local governments until the 90s. When the networks were sold, it was done under strict conditions about pricing and availability of channels. I think I pay about 16 euros/month for about 30 channels of analog TV.
Indeed, how do Americans fall for this stuff while people in other nations seem to be able to get better deals? Are we really just that dumb?
Regulation is part of the difference. It seems many Americans are allergic to government involvement, but it does help competition if for example carriers are forced to migrate your existing phone number if you switch from one carrier to another. And the fact that you can switch carriers at all while keeping the same handset is also a consequence of regulation.
Another difference is the way people look at contracts and laws. In the USA, it's all about the letter of the law, while in much of Europe it's about the spirit of the law. I'm exaggerating a bit here, but if you sign a contract that is a bad deal for you, in the USA you would be considered stupid for signing it and you would be stuck with it, while in Europe the other party would be considered to have offered you an unfair deal. It could lead to bad PR and parts of the contract could be declared void by a judge.
In negotiations, the party who has more power will get the better deal. If there is a transparent market with many sellers, the buyer has the power. Telecom is a market with few sellers due to the huge infrastructure investments needed and the carriers are doing everything they can to make the market less transparent by offering complex plans that are hard to compare (subsidized phones are part of that, voice/text/data bundles as well). If you add lock-in, the power is very much on the side of the carriers unless there are other factors pushing in favor of the consumers.
"Renewable" doesn't mean "perpetual", it means "lasts as long as the sun". The sun won't last forever, but probably well over a billion years, while oil will likely be depleted in under 100 years (and maybe far sooner than that).
I guess I haven't read enough about how malware works lately. If the connection is initiated from the victim's PC then port scanning is already useless.
Maybe he got the idea while standing in a queue for an airport security check...
It is perfectly reasonable for anyone coming in virtual contact with your data to request that you prove that your data is sanitary.
One of the rules in computer security is to never trust the client. A server should always fully validate the data regardless of what assurances the client gives about it, so it is pointless to send those assurances in the first place.
From TFA:
"A bank could ask customers to sign up for a program that would scan their PC for signs of infection during online sessions"
I think "program" here means an initiative by the bank that a customer can optionally participate in, rather than an executable running on the customer's PC. It might be a port scan done from the bank's servers.
Still I doubt this is actually useful: if these scans becomes common practice, malware can stay undetected by not responding or faking another protocol/application unless the contact is initiated in a particular way that only the malware control network can perform. For example a TCP connection would only be accepted if preceded by a port knocking sequence that is computed from the victim's IP address and a private key, making it impossible for the bank to replay that sequence when scanning another PC.
I am not convinced that "opting out of behavioral advertising" is the same as "do not track". The page describing the opt-out initiative contains the following sentence:
In some cases, automated systems will continue to collect other data about browser visits but that data will no longer be used to deliver interest-based advertising to the user.
This suggests that tracking might still happen, but the ads served will not be based on the collected information if you opt out. That does not sound like much of an improvement in online privacy.
Android uses a Linux kernel, but everything on top of that is completely different from desktop Linux systems (even the libc is different). iOS uses a Darwin kernel and shares some frameworks with OS X, but important parts like UIKit are very different. MeeGo uses Linux + Qt and is the closest of the three to its desktop equivalent, but even there the window management and the apps are different from the desktop.
It might make sense to use the Windows kernel on a phone, but not the high level UI or existing Windows apps. So if apps have to be redesigned and rewritten anyway, the question is whether it really matters that the kernel is shared.
How relevant will TV, radio, Blu-ray etc be in 2020? CD sales are already being replaced by digital downloads and while a lot of people continue to listen to the radio, they often do so by streaming it over the net. I see no reason why the future would be different for video.
What does pee me off however, is that the DVDs seem to have episodes out of sequence and the disks are littered with promos for other SG episodes, movies, etc -- plus the obligatory, unskippable copyright warnings. When I get time, I *will* rip these disks to DVDR so I don't have to sit through all that crap!
It might be easier to fix the player: unskippable sections are a misfeature and any user friendly player should ignore that flag. On a computer you can use for example VLC. I don't know what devices are available that obey the user's commands rather than the disc author's, but I'm guessing that at least the ones with open source firmware will (or have fixes available in the community).
Firmware is the software that runs on the device (PCI card, USB device etc), not on the CPU. This is unrelated to binary blobs like the NVIDIA driver, which do run on the CPU.
Also, KDE veteran Aaron Seigo wrote a blog entry about the split.
The VPRO documentary was first broadcast on November 23. I don't know when the interviews in it were made, it might be some months before. In the interviews Felisa says she does not have proof of life using arsenic instead of phosphor yet. So I'm guessing that she does have proof now and will present it in the press conference.
I think that the development process should be selected to match the particular project and the stage it is in. There is no perfect process that applies to every project, or even to one project forever. A team of 4 in a single room working on a demo for a new product idea will have very different requirements from a team of 20 working in two locations on an improved version of a product that is already in production...
There are two conflicting goals: to avoid breaking the main branch (trunk) and to get changes out to the other developers soon. A broken main branch wastes the time of other developers on the project. But integrating changes late has its own inefficiencies: Problems in the modifications will only be raised after the work is done. It is more likely for one set of modifications to conflict with another set if both are being developed in parallel for a longer time. Other developers might have to wait for a full set of changes to arrive while they only need a subset, or they might start merging the subset from each other's development branches, creating a confusing mix of versions.
Committing directly into trunk can be acceptable and even desirable depending on the project. It depends on how likely commits are to break the code: How many developers are there? How many mistakes do they make? (a combination of experience and carefulness) Is there decent test coverage before committing? How fragile is the code base; are there many unexpected side effects? And it depends on how much damage a broken main branch does: How long does it typically take to find and fix a problem? How modular is the code base: will a bug in one part be a nuisance to developers working on another part? And it also depends on how much there is to gain from early merging: Is the project in the start-up phase where it is likely that other developers are waiting for new core functionality, or is the code base mature and are most changes done on the edges of the program? Are all design decisions made before code is written or are developers doing design and implementation work at the same time?
If they learned from their mistakes and adopted safer coding practices and added infrastructure that enforces proper security on the code then the review has paid off. On the other hand, if they only fixed the security bugs that were pointed out and continued coding the way they did before then it will never be secure since there won't be enough reviewers to keep up with all the new bugs being added.
Yes, things would have been worse if this source was not open, but that doesn't necessarily mean the code is good enough now.