The EULA for the Flash player claims to forbid you from making your own implementation. This means that the Gnash project can't accept help from anyone who has installed Adobe's plugin. Whether click-through licences are legally binding is questionable, but in the end it doesn't matter whether they are binding or not, just whether they give an opportunity for lawyers to tie you up in long court cases, which is probably true.
Will Adobe be granting permission to work on Flash implementations to those who have installed their software? I didn't spot anything about that in their FAQ.
I run Fedora. Recently they seem to put out a new kernel package every week or so. Of course you need to reboot to install a kernel security fix, which is what TFA is all about.
IMHO this makes a lot of sense. You can do whatever the hell you want with the CD you purchased - the only thing you cannot do is make a copy of it, with limited exceptions for fair dealing. That's traditionally how copyright law worked and it's how it still applies to books. It just needs to be explicit that the temporary copy made in the memory of the CD player or the computer to play the music does not infringe copyright.
Of course, the publishers want to have it both ways - at some times to insist on a strict interpretation of traditional copyright, and at others to insist that what you bought is a 'licence' rather than a CD or computer program, and they can restrict you even further than copyright allows.
Some desktop LCD panels let you rotate them by 90 degrees to get a 'portrait' format display, which is ideal for programming. Clearly all you need do is plug in an external keyboard and then prop up your laptop like a book, and you'd get a lovely narrowscreen display for running emacs.
Interesting to see that 2.5" form factor disks are now faster than their desktop-size cousins. In a way it's a shame that WD decided to bulk out the case with extra heatsinks... it would have been more fun for them to ship a properly sized 2.5" drive you could put in your laptop.
The review only compares the new drive to older models from the same manufacturer, and it turns out to be faster - duh. How does the performance compare with those expensive solid state disks that are starting to appear?
Read TFA... if some people get the patch before others, they can use it to create a working exploit quickly. To avoid this you have to give the update to everyone at the same moment.
Legally I doubt the situation is any different from knowing about a vulnerability and having it fixed internally, but not bothering to announce the vulnerability or release the fix until it's convenient for you (which happens all the time in the proprietary software world).
I didn't suggest waiting for every last user; in any case nobody has a record of how many Windows users there are. Just waiting say three days, which should be long enough for 99% of Internet-connected machines to download the encrypted update, and then releasing the key so they can all update at once.
Right, and you religiously do this every time after the automated update runs? And so do all other Linux users?
[auto-restarting a service after installing an update]
That's been quite standard for a long time.
For server programs like Apache, maybe. It depends on the rpm spec file. But certainly not for bash, or perl, or X11, or many other things that might have a security bug. As I said, it's mostly a question of luck.
I'm not saying that forcing a reboot is always better - certainly I myself don't reboot my Linux box after installing updates - just pointing out that it may be necessary if you have your paranoia level set to high. Which might be the most appropriate setting, in the world of Windows and botnets.
The idea is that because the key is so short (if you used AES encryption, for example, it would only need to be 32 bytes long) it could be distributed very quickly and would be hard for a DDOS to stop.
The bad guys can't crack a symmetric cipher like AES (or if they can, we are all in much worse trouble than we thought). Similarly they can't break in to servers belonging to Microsoft to grab the key early (or if they can, Microsoft and its users are all in much worse trouble than we thought).
But after running your slick auto-update command in Linux and watching it smoothly install new versions without rebooting the machine, are you 100% sure you're not still running some vulnerable code? What if bash had a vulnerability, and you installed the new version but old bash processes were still running? Services like apache can be restarted, and if you're really lucky then the package manager will know to restart the service after installing a new version. But how confident are you that everything is covered?
At least if you reboot you can be pretty sure that only the new code is running. It's a crude but effective method.
One way is to make systems start up in a restricted mode where all they can do is connect to the update server and check they have all the latest security patches. That way, systems that were switched off when the update was announced will catch up on the next boot.
Patches could be in two parts: the first part just says what service is affected (and should thus be shut down until patched), and the second part contain the actual code. Even hosts on slow network connections would be able to get the first part of the patch, and once the key is revealed to the world, shut down the vulnerable service. It wouldn't restart until the new code was downloaded and installed.
You are right that you could never get 100% coverage. But it would certainly help reduce the window of vulnerability from several days to a few seconds. That still might not be enough.
You can certainly distribute the patch synchronously to 99% of the PCs (the other 1% being those not connected to the Internet or with broken auto-update). Distribute an encrypted patch, and then once all clients have downloaded it reveal the key, which is short and can be sent in a single network packet. Clients could even distribute the key among themselves peer-to-peer. The bigger problem is the timelag between the patch being revealed to the world and the machine starting to run the upgraded version of the software (which often requires a reboot). It might be necessary for patches to contain instructions saying to stop the vulnerable service immediately and not bring it back up until the new code is installed.
However, would such a scheme be compatible with free software? Under the GPL, would a Linux distributor be permitted to send out encrypted binary patches and only reveal the decryption key later?
When you set up your wireless network you can choose whether to allow open access or not. If the network's owner has specified that anyone can use it, why is it bad to do so? I have my wireless router at home set up for open access and it does me no harm if others use it for occasional web browsing. The only flaw is that many routers don't have a way to prioritize or cap usage so that my work isn't slowed down by other people's Bittorrenting.
Yes, it's sent unencrypted - just like network traffic over those old-fashioned things called wires. We all know to use https and ssh for secure connections anyway.
Does SQLite still accept "hello" as an integer? Does it still completely ignore foreign key constraints? Honestly, people like to beat up MySQL for not enforcing data integrity (especially a few years ago), but at least they make some effort.
I sympathize; I remember in the old days using several small windows but over the past few years I've got more used to having each app in a single window which is always maximized. So my web browser is full screen, as is xemacs, and the mail client, and anything else. This despite desktop resolution being several times greater. Partly the fault is with cluttered interfaces that have too many menubars and toolbars, partly 'Windows weenies' (which might even include me) who are used to a big document window with its own buttons in the window, rather than separate toolbox windows.
Apart from MDI, the biggest user interface design mistake made and perpetuated by Microsoft Windows is the way that you cannot do anything in a window without it being forced to the top. This makes it awkward to use overlapping windows on your screen - you end up either carefully tiling the windows so that they don't overlap, or going with one big maximized window at a time. I greatly prefer the approach taken by ROX where you can work in background windows and they stay background, unless you choose to bring them to the front by clicking on the title bar.
Your argument would make sense if most other applications on Linux used the same archipelago-of-small-windows approach the Gimp does. It would be the standard way of working to set up multiple virtual desktops with one for each app. But practically no other graphical program is like that, even on Unix-like systems. Even if the Gimp's way is theoretically superior, what matters most of all is consistency and not having each app reinvent the wheel in its own peculiar way. So the Gimp needs to get a more conventional user interface style.
(Are multiple desktops set up by default in a typical Linux distribution these days?)
Could you explain what you find objectionable about the name?
Would your engineering review board also have a problem with the name of the program? Or would they politely pretend not to notice and approve it with a straight face?
Slashdot Mirror
The EULA for the Flash player claims to forbid you from making your own implementation. This means that the Gnash project can't accept help from anyone who has installed Adobe's plugin. Whether click-through licences are legally binding is questionable, but in the end it doesn't matter whether they are binding or not, just whether they give an opportunity for lawyers to tie you up in long court cases, which is probably true.
Will Adobe be granting permission to work on Flash implementations to those who have installed their software? I didn't spot anything about that in their FAQ.
RMS's job title at the FSF is 'chief GNUisance'.
Governmental Wikipedia editing around the world:
Japan: "The agriculture ministry is not in charge of Gundam"
USA: "The defense department is in charge of Gitmo"
Then to freak them out even more, you can make the clock tick backwards...
I run Fedora. Recently they seem to put out a new kernel package every week or so. Of course you need to reboot to install a kernel security fix, which is what TFA is all about.
Who cares about servers? I want my Linux desktop to stay up-to-date with security fixes without having to reboot it every few days.
Bah, that's "over 83 metres per second" to all right-thinking people.
IMHO this makes a lot of sense. You can do whatever the hell you want with the CD you purchased - the only thing you cannot do is make a copy of it, with limited exceptions for fair dealing. That's traditionally how copyright law worked and it's how it still applies to books. It just needs to be explicit that the temporary copy made in the memory of the CD player or the computer to play the music does not infringe copyright.
Of course, the publishers want to have it both ways - at some times to insist on a strict interpretation of traditional copyright, and at others to insist that what you bought is a 'licence' rather than a CD or computer program, and they can restrict you even further than copyright allows.
Some desktop LCD panels let you rotate them by 90 degrees to get a 'portrait' format display, which is ideal for programming. Clearly all you need do is plug in an external keyboard and then prop up your laptop like a book, and you'd get a lovely narrowscreen display for running emacs.
Interesting to see that 2.5" form factor disks are now faster than their desktop-size cousins. In a way it's a shame that WD decided to bulk out the case with extra heatsinks... it would have been more fun for them to ship a properly sized 2.5" drive you could put in your laptop.
The review only compares the new drive to older models from the same manufacturer, and it turns out to be faster - duh. How does the performance compare with those expensive solid state disks that are starting to appear?
Read TFA... if some people get the patch before others, they can use it to create a working exploit quickly. To avoid this you have to give the update to everyone at the same moment.
Legally I doubt the situation is any different from knowing about a vulnerability and having it fixed internally, but not bothering to announce the vulnerability or release the fix until it's convenient for you (which happens all the time in the proprietary software world).
I didn't suggest waiting for every last user; in any case nobody has a record of how many Windows users there are. Just waiting say three days, which should be long enough for 99% of Internet-connected machines to download the encrypted update, and then releasing the key so they can all update at once.
[auto-restarting a service after installing an update]For server programs like Apache, maybe. It depends on the rpm spec file. But certainly not for bash, or perl, or X11, or many other things that might have a security bug. As I said, it's mostly a question of luck.
I'm not saying that forcing a reboot is always better - certainly I myself don't reboot my Linux box after installing updates - just pointing out that it may be necessary if you have your paranoia level set to high. Which might be the most appropriate setting, in the world of Windows and botnets.
The idea is that because the key is so short (if you used AES encryption, for example, it would only need to be 32 bytes long) it could be distributed very quickly and would be hard for a DDOS to stop.
The bad guys can't crack a symmetric cipher like AES (or if they can, we are all in much worse trouble than we thought). Similarly they can't break in to servers belonging to Microsoft to grab the key early (or if they can, Microsoft and its users are all in much worse trouble than we thought).
But after running your slick auto-update command in Linux and watching it smoothly install new versions without rebooting the machine, are you 100% sure you're not still running some vulnerable code? What if bash had a vulnerability, and you installed the new version but old bash processes were still running? Services like apache can be restarted, and if you're really lucky then the package manager will know to restart the service after installing a new version. But how confident are you that everything is covered?
At least if you reboot you can be pretty sure that only the new code is running. It's a crude but effective method.
One way is to make systems start up in a restricted mode where all they can do is connect to the update server and check they have all the latest security patches. That way, systems that were switched off when the update was announced will catch up on the next boot.
Patches could be in two parts: the first part just says what service is affected (and should thus be shut down until patched), and the second part contain the actual code. Even hosts on slow network connections would be able to get the first part of the patch, and once the key is revealed to the world, shut down the vulnerable service. It wouldn't restart until the new code was downloaded and installed.
You are right that you could never get 100% coverage. But it would certainly help reduce the window of vulnerability from several days to a few seconds. That still might not be enough.
You can certainly distribute the patch synchronously to 99% of the PCs (the other 1% being those not connected to the Internet or with broken auto-update). Distribute an encrypted patch, and then once all clients have downloaded it reveal the key, which is short and can be sent in a single network packet. Clients could even distribute the key among themselves peer-to-peer. The bigger problem is the timelag between the patch being revealed to the world and the machine starting to run the upgraded version of the software (which often requires a reboot). It might be necessary for patches to contain instructions saying to stop the vulnerable service immediately and not bring it back up until the new code is installed.
However, would such a scheme be compatible with free software? Under the GPL, would a Linux distributor be permitted to send out encrypted binary patches and only reveal the decryption key later?
Quit complaining, it's still in beta.
When you set up your wireless network you can choose whether to allow open access or not. If the network's owner has specified that anyone can use it, why is it bad to do so? I have my wireless router at home set up for open access and it does me no harm if others use it for occasional web browsing. The only flaw is that many routers don't have a way to prioritize or cap usage so that my work isn't slowed down by other people's Bittorrenting.
Yes, it's sent unencrypted - just like network traffic over those old-fashioned things called wires. We all know to use https and ssh for secure connections anyway.
I hope the forms they submit are only GET request forms and not POST ones.
Does SQLite still accept "hello" as an integer? Does it still completely ignore foreign key constraints? Honestly, people like to beat up MySQL for not enforcing data integrity (especially a few years ago), but at least they make some effort.
I sympathize; I remember in the old days using several small windows but over the past few years I've got more used to having each app in a single window which is always maximized. So my web browser is full screen, as is xemacs, and the mail client, and anything else. This despite desktop resolution being several times greater. Partly the fault is with cluttered interfaces that have too many menubars and toolbars, partly 'Windows weenies' (which might even include me) who are used to a big document window with its own buttons in the window, rather than separate toolbox windows.
Apart from MDI, the biggest user interface design mistake made and perpetuated by Microsoft Windows is the way that you cannot do anything in a window without it being forced to the top. This makes it awkward to use overlapping windows on your screen - you end up either carefully tiling the windows so that they don't overlap, or going with one big maximized window at a time. I greatly prefer the approach taken by ROX where you can work in background windows and they stay background, unless you choose to bring them to the front by clicking on the title bar.
Your argument would make sense if most other applications on Linux used the same archipelago-of-small-windows approach the Gimp does. It would be the standard way of working to set up multiple virtual desktops with one for each app. But practically no other graphical program is like that, even on Unix-like systems. Even if the Gimp's way is theoretically superior, what matters most of all is consistency and not having each app reinvent the wheel in its own peculiar way. So the Gimp needs to get a more conventional user interface style.
(Are multiple desktops set up by default in a typical Linux distribution these days?)
Does anyone understand these bizarre acronyms, WXGA, WSXGA and so on? If XGA is 1024x768, why is WXGA 1280x800?
Could you explain what you find objectionable about the name?
Would your engineering review board also have a problem with the name of the program? Or would they politely pretend not to notice and approve it with a straight face?