While it states "Of the 34 developers who responded, many of them are associated with projects like Apache and PostgreSQL that don't even use the GPL.", it neglects to mention how many. Of course, I can't be fucked actually reading the study (it is in PDF after all...).
Well, you can easily read the PDF file with free tools such as "evince" or other PDF readers (poppler backend). Anyway, Table B of the report (page 21) gives a breakdown of the developers by project. Here is a reformatted version of that table:
As described in the study, the third group ("Philosophers") include those who have a strong opinion about software licenses and "exactly half of Group Three" wants to use the GPL exclusively. I wonder how they take exactly half of 7 developers, but that's another issue. The "Pragmatists" and "Intellectuals" are those who prefer BSD or Apache licenses, or use a mix of licenses.
The study states clearly that they focused on the JLAMP stack and favored open source projects rather than focusing on free software projects. So instead of asking developers already using the GPL (GPLv2) if they were interested in the GPLv3, they asked developers using open source licenses (Apache, BSD, Sun CDDL and GPL) how they feel about the GPLv3. Of course, considering that some users of the other open source licenses are against the GPL (not just GPLv3, but any GPL), it is not surprising that the study concludes that some developers do not like the GPLv3. By they way, they also explain that they excluded the main developers and public figures of these projects as well as the casual contributors: instead, they went for what they consider to be the "key contributors".
So this whole study can be summarized like this: a non-representative sample of open source developers do not like the GPL or GPLv3. In other words, no news.
[...]These servers are usually well protected and have only one or just a couple of services exposed to the outside world (e.g., HTTP). But other servers may not be so well protected because they run experimental code for public testing or demonstrations, or simply because they run a larger number of services that may be vulnerable to zero-day exploits. If one of these "weaker" servers is compromised, I do not want it to be used as an intermediate step to launch an attack on other servers on the same network (behind the firewall).
I don't see how NAT helps this? If you've got the weaker services exposed, you've got them exposed. Period, end of story. However, if your firewall rules deny routing except to the secure services, you're as safe as you are with NAT.
What I tried to explain is that my firewall has to allow access to some servers that must be public and at the same time run code that may not be as secure as I would like it to be. Some of these services must be available for testing by partners or for public demonstrations. Public testbeds just have to be public, so I cannot restrict the range of source IP addresses.
Just because you have a DMZ doesn't mean that you have to turn off your firewall security. (Unless you have a really sucky firewall, that is.) You can still control the traffic going in and out of your network. For example, I might place server A into the DMZ. By default, all the ports of the machine are now open. However, that's a pretty dumb thing to do, so I immediately allow ONLY ports 80 and 443. The machine is now secure against external attacks from outside the network.
Limiting traffic to a web server to ports 80 and 443 is of course the first thing to do. But what if this web server runs some vulnerable CGI script, PHP script or Java servlet? What if this vulnerability allows an attacker to get shell access on that box? Suddenly, your whole DMZ is open to internal attacks that are remotely controlled from the outside. Your tight firewall setup becomes much less useful in that case.
This is exactly what I am trying to prevent by having multiple disjoint networks hidden behind the NAT+firewall box: the secure servers with important information go into one network, the servers containing experimental code that must have public access go into another network, etc. And I do not give too much information to the attacker about which server (or service) is in which network. So if someone ever manages to find a vulnerability in one of these servers, I do not want to make it too easy for them to find the private addresses of the other servers. This is just in case one of the other servers would be vulnerable to an attack from the local network. Of course this should not happen, but... better safe than sorry.
From my point of view, any additional effort that is required from the attackers is a good thing. If I force them to perform a noisy network scan to locate the other hosts on the internal network or to play ARP tricks, then they will be detected and isolated quickly. In the unlikely case that they would manage to attack other internal hosts anyway, then at least the damage would be limited to that specific network. Again, this is just a little addition to multiple layers of security. Every bit helps, so I like this NAT setup.
Does NAT really offer that much better security than a Dark-Net implementation?
They do not really address the same issues. First, this is not only NAT that provides the added security, but the fact that I use several disjoint networks behind the NAT box (think about DMZ + private network, except that I have more than one DMZ) and also the fact that there is no easy way for an attacker to guess the mapping between public IP addresses and private addresses in one of these subnets.
As I wrote in my previous comment, these networks contain several servers. Most of these servers are public and are intended to be accessible by almost anybody, so darknets are not really appropriate in this case.
The kind of scenario that I am trying to prevent or make more difficult by using NAT is the following: some of these servers have "interesting" contents on them and could be juicy targets for some attackers (no, I'm not talking about pr0n here but about some company internal information). These servers are usually well protected and have only one or just a couple of services exposed to the outside world (e.g., HTTP). But other servers may not be so well protected because they run experimental code for public testing or demonstrations, or simply because they run a larger number of services that may be vulnerable to zero-day exploits. If one of these "weaker" servers is compromised, I do not want it to be used as an intermediate step to launch an attack on other servers on the same network (behind the firewall). That's why I like NAT: it allows me to run the servers in different networks with different security policies and it also hides their private IP addresses. Both of these features add a small amount of security to the network. Maybe not much, but hopefully enough to prevent some attacks or delay them until IDS and counter-measures can be used effectively.
However, this "getting rid of connectivity issues due to no longer having to NAT" has NEVER been expected by anyone who knows even a bit about networking. Because we're not returning to an un-firewalled world.
There are also some features of NAT that I would like to keep even when using IPv6, the main one being the ability to hide the topology of my networks from the outside world. So in a way, I do want to have some connectivity issues.
For example, I currently maintain a firewall and NAT box that has a pool of several public IP addresses (Internet access) on one of its interfaces, and 3 additional network cards connected to different networks. Each of these 3 networks contains a number of machines and some servers for various protocols that are mapped to some of the public IP addresses. One of these private networks is rather open (with protocols such as NIS and NFS used by most hosts) and another one is rather secure (no host trusts any other host on the same subnet). I do not want to allow an external attacker to guess on which network a given server could be. Maybe this extra level of security through obscurity is not really necessary, but I want to maximize my chances in case of an attack (e.g., zero-day exploits). Some services that I mapped to an external IP address and port may go to a server on one network, while the same IP address but a different port may go to a different network. I do not want to reveal too much information about the topology of my networks, that's why I like NAT.
NAT causes some connectivity issues, but I consider some of them as features, not problems. Oh, and I know that some people claim that the network hiding brought by NAT is just some false security and that IPv6 with its much larger address space will also make it difficult to scan hosts on a network. But that's not the point here: hiding the topology is just one of the many layers of security that I use, and the larger address space of IPv6 will not prevent some information from being disclosed in routing table updates, etc.
I'm all for saving the environment, but I hate the fact the bulbs have a 'warm up' period, and whatever 'colour' bulb I get, it still throws a nasty fluro hue.
It depends a lot on which CFLs you buy. The cheapest ones are usually bad: they take ages to warm up and they don't emit a very nice light. Besides, they also tend to get worse after a couple of years (both in color and warm-up time).
I recently replaced one CFL that my wife hated because it took too long to warm up by a model from another brand. The difference was so big that I could not believe it: instead of taking 5 seconds to emit some decent light and more than 1 minute to reach its full brightness, the new one is fully warmed up in about 3 seconds. It also looks brighter although it is rated as having the same power. And on top of that, the tube has an interesting spiral design so it even looks nicer than the old one that had the common "folded" design. All that for a mere 20% increase in price.
If I had known that the difference between CFLs of different brands was so big, I would have avoided wasting my money on the cheapest ones.
Personally, I don't think many (if any) of us on/. are good judges of "easy to use" on computers. We're too involved in the technical end and know too much to judge what would be easy for someone without a lot of experience.
I agree. Also, it is difficult for anybody (including usability experts) to judge anything from a static screenshot, even if you can already have some hints by looking at the crowded menus or at the buttons available in the applications. It would be easier to comment on a movie (screencast). Or just by trying it or watching other users try it.
I have serious doubts about the usability of Ulteo when I look at the navigation on their web site. Just try accessing the items in the second-level menu bar and you should see the problem quickly: if you do not move your mouse exactly as the site designer expected, you will have a hard time selecting the item that you want. As an exercise, try selecting UlteOS/Screenshots or Docs/Documentation and see how frustrating it can be if you move your mouse a bit too far up or down. And this site is supposed to promote the "easiest Linux"?
There are more screenshots available on Go2Linux, describing the installation steps. It is not a surprise that it is almost identical to the current GTK+ Ubuntu installer, except for the Ulteo logo. Also, the initial boot screen has been changed to look a bit more similar to the SUSE boot splash (with the blue curves) but otherwise this is very similar to the current Ubuntu installation steps.
this screenshot looks a bit closer to the default Windows XP interface, so maybe he does really think that "easiest" means "easiest for experienced Windows users"
Indeed, this seems to be the case. I do not see anything in this distribution that would convince an average user to switch to it instead of using Ubuntu (or Kubuntu for those who prefer KDE).
So, FSF is really asking "should we let Novell and Microsoft off, and just apply this to future violators?" I don't think they'll do that.
The rationale for the changes explains that there are some concerns about other agreements that may have been signed before this date without malicious intent. It may be difficult for the parties involved in such agreements to re-negociate them, so that's one of the reason why this tentative cutoff date has been added to the draft.
For more details, see the last two paragraphs on pages 26-27 of the PDF file.
I only skimmed the draft, but it seems in this whole Novel-Microsoft thing, the part about web-apps has been lost.
I don't think that it has been lost. Look at section 13 Use with the Affero General Public License.. The Affero GPL (currently in version 1) is basically identical to the GNU GPLv2 with an added restriction in section 2d that states that if you run your application as a service, you must also distribute its source code if the original version of the program offered such an option. The new section 13 in the GNU GPLv3 addresses the Affero GPLv2, which is not released yet as far as I know. I expect that the Affero GPLv2 will be identical to the GNU GPLv3 with an added restriction for web apps, like the in their v1.
So if you are concerned about web apps, use the Affero GPL. It is designed for that and the GPLv3 will be compatible with it (and contain an explicit reference to it).
I don't know what project the parent post was refering to, but it is not only GIMP (with some interesting ideas) that got rejected.
Other projects that were not selected include interesting improvements to the desktop infrastructure, such as GStreamer (list of ideas) or Avahi (list of ideas).
Read the article again: if I understood it correctly, this mandatory cooling off period during which returns must be accepted would only apply to content that has interoperability problems. In other words, it is very likely that it would only apply to DRM-protected content.
So it would obviously not apply to Ogg Vorbis or MP3 music files because these are not tied to specific devices. On the other hand, this would apply to music or other digital content that does not let you exercise your usual consumer rights. And if the music can only be played on one specific device under some specific conditions, then the provider would have to accept returns. Presumably, the DRM protection would also require some sort of online validation to ensure that the DRM-protected content that you are trying to play has not been "returned".
Even if the DRM scheme does not require you to be online every time you attempt to play some protected content, there are ways to limit your ability to play "returned" content. For example, the database holding the keys for all your protected music could be versioned or could use some key chaining that makes it very difficult for you to re-insert a key that has been removed. So even if you restore both the music and the keys from backups, you would not be able to do much with them or you would not be able to play anything else that you downloaded later. Given that the DRM stuff is creeping increasingly deeper into some proprietary operating systems, you may even have to re-install your OS if you want to be able to play the "returned" files. Although this would be possible in theory, I doubt that you would enjoy the experience...
Among other nice things, you will find a whole section about "Restrictions.", including this:
3.1 Web Player Prohibited Devices. You may not Use any Web Player on any non-PC device or with any embedded or device version of any operating system. For the avoidance of doubt, and by example only, you may not use a Web Player on any (a) mobile devices, set top boxes (STB), handhelds, phones, web pads, tablets and Tablet PCs that are not running Windows XP Tablet PC Edition, game consoles, TVs, DVD players, media centers (excluding Windows XP Media Center Edition and its successors), electronic billboards or other digital signage, internet appliances or other internet-connected devices, PDAs, medical devices, ATMs, telematic devices, gaming machines, home automation systems, kiosks, remote control devices, or any other consumer electronics device, (b) operator-based mobile, cable, satellite, or television systems or (c) other closed system devices.
You are using Linux in your media center and thinking about using Flash? Nope, this is forbidden!
You are using Linux in your tablet PC or web pad (e.g., Nokia N770 or N800) and thinking about using Flash? Nope, this is forbidden!
You are using Linux in your PDA? Again, no!
...
Go on, complain! Oh, and just in case you have any doubt about what is the "Web Player", this is explained in the first paragraph of the EULA: "(collectively, the Flash, Shockwave and Authorware players, are the "Web Players")"
For that amount of cash they could probably launch a satellite. Now that's an idea -- how about trackers in the sky people can connect to by pointing an antenna to it?
Interesting idea. But you have to keep a few things in mind:
Do you plan to use the satellite as a normal tracker, as if it was a host on the Internet to which each user connects using HTTP, TCP and IP? If yes, then you have several problems:
HTTP is a request-reply protocol. TCP requires bi-directional handshakes and acknowledgements for all packets sent. This means that in order to receive data from the tracker, each user must be able to both send and receive data to/from the satellite.
A satellite antenna that can both send and receive data is very different from a typical TV antenna that is only designed for receiving data. You will need a rather large dish...
How do you intend to manage uploads anyway? Thousands of people trying to send data to the satellite at the same time? This is not going to work.
Using the HTTP protocol over TCP and IP is not the best way to use a satellite link with large round-trip delays.
You will have to connect your computer to the antenna, set up IP routing, etc. But this is probably a minor problem compared to the other ones.
Maybe you are smarter and you do not intend to use it as a normal tracker that requires a separate connection for each user. Instead, you use that satellite for what it does best: broadcasting data. So the satellite would constantly broadcast lots of tracker files and the users with the right equipment would simply receive them and pick the ones they are interested in. But there are still some problems with that solution:
Someone will still have to send the data to the satellite. Where will this antenna be located? How do you make sure that nobody can locate it and shut it down?
How will it be possible for the users to upload their torrents to the tracker? If this is done via the Internet, then it will be easy to follow the IP packets and shut down the server.
You can think about locating the server and/or the transmitting antenna in Sealand or some other island so that it is "safe" from other nations. But could you remind me... what was the point of having a satellite?
If the satellite broadcasts the same information to everybody, this means that each user has to wait quite a while before receiving the data he is interested in.
It is likely that TPB uses already much more bandwith than could be provided by a single satellite, even assuming an optimal utilization of the link. Launching a dozen satellites is going to be a bit expensive.
So I wish you good luck. If you are not interested in the satellite anymore, I could sell you some bridges or even some parts of the moon (also a satellite, but 100% natural).
Plenty of us block Google Analytics in our browsers. You are missing information.
I'll be sure to make a mental note that my stats are now 0.000125% inaccurate.
The percentage may not be so insignificant. For instance, the very popuplar
AdBlock Plus add-on for Firefox (among the recommended add-ons) includes several blacklists to which you can subscribe. Most of these blacklists include the site google-analytics.com and patterns for blocking scripts such as urchin.js.
I guess that a fair share of Firefox users have AdBlock Plus installed. It is up to you to decide if you care about these users or not.
Note that a good web statistics package that analyzes your own server logs should be able to tell you how many visitors block JavaScript, block cookies or use tools like AdBlock that selectively block some URLs. Good web statistics packages will provide this information while taking into account the effects of client caches, proxies and even multi-hosted proxies (resulting in multiple IP addresses for the same visitor). You cannot use Google Analytics to know how many visitors block Google Analytics.
So if you were using a good (local) web statistics package, you would be able to come up with a more realistic percentage than 0.000125%. Of course the actual number depends on the target audience for your site, whether they care about privacy issues, etc. Do not be surprised if you find out that the percentage is closer to 5% than to 0.000125%.
Well, call this pendantry if you want but yes, I would say that any piece of software that only runs on one specific architecture does not really support Linux.
To be more specific, I have three computers around me right now: one of them is an Athlon 64 which runs fine in 64bit mode without any old 32bit libs. The other one is a Sun SPARC workstation running Solaris right now but I can also run Linux on it. The third one is a N770. All of them run Linux. None of them supports 32bit x86 code. So it is not a theoretical problem when I say that some software does not really support Linux if it is tied to a single architecture: I simply cannot run it on my Linux systems.
Well, to be fair I should mention that I could also use my old laptop which does run 32bit Linux, but it would be inconvenient to use that slow laptop just so that I can install the Flash player and view some site that I am probably not very interested in. In any case, all the computers that I have bought recently or that I am planning to buy are either 64bit only or are using CPUs that are not x86-compatible.
This is not only for keeping the resource usage in the server down, but also for improving the overall performance of the whole network by avoiding congestions and packet losses. Note that the "whole network" includes not only the last mile (cable or DSL link between your home or office and your ISP), but also all routers at your ISP, in the backbone, etc.
Here is the general idea: if all clients use only one or two TCP connections and they use HTTP pipelining, then the traffic will be less bursty on these connections and TCP will be able to find the optimal transfer rate easily. As a result, the risk of congestion in the routers will be decreased and the overall performance of the network will be improved. The assumption of the HTTP/1.1 working group was that most of the traffic on the Internet would be TCP-friendly (using similar congestion avoidance algorithms). Although this is not really true for many peer-to-peer applications, many ISPs use traffic shaping and lower the priority of agressive P2P protocols compared to more "network-friendly" TCP-based applications.
Considering that the proprietary Flash player fails to run at all on my Athlon64 and Opteron sytstems, I would say that it does not support Linux. It just supports a subset of the 32-bits x86 Linux platforms, that's all.
I also have several ARM-based devices running Linux (Nokia N770, Linksys NSLU2) and it does not work on these either.
Sorry, but that was a bad slashvertisement for something that does not even support Linux correctly.
Using the same logic as described here, I could probably sue Google for some GPL violations.
Some web sites incorrectly send all their contents as text/plain or text/html, including binary files, images, etc. It looks like Google tries to automatically correct this, but is not always successful (this may depend on the amount of plain text contained in the binary file). Anyway, regardless of the reason why it happens, it seems to be possible to find a few binary files in the Google cache (not easy, but possible if you are lucky). And now comes the problem if one of these files is protected by the GPL: if Google distributes the binary file but not the sources, they would be violating the GPL.
Who is going to start a frivolous lawsuit against Google for GPL violations?
You are right. The article mentions that the rejection was issued by "Patent Office Hearing Officer Bruce Westerman". Thanks for the clarification. But that should not prevent you from supporting the FFII and FSF Europe...
It is not surprising that the court has rejected the patent. Most EU courts reject software patents or business method patents even though the EPO (European Patent Office) will grant them happily (contrary to the text and spirit of the patent convention). So that court did its job and rejected something that should never be patentable in Europe.
However, this could change in the future: the EPO is lobbying for establishing a "(European) Community Patent" process and for having a single European patent court, which would rule in case of patent disputes like this one. Given that the judges in that new court would probably come from the EPO, there is a high risk that they would grant the patent.
Although I have been taught to use dd/mm/yyyy, I tend to use the standard yyyy-mm-dd whenever possible, especially in discussions with people coming from other countries because this standard date format is less ambiguous.
See also the List of date and time formats used in various countries. You will see that many countries use dd/mm/yyyy, while USA, Canada and parts of Asia use mm-dd-yyyy and several countries from Eastern Europe have adopted the ISO standard yyyy-mm-dd.
This add-in is certainly a step in the right direction. But opening and saving files with this add-in is not as convenient as if the format was supported natively.
Here is an example of the problems that the users will face when using it (from the project home page):
Important note: The ODF file opened by the add-in is converted into Office OpenXML (Office 2007 new file format) and imported into Word as a read-only file. If you want to save it as ODF, you have to use the "Export as ODF" button and provide a new file name (that can be the same as the current file name).
Basically, this add-in will encourage you to convert your ODF documents to OpenXML, but if you really insist and if you really want to save (sorry, export) as ODF, then it will let you do that as well. You will just have to re-type or re-select the file name.
I thought the EU does not permit software patents, as on date. Any MS patents are null and void in the EU as it is.
Except that the European Patent Office (EPO) claims that they are not regulated by the EU. They say that they were formed before the EU (as we know it today) and therefore they only have to report to individual countries instead of reporting to the EU. And since these countries cannot agree on a common action against the EPO, then the EPO can keep on using their weird interpretation of the patent treaty: according to the EPO, software as such cannot be patented but it can be patented if that software is running on a computer.
Re:I'd just like to say,
on
Freedb.org Ending
·
· Score: 2, Informative
You can't download it as a 'dump', but he doesn't have to provide it as one.
Wrong. He does have to provide a dump, according to the GPL. The GPL requires you to provide the sources in the "prefered form" for making modifications to it. In this case, requiring to fetch the whole database query by query and having to convert the result back to text files would certainly not qualify as the prefered form.
And here is an excerpt from paragraph 3 of the GPL:
The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.
If distribution of executable or object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place counts as distribution of the source code, even though third parties are not compelled to copy the source along with the object code.
Slashdot Mirror
Well, you can easily read the PDF file with free tools such as "evince" or other PDF readers (poppler backend). Anyway, Table B of the report (page 21) gives a breakdown of the developers by project. Here is a reformatted version of that table:
And there is also a breakdown by "group":
As described in the study, the third group ("Philosophers") include those who have a strong opinion about software licenses and "exactly half of Group Three" wants to use the GPL exclusively. I wonder how they take exactly half of 7 developers, but that's another issue. The "Pragmatists" and "Intellectuals" are those who prefer BSD or Apache licenses, or use a mix of licenses.
The study states clearly that they focused on the JLAMP stack and favored open source projects rather than focusing on free software projects. So instead of asking developers already using the GPL (GPLv2) if they were interested in the GPLv3, they asked developers using open source licenses (Apache, BSD, Sun CDDL and GPL) how they feel about the GPLv3. Of course, considering that some users of the other open source licenses are against the GPL (not just GPLv3, but any GPL), it is not surprising that the study concludes that some developers do not like the GPLv3. By they way, they also explain that they excluded the main developers and public figures of these projects as well as the casual contributors: instead, they went for what they consider to be the "key contributors".
So this whole study can be summarized like this: a non-representative sample of open source developers do not like the GPL or GPLv3. In other words, no news.
What I tried to explain is that my firewall has to allow access to some servers that must be public and at the same time run code that may not be as secure as I would like it to be. Some of these services must be available for testing by partners or for public demonstrations. Public testbeds just have to be public, so I cannot restrict the range of source IP addresses.
Limiting traffic to a web server to ports 80 and 443 is of course the first thing to do. But what if this web server runs some vulnerable CGI script, PHP script or Java servlet? What if this vulnerability allows an attacker to get shell access on that box? Suddenly, your whole DMZ is open to internal attacks that are remotely controlled from the outside. Your tight firewall setup becomes much less useful in that case.
This is exactly what I am trying to prevent by having multiple disjoint networks hidden behind the NAT+firewall box: the secure servers with important information go into one network, the servers containing experimental code that must have public access go into another network, etc. And I do not give too much information to the attacker about which server (or service) is in which network. So if someone ever manages to find a vulnerability in one of these servers, I do not want to make it too easy for them to find the private addresses of the other servers. This is just in case one of the other servers would be vulnerable to an attack from the local network. Of course this should not happen, but... better safe than sorry.
From my point of view, any additional effort that is required from the attackers is a good thing. If I force them to perform a noisy network scan to locate the other hosts on the internal network or to play ARP tricks, then they will be detected and isolated quickly. In the unlikely case that they would manage to attack other internal hosts anyway, then at least the damage would be limited to that specific network. Again, this is just a little addition to multiple layers of security. Every bit helps, so I like this NAT setup.
They do not really address the same issues. First, this is not only NAT that provides the added security, but the fact that I use several disjoint networks behind the NAT box (think about DMZ + private network, except that I have more than one DMZ) and also the fact that there is no easy way for an attacker to guess the mapping between public IP addresses and private addresses in one of these subnets.
As I wrote in my previous comment, these networks contain several servers. Most of these servers are public and are intended to be accessible by almost anybody, so darknets are not really appropriate in this case.
The kind of scenario that I am trying to prevent or make more difficult by using NAT is the following: some of these servers have "interesting" contents on them and could be juicy targets for some attackers (no, I'm not talking about pr0n here but about some company internal information). These servers are usually well protected and have only one or just a couple of services exposed to the outside world (e.g., HTTP). But other servers may not be so well protected because they run experimental code for public testing or demonstrations, or simply because they run a larger number of services that may be vulnerable to zero-day exploits. If one of these "weaker" servers is compromised, I do not want it to be used as an intermediate step to launch an attack on other servers on the same network (behind the firewall). That's why I like NAT: it allows me to run the servers in different networks with different security policies and it also hides their private IP addresses. Both of these features add a small amount of security to the network. Maybe not much, but hopefully enough to prevent some attacks or delay them until IDS and counter-measures can be used effectively.
There are also some features of NAT that I would like to keep even when using IPv6, the main one being the ability to hide the topology of my networks from the outside world. So in a way, I do want to have some connectivity issues.
For example, I currently maintain a firewall and NAT box that has a pool of several public IP addresses (Internet access) on one of its interfaces, and 3 additional network cards connected to different networks. Each of these 3 networks contains a number of machines and some servers for various protocols that are mapped to some of the public IP addresses. One of these private networks is rather open (with protocols such as NIS and NFS used by most hosts) and another one is rather secure (no host trusts any other host on the same subnet). I do not want to allow an external attacker to guess on which network a given server could be. Maybe this extra level of security through obscurity is not really necessary, but I want to maximize my chances in case of an attack (e.g., zero-day exploits). Some services that I mapped to an external IP address and port may go to a server on one network, while the same IP address but a different port may go to a different network. I do not want to reveal too much information about the topology of my networks, that's why I like NAT.
NAT causes some connectivity issues, but I consider some of them as features, not problems. Oh, and I know that some people claim that the network hiding brought by NAT is just some false security and that IPv6 with its much larger address space will also make it difficult to scan hosts on a network. But that's not the point here: hiding the topology is just one of the many layers of security that I use, and the larger address space of IPv6 will not prevent some information from being disclosed in routing table updates, etc.
It depends a lot on which CFLs you buy. The cheapest ones are usually bad: they take ages to warm up and they don't emit a very nice light. Besides, they also tend to get worse after a couple of years (both in color and warm-up time).
I recently replaced one CFL that my wife hated because it took too long to warm up by a model from another brand. The difference was so big that I could not believe it: instead of taking 5 seconds to emit some decent light and more than 1 minute to reach its full brightness, the new one is fully warmed up in about 3 seconds. It also looks brighter although it is rated as having the same power. And on top of that, the tube has an interesting spiral design so it even looks nicer than the old one that had the common "folded" design. All that for a mere 20% increase in price.
If I had known that the difference between CFLs of different brands was so big, I would have avoided wasting my money on the cheapest ones.
I agree. Also, it is difficult for anybody (including usability experts) to judge anything from a static screenshot, even if you can already have some hints by looking at the crowded menus or at the buttons available in the applications. It would be easier to comment on a movie (screencast). Or just by trying it or watching other users try it.
I have serious doubts about the usability of Ulteo when I look at the navigation on their web site. Just try accessing the items in the second-level menu bar and you should see the problem quickly: if you do not move your mouse exactly as the site designer expected, you will have a hard time selecting the item that you want. As an exercise, try selecting UlteOS/Screenshots or Docs/Documentation and see how frustrating it can be if you move your mouse a bit too far up or down. And this site is supposed to promote the "easiest Linux"?
There are more screenshots available on Go2Linux, describing the installation steps. It is not a surprise that it is almost identical to the current GTK+ Ubuntu installer, except for the Ulteo logo. Also, the initial boot screen has been changed to look a bit more similar to the SUSE boot splash (with the blue curves) but otherwise this is very similar to the current Ubuntu installation steps.
Indeed, this seems to be the case. I do not see anything in this distribution that would convince an average user to switch to it instead of using Ubuntu (or Kubuntu for those who prefer KDE).
The rationale for the changes explains that there are some concerns about other agreements that may have been signed before this date without malicious intent. It may be difficult for the parties involved in such agreements to re-negociate them, so that's one of the reason why this tentative cutoff date has been added to the draft.
For more details, see the last two paragraphs on pages 26-27 of the PDF file.
I don't think that it has been lost. Look at section 13 Use with the Affero General Public License.. The Affero GPL (currently in version 1) is basically identical to the GNU GPLv2 with an added restriction in section 2d that states that if you run your application as a service, you must also distribute its source code if the original version of the program offered such an option. The new section 13 in the GNU GPLv3 addresses the Affero GPLv2, which is not released yet as far as I know. I expect that the Affero GPLv2 will be identical to the GNU GPLv3 with an added restriction for web apps, like the in their v1.
So if you are concerned about web apps, use the Affero GPL. It is designed for that and the GPLv3 will be compatible with it (and contain an explicit reference to it).
I don't know what project the parent post was refering to, but it is not only GIMP (with some interesting ideas) that got rejected.
Other projects that were not selected include interesting improvements to the desktop infrastructure, such as GStreamer (list of ideas) or Avahi (list of ideas).
...or listing domain names as science.slashdot.org instead of the logical order org.slashdot.science.
Read the article again: if I understood it correctly, this mandatory cooling off period during which returns must be accepted would only apply to content that has interoperability problems. In other words, it is very likely that it would only apply to DRM-protected content.
So it would obviously not apply to Ogg Vorbis or MP3 music files because these are not tied to specific devices. On the other hand, this would apply to music or other digital content that does not let you exercise your usual consumer rights. And if the music can only be played on one specific device under some specific conditions, then the provider would have to accept returns. Presumably, the DRM protection would also require some sort of online validation to ensure that the DRM-protected content that you are trying to play has not been "returned".
Even if the DRM scheme does not require you to be online every time you attempt to play some protected content, there are ways to limit your ability to play "returned" content. For example, the database holding the keys for all your protected music could be versioned or could use some key chaining that makes it very difficult for you to re-insert a key that has been removed. So even if you restore both the music and the keys from backups, you would not be able to do much with them or you would not be able to play anything else that you downloaded later. Given that the DRM stuff is creeping increasingly deeper into some proprietary operating systems, you may even have to re-install your OS if you want to be able to play the "returned" files. Although this would be possible in theory, I doubt that you would enjoy the experience...
Anyway, don't forget that DRM is defective by design.
Rejoice, there is a restrictive EULA attached to the flash player! You can find it here: http://www.adobe.com/products/eulas/players/flash/ .
Among other nice things, you will find a whole section about "Restrictions.", including this:
Go on, complain! Oh, and just in case you have any doubt about what is the "Web Player", this is explained in the first paragraph of the EULA: "(collectively, the Flash, Shockwave and Authorware players, are the "Web Players")"
Interesting idea. But you have to keep a few things in mind:
So I wish you good luck. If you are not interested in the satellite anymore, I could sell you some bridges or even some parts of the moon (also a satellite, but 100% natural).
The percentage may not be so insignificant. For instance, the very popuplar AdBlock Plus add-on for Firefox (among the recommended add-ons) includes several blacklists to which you can subscribe. Most of these blacklists include the site google-analytics.com and patterns for blocking scripts such as urchin.js.
I guess that a fair share of Firefox users have AdBlock Plus installed. It is up to you to decide if you care about these users or not.
Note that a good web statistics package that analyzes your own server logs should be able to tell you how many visitors block JavaScript, block cookies or use tools like AdBlock that selectively block some URLs. Good web statistics packages will provide this information while taking into account the effects of client caches, proxies and even multi-hosted proxies (resulting in multiple IP addresses for the same visitor). You cannot use Google Analytics to know how many visitors block Google Analytics.
So if you were using a good (local) web statistics package, you would be able to come up with a more realistic percentage than 0.000125%. Of course the actual number depends on the target audience for your site, whether they care about privacy issues, etc. Do not be surprised if you find out that the percentage is closer to 5% than to 0.000125%.
Well, call this pendantry if you want but yes, I would say that any piece of software that only runs on one specific architecture does not really support Linux.
To be more specific, I have three computers around me right now: one of them is an Athlon 64 which runs fine in 64bit mode without any old 32bit libs. The other one is a Sun SPARC workstation running Solaris right now but I can also run Linux on it. The third one is a N770. All of them run Linux. None of them supports 32bit x86 code. So it is not a theoretical problem when I say that some software does not really support Linux if it is tied to a single architecture: I simply cannot run it on my Linux systems.
Well, to be fair I should mention that I could also use my old laptop which does run 32bit Linux, but it would be inconvenient to use that slow laptop just so that I can install the Flash player and view some site that I am probably not very interested in. In any case, all the computers that I have bought recently or that I am planning to buy are either 64bit only or are using CPUs that are not x86-compatible.
This is not only for keeping the resource usage in the server down, but also for improving the overall performance of the whole network by avoiding congestions and packet losses. Note that the "whole network" includes not only the last mile (cable or DSL link between your home or office and your ISP), but also all routers at your ISP, in the backbone, etc.
Here is the general idea: if all clients use only one or two TCP connections and they use HTTP pipelining, then the traffic will be less bursty on these connections and TCP will be able to find the optimal transfer rate easily. As a result, the risk of congestion in the routers will be decreased and the overall performance of the network will be improved. The assumption of the HTTP/1.1 working group was that most of the traffic on the Internet would be TCP-friendly (using similar congestion avoidance algorithms). Although this is not really true for many peer-to-peer applications, many ISPs use traffic shaping and lower the priority of agressive P2P protocols compared to more "network-friendly" TCP-based applications.
Considering that the proprietary Flash player fails to run at all on my Athlon64 and Opteron sytstems, I would say that it does not support Linux. It just supports a subset of the 32-bits x86 Linux platforms, that's all.
I also have several ARM-based devices running Linux (Nokia N770, Linksys NSLU2) and it does not work on these either.
Sorry, but that was a bad slashvertisement for something that does not even support Linux correctly.
Using the same logic as described here, I could probably sue Google for some GPL violations.
Some web sites incorrectly send all their contents as text/plain or text/html, including binary files, images, etc. It looks like Google tries to automatically correct this, but is not always successful (this may depend on the amount of plain text contained in the binary file). Anyway, regardless of the reason why it happens, it seems to be possible to find a few binary files in the Google cache (not easy, but possible if you are lucky). And now comes the problem if one of these files is protected by the GPL: if Google distributes the binary file but not the sources, they would be violating the GPL.
Who is going to start a frivolous lawsuit against Google for GPL violations?
You are right. The article mentions that the rejection was issued by "Patent Office Hearing Officer Bruce Westerman". Thanks for the clarification. But that should not prevent you from supporting the FFII and FSF Europe...
It is not surprising that the court has rejected the patent. Most EU courts reject software patents or business method patents even though the EPO (European Patent Office) will grant them happily (contrary to the text and spirit of the patent convention). So that court did its job and rejected something that should never be patentable in Europe.
However, this could change in the future: the EPO is lobbying for establishing a "(European) Community Patent" process and for having a single European patent court, which would rule in case of patent disputes like this one. Given that the judges in that new court would probably come from the EPO, there is a high risk that they would grant the patent.
Time to support the FFII and the FSF Europe...
Description of the international standard date and time notation (ISO 8601):
http://www.cl.cam.ac.uk/~mgk25/iso-time.html
Although I have been taught to use dd/mm/yyyy, I tend to use the standard yyyy-mm-dd whenever possible, especially in discussions with people coming from other countries because this standard date format is less ambiguous.
See also the List of date and time formats used in various countries. You will see that many countries use dd/mm/yyyy, while USA, Canada and parts of Asia use mm-dd-yyyy and several countries from Eastern Europe have adopted the ISO standard yyyy-mm-dd.
This add-in is certainly a step in the right direction. But opening and saving files with this add-in is not as convenient as if the format was supported natively.
Here is an example of the problems that the users will face when using it (from the project home page):
Basically, this add-in will encourage you to convert your ODF documents to OpenXML, but if you really insist and if you really want to save (sorry, export) as ODF, then it will let you do that as well. You will just have to re-type or re-select the file name.
Except that the European Patent Office (EPO) claims that they are not regulated by the EU. They say that they were formed before the EU (as we know it today) and therefore they only have to report to individual countries instead of reporting to the EU. And since these countries cannot agree on a common action against the EPO, then the EPO can keep on using their weird interpretation of the patent treaty: according to the EPO, software as such cannot be patented but it can be patented if that software is running on a computer.
Wrong. He does have to provide a dump, according to the GPL. The GPL requires you to provide the sources in the "prefered form" for making modifications to it. In this case, requiring to fetch the whole database query by query and having to convert the result back to text files would certainly not qualify as the prefered form.
For more information, see this section of the GPL FAQ: Can I use the GPL for something other than software?.
And here is an excerpt from paragraph 3 of the GPL:
Note that the GPL requires distribution from the "same place", so pointing to the original freedb mirrors would not be sufficient (and would not ensure that the data remains the same anyway). This is clarified in this section of the GPL FAQ: Can I put the binaries on my Internet server and put the source on a different Internet site?