You don't have to use any of the new stuff, though. The "others" you mention add to what we had before. They don't replace it. You are free not to use e-commerce sites, or to stream music or movies, or to host your stuff in "the cloud". No-one is stopping you from restricting your browsing activity to personal or otherwise freely available websites, just like what you could access before. You are perfectly entitled to run a browser with JS disabled, ads blocked, and no plugins (including anything related to EME) if you don't want to use sites that rely on such technologies or feel that they compromise your security or privacy in unacceptable ways.
However, none of us is entitled say to everyone else, including the millions if not billions of people who find these new alternatives useful, that they can't have what they want because it's different to what we want. Also, none of us is entitled to tell those providing content that they must provide it in a certain format that we find convenient.
This mostly seems to be a combination of paranoia and slippery slope fallacies, and for someone who wants to see "proof and lots of it", your own argument is remarkably devoid of any supporting evidence.
I suggest to you that the existence of services like Netflix is beneficial to a great many people, who now get to enjoy more content at lower cost than they otherwise would have. I also suggest that services like Netflix would be much less practical without DRM, since obviously anyone could just sign up for whatever the minimum period is these days, download huge amounts of unprotected content to keep them going for a while, and then immediately cancel their subscription so they don't have to keep paying even though they're still enjoying the content. And finally, I suggest that the average Netflix user doesn't even know what DRM is or "experience" it at all.
The Internet isn't what it used to be. It has been taken over and changed. Maybe should be called the commercialnet, or spynet or something of the sort.
The irony of your comment is that the Web has become dominated by ads and privacy intrusions in large part because people using it weren't willing to pay for stuff but still wanted the stuff. It turns out that people who make good stuff still have rent to pay, and that equivalent content and services don't always magically appear from within the community if no-one pays for them.
I'm sure that has nothing to do with a discussion about copyright, infringement, and alternative business models that become practical with DRM, though. Nope, no parallels there at all.
Then you're only looking at mainstream, mass market, fixed content. A great deal of content created commercially isn't actually in that category.
Also, it makes a big difference what the "digital format" is. Sure, if you're providing fixed content that someone can play at home, then if nothing else you're vulnerable to the analog hole if you're willing to accept the drop in quality, and for the next Avengers movie or Taylor Swift album or whatever, someone among the millions of interested people is going to bother doing that. But there are online DRM schemes that are pretty effective at preventing casual copying at full quality these days, which is probably one of the reasons content creators are so keen to move in that direction for distribution.
Most DRM isn't expected to prevent 100% of copies indefinitely. Usually it's intended to deter and/or delay casual copying, and in that, it is often quite successful these days. This is something that almost invariably gets overlooked in the "DRM never works" posts that will no doubt be filling this Slashdot discussion within minutes.
Smart people don't care what it stands for. This issue always going to be about balancing the rights of content providers and the rights of content consumers, or about balancing the restrictions on the same parties, depending on how you choose to look at it. What matters is finding a reasonable balance, whatever you call any technology or laws or whatever that are used to promote it.
As with almost all technology, it depends on context.
DRM can be abused to lock up content far in excess of normal copyright protections.
DRM also makes new and useful business models practical, giving us modern replacements for old school rental stores from the likes of Netflix and Spotify, which obvious work out for a lot of people.
It probably makes sense to break out each individual step into its own function, but if your algorithm has 20 steps, each of which might need some input data from various earlier steps, what advantage is there in breaking this function down any more? It's just fundamentally a long sequence of operations.
The other example I gave is a slightly different case, but a similar conclusion. The general subgraph isomorphism problem is NP-complete, but you probably know more about your underlying data in realistic situations, so matching algorithms often wind up being some sort of deeply nested search with the order of tests determined heuristically. The similarity to the previous example is that again each level of the search might need context from various outer levels. So again, what is gained by breaking out the inner loops into their own functions here? They have no inherent meaning without that context, so it's not as if they're going to be reusable or they're going to represent some useful abstraction with a meaningful name. It's just splitting up code that is fundamentally related to avoid some dogma about deep nesting being bad.
I don't know what your background is or whether you've ever worked in the kinds of fields where these sorts of situation tend to come up. A lot of programs only need very simple data structures and algorithms, and if that's the kind of code you tend to work on then maybe what I'm saying just looks like contrived examples. All I can say is that I've worked on many projects over the years that do have need of more sophisticated data structures and algorithms than, say, typical business management software, and I've seen plenty of code where having functions of 50-100 lines or longer is entirely reasonable. Obviously I'm not talking about all of the functions, or probably even most of them, but I would argue that the important point is whether each function provides some clean, coherent packet of functionality, not whether it's 5 lines long or 105.
Perhaps your mind works different than mine. For me it is obvious that a set of smaller functions is easier to understand and maintain than a big one.
From the discussions so far, I suspect we've just worked mostly on different types of software. In some cases, I do write a lot of quite small functions. But I don't do that because being small is good, I do it when it happens to need only a few lines of code to represent whatever concepts I'm working with at the time.
When I see people like Robert Martin making sweeping generalisations about keeping functions very short or keeping under N parameters or whatever, and particularly when those people also imply that anyone whose code doesn't follow their rules is somehow a bad programmer or unprofessional or whatever insult they're hurling around this week, I feel a bit like a guy modelling the aerodynamics for a supersonic jet plane whose ten-year-old kid thinks wing design doesn't really matter because he can get enough lift already with his paper plane.
A data processing pipeline with more than a handful of steps?
A subgraph match that needs to check for more than a handful of nodes and edges?
Those are the first two that come to mind, because I happened to work on both of them today.
Emphasize on "can". But they should not. So you are arguing because you write bad code (functions with side effects) it is pointless to write shorter functions?
If you're advocating being careful about where side effects happen, you're preaching to the choir. However, I have not yet been made god-emperor of the universe, so sadly I don't get to impose my preferred design style on everyone else and sometimes have to work with code written by foolish mortals. Also, I have yet to encounter a mainstream programming language that is actually good at supporting this goal.
We don't do that because of an arbitrary limit, like 15 lines. We do it to improve readability and maintainability and on top of that: testability.
The first part of this, about readability and maintainability, is just begging the question.
As for the testing part:
A complex algorithm that is divided into several small(er) functions can be tested by testing the functions individually. A big function can only be tested as a block. And then show me your test and proof that every branch in the function is at least tested once... if you are smart you are using a coverage analyzer for that;D
Merely breaking out parts of the code into smaller functions doesn't reduce the complexity of the decision tree, so if you want to argue for comprehensive branch coverage then you need just as many tests either way unless you're immediately reusing your smaller functions (and I don't think we're talking about that sort of scenario here).
In my experience, attempting comprehensive branch coverage as a strategy for writing unit test suites is usually futile and almost always inefficient anyway. There are many other ways to try to prevent errors that are usually more effective.
Which of us do you think hasn't gone to school and doesn't know the terminology we're using? Obviously we appear to disagree on this issue, but I don't see anywhere that the meaning isn't clear on either side.
That is a strawman. Nobody said very small. They simply should be small enough, that is all.
Unfortunately, that's not true. Plenty of people do openly and sometimes rather strongly advocate extremely short functions, including Robert Martin, whose book was mentioned back up the thread. Even the original point that was linked at the start of this thread suggests an upper limit of 15 lines, which is far too short for a lot of useful algorithms.
By "definition" a function only works their arguments and returns a result.
In a pure functional language, that is true. Almost anywhere else, it is not, because functions can have side effects, often including interacting with various forms of state kept outside the function.
Usually, if it is a method in a class, it does not even manipulate the attributes of its associated object.
If it's not doing anything with the attributes of its associated object, why is it a method on that class in the first place? This makes little sense, unless you're talking about languages where all functions live on some class and so sometimes classes are basically just used as namespaces with no state.
The only relation functions have to each other is their call hierarchy, which is easy to figure and in an IDE trivial. Worst case use the debugger.
Again, that only really works in certain types of programming language, though. In languages where you can pass functions around like any other value, or even just C-style function pointers, you have a level of indirection that makes systematically identifying all potential calls to a function significantly harder. If your functions really do represent self-contained concepts with a useful amount of abstraction, the trade-off is often still worth it, but if you're just breaking a relatively long function into smaller parts because of some arbitrary limit, it's a different story.
You write 10 small functions and then have another function that ties them all together. Problem solved, your system isn't any more complicated
Yes, it is. It's more complicated by now having 11 parts instead of one, and 10 extra relationships between them.
None of the rest of your claims follow automatically just from having more, smaller functions. Indeed, the point several of us are trying to make is that exactly the opposite may be true: breaking everything down into very small functions can make code harder to understand. While the individual functions are simpler, the number of potential relationships between them grows exponentially, and those relationships may not be as transparent once you've broken everything down into tiny pieces.
IMO, that recently UIs have swinged too much towards being good for touch use.
I agree with almost everything you wrote, but I think the above overlooks the real problem, which is that it is almost impossible to design a good UI for some tasks when you're constraining yourself to what works on small touchscreen devices. You can do OK if your presentation and interaction requirements are simple, and that's where those kinds of devices are useful: share a photo, write a short message, log a site visit. However, for more complicated systems, we have big screens with multiple information displays and space for direct controls, and we have keyboards and mice for relatively fast and precise input. Asking a UI designer to ignore all of that is like giving a painter nothing but thick, black paint and an inch-wide brush that they can only hold at the other end of its foot-long stem, and then asking them to create the next Mona Lisa.
Can we just kill all the "designers" and start over?
Or just hire some real ones. I'm sure they can afford it, and it's not like no-one in the design industry has criticised the modern generation of UIs for the same reasons many of us are here.
I sincerely doubt the UIs are getting worse year after year. If that were the case, we would have unusable devices by now.
Lately, we are sometimes coming awfully close to that. The lack of affordances in modern flat, touch-friendly, most-things-hidden UIs is horrible for usability compared to the explicit menus and toolbars and consistent conventions we had before. The things some UI designers seem to think people understand or want and the comments you hear and behaviour you see if you observe real users trying to operate the UI seem to be in different universes at times.
What is really happening is that people are resisting change.
That is also true, but there is a good reason for that. In most cases, UIs are not starting from a blank slate. If you take two UIs for something that the user has never done before, maybe one of them will work a bit better than the other one. But if you take those exact same UIs for something the user has done before but only using one of them, the other one needs to be much better to be worth the time and effort to learn it given that the user could already do what they needed to.
Also, obviously not all change is necessarily good change, and bad changes will naturally be resisted.
I haven't used much from Google in years, personally. I'll still use Google search if my first choices don't get good results, but usually they do fine. I watch videos on YouTube sometimes. It's not as if anyone actually has to use Google services routinely if they don't want to be subject to Google hassles.
We're all fine unless other admins start plastering Google-hosted junk all over their own sites. Oh, wait...
You got through after only two or three times? That's a huge improvement on the old system then. I have literally been locked out of making financial payments and even being able to access some government systems because of captcha madness, giving up trying after several minutes of not being able to get one right. The picture-based ones, where you have to click every square with a tree or road sign or something, are the worst. So much time wasted.
Does anyone know if they've fixed the privacy concerns about the Community edition yet?
Last time I checked, there were multiple inter-related privacy policies that seemed to apply, but between those and the general terms it seemed clear that they could upload more-or-less anything (including, say, your code) through their telemetry processes. You also needed a Microsoft account to even continue using the IDE after a few days.
This sort of nonsense simply shouldn't be necessary in real world development tools.
Just be glad you're not using professional networking gear that gets installed and then stays mostly untouched for years. A lot of gear that is still in use dates from the era when plugins were necessary to do just about anything graphical in a browser-based UI, and all of them just broke completely with the removal of NPAPI support. (There is a note on the Mozilla web site that the ESR for 52 doesn't have this limitation, so it looks like anyone in that position has about a year more before Firefox won't support them at all.)
I don't know of anywhere that time shifting is a legal right in the sense that whoever provides the content is also required to allow for it to be time-shifted or to provide any assistance in doing so. If the provider effectively restricts the use of the work in some other way, whether legal or technical, then whether any particular action would be permitted under copyright law doesn't really matter.
As an aside, in the UK, and actually most places outside the US that I know anything about, exceptions of whatever form to copyright protection tend to be quite tightly specified, rather than the generic tests of the US fair use doctrine. So it isn't even necessarily the case that something like time shifting would be automatically permitted under copyright law. A lot has come down to a handful of quite specific uses that have codified protections under the fair dealing rules, such as parody, and sometimes to the idea that consent is implicit in the basis on which a work was provided.
Just to be clear, this story is about the UK, and it's the law here in England that I was talking about as far as EULAs are concerned. I don't know whether the same theory has been tested in the US, which seems to be where you're talking about.
To be fair, that's hardly unprecedented in the history of copyright laws. I can't remember exactly which of the attempts to modernise the legal framework in recent years survived the subsequent challenges, but it might still be the case that, strictly speaking, recording a broadcast TV programme just to time-shift is legal but doing so to keep permanently and watch as often as you want is not.
Apparently if you keep all the data in RAM, it's "streaming" and not infringement. But the moment you write that sucker to disk, you're a dirty pirate.
If a court ruled along similar lines with software, that would also challenge a commonly claimed legal basis for many click-through EULAs and similar agreements being enforceable here (England). That might create an interesting legal landscape for the next few years, though with more software being supplied online by the original creators and subject to their direct terms of sale, that issue may be less relevant as time goes by.
Getting back to the original topic, it's always been the case that copyright actions have tended to go after the distributor rather than the purchaser/downloader. They're much easier targets in terms of clearly breaking the law, and it's also much more useful to stop one large distributor than one individual downloader.
But even if because streaming doesn't infringe copyright, that doesn't necessarily mean those doing it are safe. For example, if they're using some sort of crack to download from an authorised source but without the proper payment/permission, they're still subject to all the normal laws about unauthorised access to computer systems.
Slashdot Mirror
You don't have to use any of the new stuff, though. The "others" you mention add to what we had before. They don't replace it. You are free not to use e-commerce sites, or to stream music or movies, or to host your stuff in "the cloud". No-one is stopping you from restricting your browsing activity to personal or otherwise freely available websites, just like what you could access before. You are perfectly entitled to run a browser with JS disabled, ads blocked, and no plugins (including anything related to EME) if you don't want to use sites that rely on such technologies or feel that they compromise your security or privacy in unacceptable ways.
However, none of us is entitled say to everyone else, including the millions if not billions of people who find these new alternatives useful, that they can't have what they want because it's different to what we want. Also, none of us is entitled to tell those providing content that they must provide it in a certain format that we find convenient.
This mostly seems to be a combination of paranoia and slippery slope fallacies, and for someone who wants to see "proof and lots of it", your own argument is remarkably devoid of any supporting evidence.
I suggest to you that the existence of services like Netflix is beneficial to a great many people, who now get to enjoy more content at lower cost than they otherwise would have. I also suggest that services like Netflix would be much less practical without DRM, since obviously anyone could just sign up for whatever the minimum period is these days, download huge amounts of unprotected content to keep them going for a while, and then immediately cancel their subscription so they don't have to keep paying even though they're still enjoying the content. And finally, I suggest that the average Netflix user doesn't even know what DRM is or "experience" it at all.
The Internet isn't what it used to be. It has been taken over and changed. Maybe should be called the commercialnet, or spynet or something of the sort.
The irony of your comment is that the Web has become dominated by ads and privacy intrusions in large part because people using it weren't willing to pay for stuff but still wanted the stuff. It turns out that people who make good stuff still have rent to pay, and that equivalent content and services don't always magically appear from within the community if no-one pays for them.
I'm sure that has nothing to do with a discussion about copyright, infringement, and alternative business models that become practical with DRM, though. Nope, no parallels there at all.
Then you're only looking at mainstream, mass market, fixed content. A great deal of content created commercially isn't actually in that category.
Also, it makes a big difference what the "digital format" is. Sure, if you're providing fixed content that someone can play at home, then if nothing else you're vulnerable to the analog hole if you're willing to accept the drop in quality, and for the next Avengers movie or Taylor Swift album or whatever, someone among the millions of interested people is going to bother doing that. But there are online DRM schemes that are pretty effective at preventing casual copying at full quality these days, which is probably one of the reasons content creators are so keen to move in that direction for distribution.
Most DRM isn't expected to prevent 100% of copies indefinitely. Usually it's intended to deter and/or delay casual copying, and in that, it is often quite successful these days. This is something that almost invariably gets overlooked in the "DRM never works" posts that will no doubt be filling this Slashdot discussion within minutes.
Smart people don't care what it stands for. This issue always going to be about balancing the rights of content providers and the rights of content consumers, or about balancing the restrictions on the same parties, depending on how you choose to look at it. What matters is finding a reasonable balance, whatever you call any technology or laws or whatever that are used to promote it.
As with almost all technology, it depends on context.
DRM can be abused to lock up content far in excess of normal copyright protections.
DRM also makes new and useful business models practical, giving us modern replacements for old school rental stores from the likes of Netflix and Spotify, which obvious work out for a lot of people.
I would not know why both can not be expressed with a set of small functions.
Well, what would those small functions be? Suppose we've got a data processing pipeline that essentially looks something like this:
It probably makes sense to break out each individual step into its own function, but if your algorithm has 20 steps, each of which might need some input data from various earlier steps, what advantage is there in breaking this function down any more? It's just fundamentally a long sequence of operations.
The other example I gave is a slightly different case, but a similar conclusion. The general subgraph isomorphism problem is NP-complete, but you probably know more about your underlying data in realistic situations, so matching algorithms often wind up being some sort of deeply nested search with the order of tests determined heuristically. The similarity to the previous example is that again each level of the search might need context from various outer levels. So again, what is gained by breaking out the inner loops into their own functions here? They have no inherent meaning without that context, so it's not as if they're going to be reusable or they're going to represent some useful abstraction with a meaningful name. It's just splitting up code that is fundamentally related to avoid some dogma about deep nesting being bad.
I don't know what your background is or whether you've ever worked in the kinds of fields where these sorts of situation tend to come up. A lot of programs only need very simple data structures and algorithms, and if that's the kind of code you tend to work on then maybe what I'm saying just looks like contrived examples. All I can say is that I've worked on many projects over the years that do have need of more sophisticated data structures and algorithms than, say, typical business management software, and I've seen plenty of code where having functions of 50-100 lines or longer is entirely reasonable. Obviously I'm not talking about all of the functions, or probably even most of them, but I would argue that the important point is whether each function provides some clean, coherent packet of functionality, not whether it's 5 lines long or 105.
Perhaps your mind works different than mine. For me it is obvious that a set of smaller functions is easier to understand and maintain than a big one.
From the discussions so far, I suspect we've just worked mostly on different types of software. In some cases, I do write a lot of quite small functions. But I don't do that because being small is good, I do it when it happens to need only a few lines of code to represent whatever concepts I'm working with at the time.
When I see people like Robert Martin making sweeping generalisations about keeping functions very short or keeping under N parameters or whatever, and particularly when those people also imply that anyone whose code doesn't follow their rules is somehow a bad programmer or unprofessional or whatever insult they're hurling around this week, I feel a bit like a guy modelling the aerodynamics for a supersonic jet plane whose ten-year-old kid thinks wing design doesn't really matter because he can get enough lift already with his paper plane.
I never saw a reason for functions that long.
A data processing pipeline with more than a handful of steps?
A subgraph match that needs to check for more than a handful of nodes and edges?
Those are the first two that come to mind, because I happened to work on both of them today.
Emphasize on "can". But they should not. So you are arguing because you write bad code (functions with side effects) it is pointless to write shorter functions?
If you're advocating being careful about where side effects happen, you're preaching to the choir. However, I have not yet been made god-emperor of the universe, so sadly I don't get to impose my preferred design style on everyone else and sometimes have to work with code written by foolish mortals. Also, I have yet to encounter a mainstream programming language that is actually good at supporting this goal.
We don't do that because of an arbitrary limit, like 15 lines. We do it to improve readability and maintainability and on top of that: testability.
The first part of this, about readability and maintainability, is just begging the question.
As for the testing part:
A complex algorithm that is divided into several small(er) functions can be tested by testing the functions individually. A big function can only be tested as a block. And then show me your test and proof that every branch in the function is at least tested once ... if you are smart you are using a coverage analyzer for that ;D
Merely breaking out parts of the code into smaller functions doesn't reduce the complexity of the decision tree, so if you want to argue for comprehensive branch coverage then you need just as many tests either way unless you're immediately reusing your smaller functions (and I don't think we're talking about that sort of scenario here).
In my experience, attempting comprehensive branch coverage as a strategy for writing unit test suites is usually futile and almost always inefficient anyway. There are many other ways to try to prevent errors that are usually more effective.
Which of us do you think hasn't gone to school and doesn't know the terminology we're using? Obviously we appear to disagree on this issue, but I don't see anywhere that the meaning isn't clear on either side.
That is a strawman. Nobody said very small. They simply should be small enough, that is all.
Unfortunately, that's not true. Plenty of people do openly and sometimes rather strongly advocate extremely short functions, including Robert Martin, whose book was mentioned back up the thread. Even the original point that was linked at the start of this thread suggests an upper limit of 15 lines, which is far too short for a lot of useful algorithms.
By "definition" a function only works their arguments and returns a result.
In a pure functional language, that is true. Almost anywhere else, it is not, because functions can have side effects, often including interacting with various forms of state kept outside the function.
Usually, if it is a method in a class, it does not even manipulate the attributes of its associated object.
If it's not doing anything with the attributes of its associated object, why is it a method on that class in the first place? This makes little sense, unless you're talking about languages where all functions live on some class and so sometimes classes are basically just used as namespaces with no state.
The only relation functions have to each other is their call hierarchy, which is easy to figure and in an IDE trivial. Worst case use the debugger.
Again, that only really works in certain types of programming language, though. In languages where you can pass functions around like any other value, or even just C-style function pointers, you have a level of indirection that makes systematically identifying all potential calls to a function significantly harder. If your functions really do represent self-contained concepts with a useful amount of abstraction, the trade-off is often still worth it, but if you're just breaking a relatively long function into smaller parts because of some arbitrary limit, it's a different story.
You write 10 small functions and then have another function that ties them all together. Problem solved, your system isn't any more complicated
Yes, it is. It's more complicated by now having 11 parts instead of one, and 10 extra relationships between them.
None of the rest of your claims follow automatically just from having more, smaller functions. Indeed, the point several of us are trying to make is that exactly the opposite may be true: breaking everything down into very small functions can make code harder to understand. While the individual functions are simpler, the number of potential relationships between them grows exponentially, and those relationships may not be as transparent once you've broken everything down into tiny pieces.
IMO, that recently UIs have swinged too much towards being good for touch use.
I agree with almost everything you wrote, but I think the above overlooks the real problem, which is that it is almost impossible to design a good UI for some tasks when you're constraining yourself to what works on small touchscreen devices. You can do OK if your presentation and interaction requirements are simple, and that's where those kinds of devices are useful: share a photo, write a short message, log a site visit. However, for more complicated systems, we have big screens with multiple information displays and space for direct controls, and we have keyboards and mice for relatively fast and precise input. Asking a UI designer to ignore all of that is like giving a painter nothing but thick, black paint and an inch-wide brush that they can only hold at the other end of its foot-long stem, and then asking them to create the next Mona Lisa.
Can we just kill all the "designers" and start over?
Or just hire some real ones. I'm sure they can afford it, and it's not like no-one in the design industry has criticised the modern generation of UIs for the same reasons many of us are here.
I sincerely doubt the UIs are getting worse year after year. If that were the case, we would have unusable devices by now.
Lately, we are sometimes coming awfully close to that. The lack of affordances in modern flat, touch-friendly, most-things-hidden UIs is horrible for usability compared to the explicit menus and toolbars and consistent conventions we had before. The things some UI designers seem to think people understand or want and the comments you hear and behaviour you see if you observe real users trying to operate the UI seem to be in different universes at times.
What is really happening is that people are resisting change.
That is also true, but there is a good reason for that. In most cases, UIs are not starting from a blank slate. If you take two UIs for something that the user has never done before, maybe one of them will work a bit better than the other one. But if you take those exact same UIs for something the user has done before but only using one of them, the other one needs to be much better to be worth the time and effort to learn it given that the user could already do what they needed to.
Also, obviously not all change is necessarily good change, and bad changes will naturally be resisted.
Crazy idea, sounds like the Dark Ages or something.
The problem in defense is how far you can go without destroying from within what you are trying to defend from without.
Dwight D. Eisenhower
I haven't used much from Google in years, personally. I'll still use Google search if my first choices don't get good results, but usually they do fine. I watch videos on YouTube sometimes. It's not as if anyone actually has to use Google services routinely if they don't want to be subject to Google hassles.
We're all fine unless other admins start plastering Google-hosted junk all over their own sites. Oh, wait...
You got through after only two or three times? That's a huge improvement on the old system then. I have literally been locked out of making financial payments and even being able to access some government systems because of captcha madness, giving up trying after several minutes of not being able to get one right. The picture-based ones, where you have to click every square with a tree or road sign or something, are the worst. So much time wasted.
Does anyone know if they've fixed the privacy concerns about the Community edition yet?
Last time I checked, there were multiple inter-related privacy policies that seemed to apply, but between those and the general terms it seemed clear that they could upload more-or-less anything (including, say, your code) through their telemetry processes. You also needed a Microsoft account to even continue using the IDE after a few days.
This sort of nonsense simply shouldn't be necessary in real world development tools.
Just be glad you're not using professional networking gear that gets installed and then stays mostly untouched for years. A lot of gear that is still in use dates from the era when plugins were necessary to do just about anything graphical in a browser-based UI, and all of them just broke completely with the removal of NPAPI support. (There is a note on the Mozilla web site that the ESR for 52 doesn't have this limitation, so it looks like anyone in that position has about a year more before Firefox won't support them at all.)
I don't know of anywhere that time shifting is a legal right in the sense that whoever provides the content is also required to allow for it to be time-shifted or to provide any assistance in doing so. If the provider effectively restricts the use of the work in some other way, whether legal or technical, then whether any particular action would be permitted under copyright law doesn't really matter.
As an aside, in the UK, and actually most places outside the US that I know anything about, exceptions of whatever form to copyright protection tend to be quite tightly specified, rather than the generic tests of the US fair use doctrine. So it isn't even necessarily the case that something like time shifting would be automatically permitted under copyright law. A lot has come down to a handful of quite specific uses that have codified protections under the fair dealing rules, such as parody, and sometimes to the idea that consent is implicit in the basis on which a work was provided.
Just to be clear, this story is about the UK, and it's the law here in England that I was talking about as far as EULAs are concerned. I don't know whether the same theory has been tested in the US, which seems to be where you're talking about.
To be fair, that's hardly unprecedented in the history of copyright laws. I can't remember exactly which of the attempts to modernise the legal framework in recent years survived the subsequent challenges, but it might still be the case that, strictly speaking, recording a broadcast TV programme just to time-shift is legal but doing so to keep permanently and watch as often as you want is not.
Apparently if you keep all the data in RAM, it's "streaming" and not infringement. But the moment you write that sucker to disk, you're a dirty pirate.
If a court ruled along similar lines with software, that would also challenge a commonly claimed legal basis for many click-through EULAs and similar agreements being enforceable here (England). That might create an interesting legal landscape for the next few years, though with more software being supplied online by the original creators and subject to their direct terms of sale, that issue may be less relevant as time goes by.
Getting back to the original topic, it's always been the case that copyright actions have tended to go after the distributor rather than the purchaser/downloader. They're much easier targets in terms of clearly breaking the law, and it's also much more useful to stop one large distributor than one individual downloader.
But even if because streaming doesn't infringe copyright, that doesn't necessarily mean those doing it are safe. For example, if they're using some sort of crack to download from an authorised source but without the proper payment/permission, they're still subject to all the normal laws about unauthorised access to computer systems.