The practical effect is the same - the user is denied access to the site via an attack on the name resolution protocol. If the registrar is subpoenaed, it doesn't matter if they set the domain to resolve to a takedown notice or a NXDOMAIN result - the practical result is that anyone who doesn't have the site's IP address written down will be unable to access it.
Both hosting and registering the domain outside of the US will provide some resilience if you are doing something they don't like, though they can still block resolution for everyone who isn't using DNSSEC.
There's a level in risk in life that most people are willing to accept in order to live life the way they want. Just because some people are happy wrapped up on cotton wool and kept away from any possible harm doesn't mean that sort of life should be inflicted on the entire population.
Society as a whole is what decides where on the freedom-safety spectrum it lies. Given that we already have speed limits, it's not unlikely that limits on manual driving may be put in place eventually.
This is Australia. We don't have constitutional rights - our constitution merely codifies the relationship between the states, territories, federal government and the commonwealth.
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.
The wording of the GPL is quite clear - it only requires the Makefiles to be included, and even adds an exception for the compiler when included with the OS as a runtime dependency. It doesn't say anything about the requirement to include the compiler.
Keep in mind that when the GPL was first written, GCC was only 2 years old, and proprietary compilers were unavoidable in many areas. Even today, proprietary compilers are still unavoidable for certain applications. e.g. FPGAs. To require the publishers of open source programs to cover the cost of licensing the compiler for all their users would have been insane, and significantly limited the spread of open source software.
The obvious intent of the GPL is for you to get a code in a way that allows you to work with it and get results.
The intention of the GPLv2, to paraphrase Linus Torvalds, is that in exchange for the ability to modify the software to suit yourself, the changes you make can be merged back into the upstream. The GPLv3 places a greater focus on the ability of the user to generate a useful executable, but the v2 was chosen (possibly intentionally) for this instead. Whatever your opinion on v3, their choice of v2 speaks for itself.
The solution is the same as for the razor blade model - stick with products which accept generic consumables. e.g. coffee grinders that take beans, or double edged razors (all the blades have the same shape and are intercompatible). The difference in cost is usually about an order of magnitude. e.g. DE razor blades are ~30c each.
Wrong on both accounts. Both ALSA and Pulseaudio are available on pretty much every Linux distro. Pulseaudio is generally regarded as the standard these days, but you can target ALSA if you really care about supporting the minority of Arch and Gentoo users without Pulseaudio.
Both of these are free (both libre and gratis), with the GPL family of licenses being the FSF's gold standard.
As for your claim about the LGPL, I am not aware of any evidence that supports your interpretation. In fact, the existence of Linux ports for numerous AAA games indicates that many large companies do not consider the risk significant. Furthermore, courts are generally quite conservative, and prefer to avoid disrupting existing arrangements where possible. The idea that the LGPL was explicitly designed to enable the use of libraries by non-GPL'd programs, combined with the number of companies relying on it, means that regardless of ambiguities in the actual wording, the chances of the LGPL being turned into a regular GPL are slim to none.
Take a look at appdb to see how many of the games you play under Windows (which don't have explicit Linux support) will actually work via WINE. You might be surprised - it's not all of them, but these days they work more often than not.
Keep in mind that Google Inbox is really just a fancy email client, albeit one implemented in the browser. I don't really care if they experiment with it, because I've always used a regular IMAP client instead, and I don't see them removing that option any time soon.
Open source hardware isn't viable, though, at least not in its own right. You need to make profit somewhere, and it's usually one of software, hardware, or support. The SoC manufacturers sell hardware - if they just gave it away by open sourcing it, they'd lose their biggest source of revenue. Pretty much all the open source hardware in existence is either bought by a small segment of zealots (e.g. any of the attempts at a completely FOSS tablet), or is sold as a loss leader (e.g. Sparkfun open sources the designs for their breakout boards, because they also sells the parts for them).
The premise of the article is just weird - an article about programming languages with single letter names makes about as much sense as an article about operating systems with blue logos. That D is compared to C instead of C++ further demonstrates the author's cluelessness. (Many D programmers regard D as an improved, non-backward compatible version of C++.)
You're conflating aspect ratio and resolution. If the 16:9 monitor is 1600x900, then a 4:3 with equivalent vertical resolution would be 1600x1200.
I use 2x 1280x1024 on my desktop, and 1x 1920x1080 on my laptop. I agree that 16:9 is almost like having dual screens, but it's just not as good. If you're going to use dual screens anyway, then it makes more sense to go with 4:3 and have one window per screen.
A semi-related issue is that Linux HiDPI support isn't quite there yet (KDE5 and Wayland aren't mainstream yet), so there's little reason to upgrade until then.
The only reason, AFAIK, is because it's of strategic advantage to the systemd project, and by extension, Red Hat. (If someone has evidence to the contrary, I'd love to hear it.)
I've used systemd since mid-2013, and since then I've acquired a fair few reasons to dislike it, but it's the management of the project that bothers me more than any technical aspect. The systemd modules all seem to depend on the process manager and journal. The process manager requires that systemd also acts as init,* and user instances require a root instance. None of these dependencies need to exist - even the journalling library could be replaced by a shim that just forwards everything to stderr. Traditionally they would have been separate projects and such dependencies wouldn't exist.
* Systemd is a much better process manager than SysVinit, but there was never any reason to prevent the user from choosing another init.
How is that not fair? As a solar panel user, you’re no different from any other generator company.
The problem is that they aren't under the same contract as another generation company; they're just given a flat rate. The generators are subject to dynamic pricing that varies by the hour, and those prices take power factors into account. In certain regions, at certain times, the price of electricity can even go negative if the mismatch between demand and supply gets too great (this is typically associated with large wind/solar installations, which are inherently unpredictable).
Of course, the reason they're given a flat rate in the first place is because dynamic pricing would be too complex and unpredictable for the average consumer, even though it would result in a more efficient system. Ultimately I suspect they'll just offer a mean price that compensates for this, with dynamic pricing as a possible alternative.
When you flick a pencil in the absence of gravity, you impart both translational and rotational momentum to it, both of which are conserved. Flick it in the center, and it will fly forward, and you backward. Flick it at an extreme*, and while it spins forward, you will spin backward. Flick it anywhere in between, and you'll get some combination of those.
* I doubt you can flick it without imparting any translational momentum in practice, because your finger is not infinitely thin.
Rather than choosing specific resources, you might find it more helpful to look for comprehensive collections. e.g.
Wikipedia - because if anything comes close to being the sum of human knowledge, this is probably it. [10 GB]
A complete mirror of the packages available for your distribution of choice (I suggest Debian stable [60 GB], though Gentoo [160 GB] might be worth considering if you want more flexibility and don't mind the compile times.). This will allow you to experiment with a language/program/etc. even if you don't have it installed when you leave.
Project Gutenburg [8 GB]
In addition to these, any of the standard comp sci books (e.g. the Art of Programming) will give you something to mull over. Learn a functional language if you haven't used one before (I suggest Haskell).
I think D is spectacular and I'm sorry it hasn't seen more adoption.
I'll second that. It seems to be purely a matter of corporate backing - Go and Rust have received a significant amount of funding from Google and Mozilla, but D hasn't gotten much more than a few conferences sponsored by Facebook.
If it's not supported on WINE, then it's completely random whether or not the WINE demographic will buy it, and MBA-types tend to prefer predictability. Furthermore, if it does work well under WINE, that implies the effort needed to port it is minimal - simply bundling WINE (or a similar translation layer) with it would be sufficient. In my experience, there isn't much support available for games anyway, unless it's a game-breaking bug that affects a large number of people.
Then you've got the people like me, who dual boot all of their systems (so we're already customers, anyhow).
Then, over in a tiny little corner, you've got the Linux users with a gamer-grade PC, no OS but Linux, no console, and pockets lined with cash earmarked for games if only publishers'd release them on their OS of choice!
I think you've mis-characterised the demographic. I single boot Linux (because dual booting is a pain), but I still buy Windows games via Steam that work via WINE. If a game isn't playable under WINE (which is increasingly uncommon these days) and doesn't have a native Linux port, I simply don't buy it.
Valve knows exactly how many people are doing this, and my guess is its a small but non-trivial number.
That's actually a rather interesting question. As with many things in law, it's the result of historical precedent (aka legacy code).
Historically, computer programs were not effectively protected by copyrights because computer programs were not viewed as a fixed, tangible object: object code was viewed as a utilitarian good produced from source code rather than as a creative work. Due to lack of precedent, this outcome was reached while deciding how to handle copyright of computer programs. The Copyright Office attempted to classify computer programs by drawing an analogy: the blueprints of a bridge and the resulting bridge compared to the source code of a program and the resulting executable object code. This analogy caused the Copyright Office to issue copyright certificates under its "Rule of Doubt".
So basically, software is copyrightable because blueprints are copyrightable, and later legislation was passed to codify this (and legislation doesn't need to be well reasoned or justified, merely politically tenable). This then leads to the question of why blueprints are copyrightable.
"Consistent with other provisions of the Copyright Act and copyright regulations, . . . protection [of architectural works] does not extend to standard features, such as common windows, doors, and other stable building components."[27] As architect Michael Graves explained, copyright protection covers only the "poetic language" of an architectural work, which includes those parts of the design that are "responsive to issues external to the building, and incorporates the three-dimensional expression of the myths and rituals of society". It does not cover "internal language", which includes those parts of the design that are "intrinsic to the building in its most basic form – determined by its pragmatic, constructional, and technical requirements."[33] Thus, for example, individual elements that are driven by function are not copyrightable, including the presence of doors and windows or those elements required by building codes. Accordingly, architectural designs must be analyzed to determine the scope of their functionality.
So basically, architecture is a combination of art and functional aspects, and only the artistic elements were ever intended to be covered. The problem is that because the judiciary (in most cases) don't understand programming, they are unable to distinguish between them adequately.
IMO, computer programs in general should never have been considered to have an artistic element (and I say that as someone who appreciates beautiful code). A building may be said to have artistic elements because it serves two purposes: a functional one (to provide shelter), and an artistic one (to look good). With the exception of examples in textbooks (which are copyrightable independently of this), code is almost never written to look good, merely to serve a functional purpose. While it may be beautiful, that it not it's primary purpose. They should have been regarded as purely mechanical, and covered by patent law instead.* At this point in time though, it is likely impossible to fix that flaw, given how disruptive it would be.
* I think that software patents should exist, but not in their current form. While computer programs are mathemathical in nature, so are many other patentable creations. For example, the negative feedback amplifier was well-deserving of a patent (given how revolutionary it was at the time), but each of the components in that circuit could be well-defined mathematically. If the requirements for a patent were enforced properly (i.e. novelty/obviousness and the limitation to an implementation, as opposed to a goal/idea), then they would actually be useful.
Slashdot Mirror
The practical effect is the same - the user is denied access to the site via an attack on the name resolution protocol. If the registrar is subpoenaed, it doesn't matter if they set the domain to resolve to a takedown notice or a NXDOMAIN result - the practical result is that anyone who doesn't have the site's IP address written down will be unable to access it.
Both hosting and registering the domain outside of the US will provide some resilience if you are doing something they don't like, though they can still block resolution for everyone who isn't using DNSSEC.
There's a level in risk in life that most people are willing to accept in order to live life the way they want. Just because some people are happy wrapped up on cotton wool and kept away from any possible harm doesn't mean that sort of life should be inflicted on the entire population.
Society as a whole is what decides where on the freedom-safety spectrum it lies. Given that we already have speed limits, it's not unlikely that limits on manual driving may be put in place eventually.
This is Australia. We don't have constitutional rights - our constitution merely codifies the relationship between the states, territories, federal government and the commonwealth.
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.
The wording of the GPL is quite clear - it only requires the Makefiles to be included, and even adds an exception for the compiler when included with the OS as a runtime dependency. It doesn't say anything about the requirement to include the compiler.
Keep in mind that when the GPL was first written, GCC was only 2 years old, and proprietary compilers were unavoidable in many areas. Even today, proprietary compilers are still unavoidable for certain applications. e.g. FPGAs. To require the publishers of open source programs to cover the cost of licensing the compiler for all their users would have been insane, and significantly limited the spread of open source software.
The obvious intent of the GPL is for you to get a code in a way that allows you to work with it and get results.
The intention of the GPLv2, to paraphrase Linus Torvalds, is that in exchange for the ability to modify the software to suit yourself, the changes you make can be merged back into the upstream. The GPLv3 places a greater focus on the ability of the user to generate a useful executable, but the v2 was chosen (possibly intentionally) for this instead. Whatever your opinion on v3, their choice of v2 speaks for itself.
The solution is the same as for the razor blade model - stick with products which accept generic consumables. e.g. coffee grinders that take beans, or double edged razors (all the blades have the same shape and are intercompatible). The difference in cost is usually about an order of magnitude. e.g. DE razor blades are ~30c each.
Like this
Does it improve the picture now that you have twisted cables?
Make sure you rotate by -360 degress in the Southern Hemisphere or the electrons will get tangled.
Do that and they'll disappear into a singularity (mathematical, not physical). What you really need is to use quaternions, like -ijk.
This feels like a troll, but I'll respond anyway.
There is no standard and free audio API on Linux.
Wrong on both accounts. Both ALSA and Pulseaudio are available on pretty much every Linux distro. Pulseaudio is generally regarded as the standard these days, but you can target ALSA if you really care about supporting the minority of Arch and Gentoo users without Pulseaudio.
Both of these are free (both libre and gratis), with the GPL family of licenses being the FSF's gold standard.
As for your claim about the LGPL, I am not aware of any evidence that supports your interpretation. In fact, the existence of Linux ports for numerous AAA games indicates that many large companies do not consider the risk significant. Furthermore, courts are generally quite conservative, and prefer to avoid disrupting existing arrangements where possible. The idea that the LGPL was explicitly designed to enable the use of libraries by non-GPL'd programs, combined with the number of companies relying on it, means that regardless of ambiguities in the actual wording, the chances of the LGPL being turned into a regular GPL are slim to none.
Take a look at appdb to see how many of the games you play under Windows (which don't have explicit Linux support) will actually work via WINE. You might be surprised - it's not all of them, but these days they work more often than not.
"I knew slashdot was right wing these days"
LOL really?! The leftist propaganda keeps me away from this site most of the time.
Slashdot is US-centric, which means it's right-wing from an international perspective. Right and Left aren't absolute terms.
Keep in mind that Google Inbox is really just a fancy email client, albeit one implemented in the browser. I don't really care if they experiment with it, because I've always used a regular IMAP client instead, and I don't see them removing that option any time soon.
Open source hardware isn't viable, though, at least not in its own right. You need to make profit somewhere, and it's usually one of software, hardware, or support. The SoC manufacturers sell hardware - if they just gave it away by open sourcing it, they'd lose their biggest source of revenue. Pretty much all the open source hardware in existence is either bought by a small segment of zealots (e.g. any of the attempts at a completely FOSS tablet), or is sold as a loss leader (e.g. Sparkfun open sources the designs for their breakout boards, because they also sells the parts for them).
there are not enough tools to quickly provide them all of my os/cpu/motherboard/hd/videocard information (yes sometimes this is needed for bugs)
$ sudo lshw > hardware_info
The premise of the article is just weird - an article about programming languages with single letter names makes about as much sense as an article about operating systems with blue logos. That D is compared to C instead of C++ further demonstrates the author's cluelessness. (Many D programmers regard D as an improved, non-backward compatible version of C++.)
While I agree with your point, it is worth noting that there have been several studies over the last half-century disproving the diet-heart hypothesis.
You're conflating aspect ratio and resolution. If the 16:9 monitor is 1600x900, then a 4:3 with equivalent vertical resolution would be 1600x1200.
I use 2x 1280x1024 on my desktop, and 1x 1920x1080 on my laptop. I agree that 16:9 is almost like having dual screens, but it's just not as good. If you're going to use dual screens anyway, then it makes more sense to go with 4:3 and have one window per screen.
A semi-related issue is that Linux HiDPI support isn't quite there yet (KDE5 and Wayland aren't mainstream yet), so there's little reason to upgrade until then.
The only reason, AFAIK, is because it's of strategic advantage to the systemd project, and by extension, Red Hat. (If someone has evidence to the contrary, I'd love to hear it.)
I've used systemd since mid-2013, and since then I've acquired a fair few reasons to dislike it, but it's the management of the project that bothers me more than any technical aspect. The systemd modules all seem to depend on the process manager and journal. The process manager requires that systemd also acts as init,* and user instances require a root instance. None of these dependencies need to exist - even the journalling library could be replaced by a shim that just forwards everything to stderr. Traditionally they would have been separate projects and such dependencies wouldn't exist.
* Systemd is a much better process manager than SysVinit, but there was never any reason to prevent the user from choosing another init.
How is that not fair? As a solar panel user, you’re no different from any other generator company.
The problem is that they aren't under the same contract as another generation company; they're just given a flat rate. The generators are subject to dynamic pricing that varies by the hour, and those prices take power factors into account. In certain regions, at certain times, the price of electricity can even go negative if the mismatch between demand and supply gets too great (this is typically associated with large wind/solar installations, which are inherently unpredictable).
Of course, the reason they're given a flat rate in the first place is because dynamic pricing would be too complex and unpredictable for the average consumer, even though it would result in a more efficient system. Ultimately I suspect they'll just offer a mean price that compensates for this, with dynamic pricing as a possible alternative.
Generalized Bechdel test: how many movies have conversations between minor characters that are about something other than the main character?
When you flick a pencil in the absence of gravity, you impart both translational and rotational momentum to it, both of which are conserved. Flick it in the center, and it will fly forward, and you backward. Flick it at an extreme*, and while it spins forward, you will spin backward. Flick it anywhere in between, and you'll get some combination of those.
* I doubt you can flick it without imparting any translational momentum in practice, because your finger is not infinitely thin.
Rather than choosing specific resources, you might find it more helpful to look for comprehensive collections. e.g.
In addition to these, any of the standard comp sci books (e.g. the Art of Programming) will give you something to mull over. Learn a functional language if you haven't used one before (I suggest Haskell).
I think D is spectacular and I'm sorry it hasn't seen more adoption.
I'll second that. It seems to be purely a matter of corporate backing - Go and Rust have received a significant amount of funding from Google and Mozilla, but D hasn't gotten much more than a few conferences sponsored by Facebook.
If it's not supported on WINE, then it's completely random whether or not the WINE demographic will buy it, and MBA-types tend to prefer predictability.
Furthermore, if it does work well under WINE, that implies the effort needed to port it is minimal - simply bundling WINE (or a similar translation layer) with it would be sufficient. In my experience, there isn't much support available for games anyway, unless it's a game-breaking bug that affects a large number of people.
Then you've got the people like me, who dual boot all of their systems (so we're already customers, anyhow).
Then, over in a tiny little corner, you've got the Linux users with a gamer-grade PC, no OS but Linux, no console, and pockets lined with cash earmarked for games if only publishers'd release them on their OS of choice!
I think you've mis-characterised the demographic. I single boot Linux (because dual booting is a pain), but I still buy Windows games via Steam that work via WINE. If a game isn't playable under WINE (which is increasingly uncommon these days) and doesn't have a native Linux port, I simply don't buy it.
Valve knows exactly how many people are doing this, and my guess is its a small but non-trivial number.
That's actually a rather interesting question.
As with many things in law, it's the result of historical precedent (aka legacy code).
Historically, computer programs were not effectively protected by copyrights because computer programs were not viewed as a fixed, tangible object: object code was viewed as a utilitarian good produced from source code rather than as a creative work. Due to lack of precedent, this outcome was reached while deciding how to handle copyright of computer programs. The Copyright Office attempted to classify computer programs by drawing an analogy: the blueprints of a bridge and the resulting bridge compared to the source code of a program and the resulting executable object code. This analogy caused the Copyright Office to issue copyright certificates under its "Rule of Doubt".
Source: http://en.wikipedia.org/wiki/S...
So basically, software is copyrightable because blueprints are copyrightable, and later legislation was passed to codify this (and legislation doesn't need to be well reasoned or justified, merely politically tenable).
This then leads to the question of why blueprints are copyrightable.
"Consistent with other provisions of the Copyright Act and copyright regulations, . . . protection [of architectural works] does not extend to standard features, such as common windows, doors, and other stable building components."[27] As architect Michael Graves explained, copyright protection covers only the "poetic language" of an architectural work, which includes those parts of the design that are "responsive to issues external to the building, and incorporates the three-dimensional expression of the myths and rituals of society". It does not cover "internal language", which includes those parts of the design that are "intrinsic to the building in its most basic form – determined by its pragmatic, constructional, and technical requirements."[33] Thus, for example, individual elements that are driven by function are not copyrightable, including the presence of doors and windows or those elements required by building codes. Accordingly, architectural designs must be analyzed to determine the scope of their functionality.
Source: http://en.wikipedia.org/wiki/C...
So basically, architecture is a combination of art and functional aspects, and only the artistic elements were ever intended to be covered. The problem is that because the judiciary (in most cases) don't understand programming, they are unable to distinguish between them adequately.
IMO, computer programs in general should never have been considered to have an artistic element (and I say that as someone who appreciates beautiful code). A building may be said to have artistic elements because it serves two purposes: a functional one (to provide shelter), and an artistic one (to look good). With the exception of examples in textbooks (which are copyrightable independently of this), code is almost never written to look good, merely to serve a functional purpose. While it may be beautiful, that it not it's primary purpose. They should have been regarded as purely mechanical, and covered by patent law instead.* At this point in time though, it is likely impossible to fix that flaw, given how disruptive it would be.
* I think that software patents should exist, but not in their current form. While computer programs are mathemathical in nature, so are many other patentable creations. For example, the negative feedback amplifier was well-deserving of a patent (given how revolutionary it was at the time), but each of the components in that circuit could be well-defined mathematically. If the requirements for a patent were enforced properly (i.e. novelty/obviousness and the limitation to an implementation, as opposed to a goal/idea), then they would actually be useful.