Bullshit. I own that copy of the recording and the piece of media it sits on.
Its the other way around - you own a piece of media and a license for personal usage of the recording within the media. If you want to change the media type, you need to acquire a new package (a new license for the recording and the supporting media of your choice).
I will do whatever the fuck I want to with that recording
No, you will do with the media. The copyright law explicitly forbids you to do anything else than personal reproduction of the media or transmission of your rights to another person (eg. selling a used CD). You cannot reproduce it publicly, you cannot broadcast it, you cannot clip it or alter it in any way, you cannot create multiple copies of it to allow reproduction on multiple devices simultaneously (only backup copies are allowed), you cannot claim it as your own. This is pretty common in almost copyright-abiding countries - and in most of them, playing a CD in a car with 4 persons in it technically requires licensing (but yeah, no one cares):)
It is MINE. I OWN IT.
Given that many of the bands available on a disk store don't even OWN their own work (they sell their ownership in turn of royalties), your claim is amusing:D
If I really like a song, I still acquire a real copy that's mine, rather than depend on Spotify to listen to it when I want to.
You don't own the recording, just the media. You license the recording. Streaming services allow me to listen to "whatever I want" (most music I hear is somewhat easy to find) without having to carry with me gigabytes of mp3 or whatever. And I do listen to lots of stuff once - I can "preview it" instead of doing the full commit of buying it. I usually listen to - at least - 5h of music per working day, so if I was buying CD's or mp3 it would get pretty expensive quickly. Given that some of my computers don't even have a working CD/DVD drive, it is often good deal. It doesn't mean I don't buy CDs, but I don't need to carry around the >300 albums I have in my Spotify playlist.
Streaming services are like buffet restaurants - they are not for everybody (nor they are meant to be), but in the end they are a very good deal for some people.
Please explain how this works. Are you equating baroque complexity with robustness? If not, show how the approach you refer to is more robust than Unix pipes.
Given the sheer amount of system resources allocated to complex pipe usage (eg. file descriptors) that render them useless in most recursive usage scenarios, and the fact that they only work with "streams of bytes", I'd say there's a lot to be improved on. We're not in the 70's anymore.
Accessible from within the terminal emulator hosting the command line?
No UNIX I know of *has* manual pages accessible from within the terminal emulator. They all rely on an external utility for it, that can actually be run directly without a terminal (eg. on a custom app by executing an exec call) - man or info or whatever.
Not in my experience. linux man pages have a habit of saying "go read the info pages"* and where they've been replaced with slightly better versions (debian tries to offer this) they aren't as extensive as what I consider normal for manpages.
I'd suggest you to have a look at the man pages of any modern BSD system, to see how "proper man pages" looks like. More often than not, manpages in linux are outdated, because features tend to be deployed without updating the documentation.
You're welcome to colour me biased, because I'm used to systems that hold themselves to much higher standards here.
I'd say that part of that prosperity derived from American support, including financial one with plan Marshall. France finished WWII with most of their core infrastructure intact, in contrast with the devastated cities of the nearby countries (UK, Spain - from civil war, Germany, etc), and they quickly learned how to modernize their industry by using the american example.
Don't worry. It won't take long for the Europeans to self destruct again and America will be there to pick up the pieces.
Are you talking about the same country it seems to spy everyone everywhere but could not find a single guy living in Pakistan (an allied country) as a neighbour to american military settlements? That America or the one that only seems to exist in your head?
THE ONLY REASON YOU CAN TRUST OSS ON LINUX is because you can see the source and there is nowhere for malware to hide.
While I do understand what you're saying, either you are a OS wizard or you are _TRUSTING_ that OTHER PEOPLE checked the code for malware. Since this is Slashdot, I'd bet on the latter. Truth is, there are always obscure and not-so-documented parts of every operating system where you don't really know what's happening, specially (in Linux's case) when you have several commercial companies contributing to it. Most modern Linux distros ALLOW the loading of blob's right in the kernel - they call them drivers. And if you think having the source is the proof you need, think again. Just look at the recent arguments about RNG, or a bit further away, the whole "backdoor in OpenBSD's IPSEC" discussion.
Be very suspicious of any software for Linux that requires/root r+w after install
Having root +rw is no big problem (I don't like it, but its not suid), since all root-level processes have access to what they want anyway. However, a malicious application may be able to piggyback into sudo to easily gain root access. For that, I'd recommend using an operating system that does not rely on sudo (eg. BSD):)
unless someone wrote a piece of spyware to discover them and linux users were stupid enough to run it as root
Spyware DOES NOT require root privileges. Most distros will run the software spyware wants to spy on with the current user's privileges - this usually includes some parts of X itself, browsers and most of other pieces of software that may handle sensitive information. There is a huge impedance between GUI systems an UNIX permissions system, but no one seems to care. The only reason why we don't have a huge spike in spyware for Linux (or OSX) is because they still don't matter in the big pool of users. And all those "modern vulnerabilites" (social engineering/phishing, CSRF, etc) still work on most*NIX users.
UNIX operating systems are not about user security, but system security - you may have a heavily "infected" user, but you cannot access or change system wide settings on the machine. The same way, a given user may not be able to interfere with other user's settings (much more "lets sandbox user's crap" than "lets protect users").
Want to be above average? Sandbox your browser and your applications in different users. As it SHOULD be. And deal with the problems from X for this (not shure if it still requires being run as root, or if its possible to have an ACL on the socket).
America invented the 20th century between 1950 and 1970, during a time when the average wage doubled.
If you look closely, it almost seems like the other "big" countries were a wreck during that period... as if they were recovering from a devastating war.
SQL is a declarative language, not an imperative one.
Actually, its not. DDL is declarative. DML, while usuallly vendor-dependent, its not necessarily declarative, and most often than not, is imperative. But anyway.
Yes, machine language is imperative.
Actually, its not. Machine language is declarative - you DESCRIBE values and operations (scroll up for people talking about VHDL and Verilog similarities) . Assembly is usually considered to be imperative. But, because of that, most languages are imperative at some level - regardless of how you describe shit. That is still the point.
Actually, no, I would have not any difficulty at all figuring that out--it's really quite easy for me to spot whether or not a programming language requires/allows me to specify control flow.
HTML allows you to specify control flow for some given browsers - does that make HTML a programming language?
Grow out of your shell. The world is not black and white.
The point is that *every* imperative or functional language has a declarative part. Even SQL. And in the end, every language that is compiled into dynamic programmable logic (as in actual microprocessor instructions) is translated into simple statements, and at that level there is no difference between declarative and imperative - there is usually no practical difference between "assume X is 5" or "move 5 to value of X". If you want to be "scholar" about it, go ahead. In the end, it's all ones and zeros, so I'd guess you'll have a hard time figuring out if they are declarative (as in defining rules and limits) or imperative (performing operations).
Again, programmable logic. Do you know the actual difference between one and the other? You could even do "push Y to stack / call X to decide what to do with it". and in both examples you provided, the generated code for programmable logic would be stuff like "memory position X has value Y; compare [X] with [Z]". There is no friggin difference, since most processors dont understand actual complex data structures (eg. a quicksort of a bunch of strings).
This is my personal opinion, but the whole "lets fit languages into predefined buzzwords" is f*** bullshit. Every strong typed language has a declarative section with static or partially static values, that define data structure. So before the "do this", you define "where". Moving to your example, x = bar 3.14 and not necessarily y. Out-of-order declaration is allowed because there is no cascading dependency (eg. y value cannot change globally, so it doesn't matter where it is declared). That is syntax sugar (again, my opinion) that adds nothing to the problem. As an example, its a bit like declaring functions external (as references not solvable in compile time) and be surprised when the linker does its job.
In the end, its all ones and zeros. And AFAIK, processors don't eat up stuff like "this is the way it is", but rather direct, declarative/imperative (is there an actual difference?) statements.
Expressing variables as functions is not new - most modern languages allow you to use them to some extent, and many database systems also - specially considering the NoSQL kind. Automata and state machines are also not new (counting decades), and actually I find your link way more interesting and informative than TFA.
Ok, I've read the article diagonally (hey its slashdot!), and apparently someone will have a big surprise when arriving to the letter T (triggers) in their SQL manual. And if it is an actual PostgreSQL manual, imagine their surprise when they find out they can actually code said "triggers" using several high-level languages.
Next week I'm expecting a blog article explaining why it is a bad idea to embed application logic in the database... Then again, this will still be slashdot:P
From the article description I couldn't figure out a) what is actually reactive programming; b) how will that help me build better applications. Complex applications are already built from a series of simple declarative statements. In fact, we call the most simple declarative statements language available "assembly". We call the machine representation of those very complex applications built with simple declarative statements "binary". On the other hand, Brainfuck also allows you to build complex applications with very simple statements, and I'm not migrating to it anytime soon.
Not cool, Slashdot, I'm going to have to read TFA!
Slashdot Mirror
Bullshit. I own that copy of the recording and the piece of media it sits on.
Its the other way around - you own a piece of media and a license for personal usage of the recording within the media. If you want to change the media type, you need to acquire a new package (a new license for the recording and the supporting media of your choice).
I will do whatever the fuck I want to with that recording
No, you will do with the media. The copyright law explicitly forbids you to do anything else than personal reproduction of the media or transmission of your rights to another person (eg. selling a used CD). You cannot reproduce it publicly, you cannot broadcast it, you cannot clip it or alter it in any way, you cannot create multiple copies of it to allow reproduction on multiple devices simultaneously (only backup copies are allowed), you cannot claim it as your own. This is pretty common in almost copyright-abiding countries - and in most of them, playing a CD in a car with 4 persons in it technically requires licensing (but yeah, no one cares) :)
It is MINE. I OWN IT.
Given that many of the bands available on a disk store don't even OWN their own work (they sell their ownership in turn of royalties), your claim is amusing :D
If I really like a song, I still acquire a real copy that's mine, rather than depend on Spotify to listen to it when I want to.
You don't own the recording, just the media. You license the recording. Streaming services allow me to listen to "whatever I want" (most music I hear is somewhat easy to find) without having to carry with me gigabytes of mp3 or whatever. And I do listen to lots of stuff once - I can "preview it" instead of doing the full commit of buying it. I usually listen to - at least - 5h of music per working day, so if I was buying CD's or mp3 it would get pretty expensive quickly. Given that some of my computers don't even have a working CD/DVD drive, it is often good deal. It doesn't mean I don't buy CDs, but I don't need to carry around the >300 albums I have in my Spotify playlist.
Streaming services are like buffet restaurants - they are not for everybody (nor they are meant to be), but in the end they are a very good deal for some people.
Please explain how this works. Are you equating baroque complexity with robustness? If not, show how the approach you refer to is more robust than Unix pipes.
Given the sheer amount of system resources allocated to complex pipe usage (eg. file descriptors) that render them useless in most recursive usage scenarios, and the fact that they only work with "streams of bytes", I'd say there's a lot to be improved on. We're not in the 70's anymore.
Accessible from within the terminal emulator hosting the command line?
No UNIX I know of *has* manual pages accessible from within the terminal emulator. They all rely on an external utility for it, that can actually be run directly without a terminal (eg. on a custom app by executing an exec call) - man or info or whatever.
Not in my experience. linux man pages have a habit of saying "go read the info pages"* and where they've been replaced with slightly better versions (debian tries to offer this) they aren't as extensive as what I consider normal for manpages.
I'd suggest you to have a look at the man pages of any modern BSD system, to see how "proper man pages" looks like. More often than not, manpages in linux are outdated, because features tend to be deployed without updating the documentation.
You're welcome to colour me biased, because I'm used to systems that hold themselves to much higher standards here.
So, you're not using Linux, right?
I'd say that part of that prosperity derived from American support, including financial one with plan Marshall. France finished WWII with most of their core infrastructure intact, in contrast with the devastated cities of the nearby countries (UK, Spain - from civil war, Germany, etc), and they quickly learned how to modernize their industry by using the american example.
Don't worry. It won't take long for the Europeans to self destruct again and America will be there to pick up the pieces.
Are you talking about the same country it seems to spy everyone everywhere but could not find a single guy living in Pakistan (an allied country) as a neighbour to american military settlements? That America or the one that only seems to exist in your head?
toor is looking at you!
THE ONLY REASON YOU CAN TRUST OSS ON LINUX is because you can see the source and there is nowhere for malware to hide.
While I do understand what you're saying, either you are a OS wizard or you are _TRUSTING_ that OTHER PEOPLE checked the code for malware. Since this is Slashdot, I'd bet on the latter. Truth is, there are always obscure and not-so-documented parts of every operating system where you don't really know what's happening, specially (in Linux's case) when you have several commercial companies contributing to it. Most modern Linux distros ALLOW the loading of blob's right in the kernel - they call them drivers. And if you think having the source is the proof you need, think again. Just look at the recent arguments about RNG, or a bit further away, the whole "backdoor in OpenBSD's IPSEC" discussion.
Be very suspicious of any software for Linux that requires /root r+w after install
Having root +rw is no big problem (I don't like it, but its not suid), since all root-level processes have access to what they want anyway. However, a malicious application may be able to piggyback into sudo to easily gain root access. For that, I'd recommend using an operating system that does not rely on sudo (eg. BSD) :)
unless someone wrote a piece of spyware to discover them and linux users were stupid enough to run it as root
Spyware DOES NOT require root privileges. Most distros will run the software spyware wants to spy on with the current user's privileges - this usually includes some parts of X itself, browsers and most of other pieces of software that may handle sensitive information. There is a huge impedance between GUI systems an UNIX permissions system, but no one seems to care. The only reason why we don't have a huge spike in spyware for Linux (or OSX) is because they still don't matter in the big pool of users. And all those "modern vulnerabilites" (social engineering/phishing, CSRF, etc) still work on most*NIX users.
UNIX operating systems are not about user security, but system security - you may have a heavily "infected" user, but you cannot access or change system wide settings on the machine. The same way, a given user may not be able to interfere with other user's settings (much more "lets sandbox user's crap" than "lets protect users").
Want to be above average? Sandbox your browser and your applications in different users. As it SHOULD be. And deal with the problems from X for this (not shure if it still requires being run as root, or if its possible to have an ACL on the socket).
America invented the 20th century between 1950 and 1970, during a time when the average wage doubled.
If you look closely, it almost seems like the other "big" countries were a wreck during that period... as if they were recovering from a devastating war.
then again, to some extent, so are big groups of mathematical operations in C (if they don't have side-effects)
And replying to
No, I actually know the difference pretty damned well.
Shure you do, shure you do.
DECLARE foo(last) = VALUES(bar)
what you're saying strongly suggests that you don't know what declarative programming is at all.
Or I do and I still call it bullshit. Which one will make you think twice about stuff?
You're having fun heh? At least I'm learning something :D Thank you. Really
SQL is a declarative language, not an imperative one.
Actually, its not. DDL is declarative. DML, while usuallly vendor-dependent, its not necessarily declarative, and most often than not, is imperative. But anyway.
Yes, machine language is imperative.
Actually, its not. Machine language is declarative - you DESCRIBE values and operations (scroll up for people talking about VHDL and Verilog similarities) . Assembly is usually considered to be imperative. But, because of that, most languages are imperative at some level - regardless of how you describe shit. That is still the point.
Actually, no, I would have not any difficulty at all figuring that out--it's really quite easy for me to spot whether or not a programming language requires/allows me to specify control flow.
HTML allows you to specify control flow for some given browsers - does that make HTML a programming language?
Grow out of your shell. The world is not black and white.
True, but the replies aren't against the (non) article - they are about me stating assembly is a declarative language. You add nothing to it.
The point is that *every* imperative or functional language has a declarative part. Even SQL. And in the end, every language that is compiled into dynamic programmable logic (as in actual microprocessor instructions) is translated into simple statements, and at that level there is no difference between declarative and imperative - there is usually no practical difference between "assume X is 5" or "move 5 to value of X". If you want to be "scholar" about it, go ahead. In the end, it's all ones and zeros, so I'd guess you'll have a hard time figuring out if they are declarative (as in defining rules and limits) or imperative (performing operations).
Again, programmable logic. Do you know the actual difference between one and the other? You could even do "push Y to stack / call X to decide what to do with it". and in both examples you provided, the generated code for programmable logic would be stuff like "memory position X has value Y; compare [X] with [Z]". There is no friggin difference, since most processors dont understand actual complex data structures (eg. a quicksort of a bunch of strings).
Yes I did :D And that will actually come handy in a current project, tnx for the refresh!
So, what you're saying is that "Memory position X has value Y" is different from "Move Y to memory position X" in programmable logic?
This is my personal opinion, but the whole "lets fit languages into predefined buzzwords" is f*** bullshit. Every strong typed language has a declarative section with static or partially static values, that define data structure. So before the "do this", you define "where". Moving to your example, x = bar 3.14 and not necessarily y. Out-of-order declaration is allowed because there is no cascading dependency (eg. y value cannot change globally, so it doesn't matter where it is declared). That is syntax sugar (again, my opinion) that adds nothing to the problem. As an example, its a bit like declaring functions external (as references not solvable in compile time) and be surprised when the linker does its job.
In the end, its all ones and zeros. And AFAIK, processors don't eat up stuff like "this is the way it is", but rather direct, declarative/imperative (is there an actual difference?) statements.
Expressing variables as functions is not new - most modern languages allow you to use them to some extent, and many database systems also - specially considering the NoSQL kind. Automata and state machines are also not new (counting decades), and actually I find your link way more interesting and informative than TFA.
Yes. "Views" and "Mature" are not cool buzzwords for CTOs.
Usually database manuals calls them triggers.
Ok, I've read the article diagonally (hey its slashdot!), and apparently someone will have a big surprise when arriving to the letter T (triggers) in their SQL manual. And if it is an actual PostgreSQL manual, imagine their surprise when they find out they can actually code said "triggers" using several high-level languages. :P
Next week I'm expecting a blog article explaining why it is a bad idea to embed application logic in the database... Then again, this will still be slashdot
From the article description I couldn't figure out a) what is actually reactive programming; b) how will that help me build better applications. Complex applications are already built from a series of simple declarative statements. In fact, we call the most simple declarative statements language available "assembly". We call the machine representation of those very complex applications built with simple declarative statements "binary". On the other hand, Brainfuck also allows you to build complex applications with very simple statements, and I'm not migrating to it anytime soon.
Not cool, Slashdot, I'm going to have to read TFA!
DoubleClick is ad-related: http://en.wikipedia.org/wiki/DoubleClick Optimizely is a javascript-based A/B testing platform, quite common these days