He was referring to the original poster who said, "BSD however, really only has one user base - and they largely want the same thing. Stability, security, and performance. So all the cute little desktop friendly stuff that Linux keeps adding and all the server-specific stuff that Linux keeps adding aren't there." So he (semi-jokingly) asked, if BSD doesn't have "server" or "desktop" stuff, then what does it do?
True, but given a set of conditions including "value" or "complexity" of the submission, it'd be damn-near impossible to judge the final result. Your hypothetical example is easy: if the dirt-simple algo got a 10.2% improvement, whereas the algos with magnitudes greater complexity netted a 10.4% improvement, it'd be easy to say the simple algo is more "valuable." But what if the complexity differences are much smaller? How do you judge them when the improvement is also close? I think Netflix was smart by providing a numerical target and detailing specifically how the numerical results are calculated. While there's always room for people to argue a result, it's harder when the criteria are simple.
It is? I only see a bit in a question about licensing (somewhat tangential) that suggests that Netflix hopes that participants will be able to build a business out of the algorithm they design, but that sounds pretty weak, and doesn't have all that much to do with what the participants got, aside from the prize money.
The contest has been going on for three and a half years, and the winning team of seven will be splitting a cool million, which gives each person just under $145k, minus taxes. Now, I don't know how much time these guys spent on it, but even if they only worked a year's worth of regular work hours over the 3.5 years, $145k per year each for seven developers is a pretty damn good bargain from Netflix's perspective for what they got (not just the new algorithm, but a lot of good PR and buzz).
I'm not saying the BellKor guys got the shaft; they were certainly compensated (not just monetarily; I'm sure their employability went up as well), and I'm sure a big part of their desire to compete was the challenge itself. But I'd bet that Netflix would've had to pay quite a bit more.
And it's not like the BellKor team did all the work; all the other teams did some of the same work independently. I imagine many (most?) of them didn't stand a chance, but let's just throw out a conservative number and say the top 5% of teams managed to improve on Netflix's existing algorithm (even if not by 10%). It's conceivable to believe that an in-house team of paid developers/researchers would end up doing an analogous iterative process, achieving smaller gains, eventually reaching the 10% goal. Depending on Netflix's hiring skills, it's possible they wouldn't reach a 10% increase without many more man-years of work.
This contest was a very smart move on Netflix's part: their only real downside is that their -- self-imposed -- competition terms will allow the contest participants to competitively license their implementations to other companies.
Other tasks like live midi stuff tend to require low latency or it will sound extremely off.
... which is why you should be using jack for these sorts of things.
Yes, they have been trying to work together, but serious question have you ever tried this setup? It's not pretty, the pulse audio sink for jack has a myriad of problems, and most of the time it just plain doesn't work.
This may improve in future, but for now it is extremely hit or miss, with most of the time being miss.
I never said it worked perfectly, just that there's been a commitment made to support this setup. PA is a new technology, and the basic concept of sharing an ALSA device between two sound-server-like apps is completely new as well. These things just don't magically start working overnight.
Better yet, try implementing them, I have.
Have you filed bug reports and tried to help fix the issues, or are you just complaining uselessly?
I'm sorry you have shitty drivers for your audio hardware, but cutting in PA as default for several distributions was a calculated move designed to quickly expose these sorts of problems so they could be fixed in the audio drivers themselves (PA exercises the ALSA API in many different interesting ways that most apps don't).
If you object to the idea of your distro using you as a guinea pig, I can certainly understand that, but that's a separate issue.
I suffer no latency problems with PA. How is it a band aid? It's the way of the future, as long as proper software mixing and control is kept out of the kernel. PA gives Linux a decent audio API, starting to approach the kinds of things you can do on Windows or MacOS.
Only professional apps tend to support jack.
Because jack solves a problem that has nothing to do with regular ol' desktop audio.
Feel free to read up on things so you understand them before posting. PA and jack can coexist (and the developers of both have been working together for some time now to ensure this is so), and solve completely different problems.
No, not really. I was looking for a particular post from Benjamin Otte, the latest swfdec maintainer, but I couldn't find the one I wanted This one paints part of the picture, but not the whole thing.
The problem is that the Flash spec is very incomplete. It doesn't specify how errors should be handled, and, while it does specify what Adobe *wanted* the official Flash player to do, the official Flash player has tons of subtle bugs, many of which lots of real-world Flash apps depend on to function properly. So implementing the Flash spec isn't enough to run anything but trivial Flash apps. After you implement the spec, then you have to guess how various errors are handled, and compare it to how the official player does it. Then you have to figure out all the places where the official player deviates from the spec, and effectively make your player buggy. And then you have to take behavior that's specified as being undefined by the spec, and implement it in the exact same "undefined" way that the official player does. Unfortunately, they only way to find most of these things is to throw a *lot* of flash files at your player and then painstakingly debug to figure out why they don't work.
It's a mess, and of course Flash is a moving target, which doesn't help matters.
Except that they don't. A CS degree doesn't say squat about your ability to develop good software. It does say that you probably have a clue about at least one programming language, and *probably* know a fair bit about algorithms, data structures, and computing theory, but that may or may not be relevant to a particular "software development" position. And all that's completely ignoring the huge variety in the quality of education you'll get at various colleges and universities.
Besides, if I'm not mistaken, state programs like electrician licensing have mandatory renewal and re-testing. It's one thing to have gone through a recent, up-to-date licensing program, and another to have completed a BS in CS 15 years ago.
Not to mention the fact that a state licensing program is strictly tailored for performing a particular job. A college degree need not have anything to do with job skills.
It's not hard to understand, I just don't read code that way. Error handling is not a part of "what the function does." Error handling deals with exceptional conditions that you usually hope/assume won't happen, but of course the error handling needs to be there to catch the 0.2% of the time when they do.
So "what the function does" is all the statements that have nothing to do with error handling. In the "correct" case, the function is linear: in most cases you will just execute from top to bottom, and it's done. Reading someone else's code, it'll be clearer to me much faster what is going on without the nested "if pyramid" mess.
But hey, dif'rent strokes for dif'rent folks. That's why everyone has their own coding style.
While the goto in this case does usually end up resulting in an "only one return" (or two, depending on how it's implemented), the purpose of it is to avoid copy and paste for a lot of cleanup code. Without goto, if you do multiple returns, you end up with something like:
If you have more than just one thing to clean up, or different things depending on how far you made it into the function before encountering an error, it gets worse. And if you later add code to the middle of the function that *also* needs cleanup code on errors, then you end up copy and pasting the existing error code, and then adding an extra cleanup line to all the extra error conditions below it.
With a simple goto on error, you can put all of your cleanup code in one place in the function, and only have a single copy of it. Not only does this make it clearer what the code above it does (the error handling, while necessary, only serves to obscure the real purpose of the code), but it's a lot more maintainable and easier to extend.
You could also achieve something similar with a series of nested if statements, such as:
... with the error handling code after each if block, but that quickly becomes unwieldy if you have more than 5 or so operations, as you end up 6 or more indentation levels deep. I use 4-space indentation, but I know people who like 8, which makes the problem occur twice as fast. Even ignoring the indentation issues, personally I find the "if pyramid" less readable than goto-based error handling.
Hopefully not, seeing as the "=" there will likely net you a syntax error when you try to use your preprocessor symbol in the program. (Unless you're doing something retarded, anyway.)
That would be a little more difficult here. Not only is the US orders of magnitude larger than the UK, but I doubt Dish or DirecTV have the resources to police the entire country. Not to mention they don't know how you're getting your signal. If you put your dish in your back yard and an eavesdropping Dish Network truck drives by, how do they know what you're watching, even assuming they can hear your TV (unlikely)? Maybe you're using cable. Maybe you're using free OTA broadcast. Maybe you're using one of their competitors. No way for them to know.
But what you have to remember is that they are the ones to decide what the prices are. If their prices is what it takes to do business, then that's what they'll charge.
Of course. I just happen to think their pricing model is flawed, and their "fix" for their piracy problem will cause them more problems than it solves. Only time will tell how it'll play out.
You have totally missed it. Linux Game Publishin publishes games. The companies you name are developers who happen to make the majority of their money on all platformas other than Linux.
Maybe you should listen to what the developers actually think.
Heh, I don't particularly care that much.
If they can't then they will go bankrupt. But if they believe that DRM will help them, it's their right to use it.
Sure it is. My guess is that it won't work well for them. It'll probably reduce their piracy rate, but I doubt it'll increase sales. If anything, it'll probably decrease sales.
Windows users aren't particularly thrilled about DRM these days. How crazy does LGP have to be to think that all their current Linux users -- and a significant portion of their Linux pirates -- will swallow DRM?
I'm arguing that a software integrator need not be involved in the development of every piece of software they ship. I'm certainly not denying that the kernel needs work, but I think it's perfectly reasonable if Canonical decides they don't want to retain kernel expertise on their payroll. It's a business decision, like any other, and it doesn't seem to have been hurting them.
How is that ignorant? The BM organizers have set up a closed environment where they are nominally in control of photography and videography. Of course their control is not perfect, but it appears to be "good enough" to satisfy a lot of people.
So? They contribute to GNOME and to other software they use. Why is it required/expected that a company contribute to every single open source project whose software they use?
Except that's not true, at least on the surface. Settings -> Privacy -> Applications, Settings tab:
"You can use the controls on this page to limit what types of information your friends can see about you through applications. Please note that this is only for applications you do not use yourself:"
And there's a list of about 20 checkboxes that allow you to restrict what applications *that your friends add* can see about you. Whether or not it actually works is up for question, of course.
Now, annoyingly, any app *you* add yourself gets access to all of your information, regardless of your privacy settings ("When you authorize an application, it can access any information associated with your account that it requires to work"). It would be nice to be able to semi-sandbox apps you add as well. (It does say that they never share contact information through the app platform, which is nice.)
I remember when the app platform was new, you were prompted about the specific types of information the app required and could optionally use, and you could uncheck the optional ones you didn't want to share. The required ones were set in stone, but you'd at least know at that point what would be shared and could make a better decision to allow or deny. A shame that feature is gone.
Actually, scratch that. The Applications privacy settings page specifically is for your info that applications are allowed to see when a friend adds it. So it turns out I'm wrong. Unfortunately, there's *no* way to limit what applications that you add are allowed to see -- they're supposed to abide by your privacy settings, but that isn't enforced by any technical measures. In fact, it explicitly says: "When you authorize an application, it can access any information associated with your account that it requires to work." The "that it requires to work bit" is a bit misleading, because the apps get to self-define what they require. There aren't any measures in place to limit this.
No, the ACLU app says exactly what you said, and it *shows* you the information from your friends' profiles that it can see.
But that's the problem. When I set, say, the privacy setting for my birth date to "friends only," I expect my friends to be able to see my birth date, and no one else. This does not include the developers of an application that my friend installed.
This is even more confusing because each user has privacy settings for applications too. It's not clear to the average user that those settings only apply to what *you* share with applications that *you* add. If you've hidden your birth date from applications, then *your* addition of an app won't leak your birth date to that app, but if one of your friends (who can see your birth date) adds that same app, then the app can get your birth date through that connection.
I picked a mundane piece of information (birth date) as an example, but this becomes more of a problem when you think about home address or phone number.
Clearly you have no grasp of economics. If the CEO is correct in that for every sale they make, there are 3-4 pirated copies, they should look into figuring out *why* there are pirated copies. Sure, there will be a subset of people who will just never pay for anything and will only ever pirate software. But surely a percentage of those people would pay if the price was more reasonable. If they cut prices by 25% and that decreases the piracy ratio from 4:1 to 3:1, they make more money than they did before. Obviously my numbers are fabricated, but, as another poster has mentioned, Frictional and Introversion seem to get by ok without DRM with more reasonable prices. It's LGP's own damned fault if they can't price their products appropriately for their market.
You're completely ignoring platform integration issues. Creating, testing, and maintaining a self-extracting installer for win32,.app bundle and.dmg for mac,.deb/.rpm/.tgz for linux is non-trivial and can take up a bunch of time... and that's just one aspect of platform integration
Hell, even ignoring that, adding testing and tech support for the app itself on a new platform isn't free. A company considering a port to another platform certainly has to consider that aspect as well.
Slashdot Mirror
He was referring to the original poster who said, "BSD however, really only has one user base - and they largely want the same thing. Stability, security, and performance. So all the cute little desktop friendly stuff that Linux keeps adding and all the server-specific stuff that Linux keeps adding aren't there." So he (semi-jokingly) asked, if BSD doesn't have "server" or "desktop" stuff, then what does it do?
Yeah, I don't get it either. More like Offtopic is the new "I disagree with you".
True, but given a set of conditions including "value" or "complexity" of the submission, it'd be damn-near impossible to judge the final result. Your hypothetical example is easy: if the dirt-simple algo got a 10.2% improvement, whereas the algos with magnitudes greater complexity netted a 10.4% improvement, it'd be easy to say the simple algo is more "valuable." But what if the complexity differences are much smaller? How do you judge them when the improvement is also close? I think Netflix was smart by providing a numerical target and detailing specifically how the numerical results are calculated. While there's always room for people to argue a result, it's harder when the criteria are simple.
It is? I only see a bit in a question about licensing (somewhat tangential) that suggests that Netflix hopes that participants will be able to build a business out of the algorithm they design, but that sounds pretty weak, and doesn't have all that much to do with what the participants got, aside from the prize money.
The contest has been going on for three and a half years, and the winning team of seven will be splitting a cool million, which gives each person just under $145k, minus taxes. Now, I don't know how much time these guys spent on it, but even if they only worked a year's worth of regular work hours over the 3.5 years, $145k per year each for seven developers is a pretty damn good bargain from Netflix's perspective for what they got (not just the new algorithm, but a lot of good PR and buzz).
I'm not saying the BellKor guys got the shaft; they were certainly compensated (not just monetarily; I'm sure their employability went up as well), and I'm sure a big part of their desire to compete was the challenge itself. But I'd bet that Netflix would've had to pay quite a bit more.
And it's not like the BellKor team did all the work; all the other teams did some of the same work independently. I imagine many (most?) of them didn't stand a chance, but let's just throw out a conservative number and say the top 5% of teams managed to improve on Netflix's existing algorithm (even if not by 10%). It's conceivable to believe that an in-house team of paid developers/researchers would end up doing an analogous iterative process, achieving smaller gains, eventually reaching the 10% goal. Depending on Netflix's hiring skills, it's possible they wouldn't reach a 10% increase without many more man-years of work.
This contest was a very smart move on Netflix's part: their only real downside is that their -- self-imposed -- competition terms will allow the contest participants to competitively license their implementations to other companies.
Got any links to online sources? I could use a good laugh to pass around at the office...
Other tasks like live midi stuff tend to require low latency or it will sound extremely off.
... which is why you should be using jack for these sorts of things.
Yes, they have been trying to work together, but serious question have you ever tried this setup? It's not pretty, the pulse audio sink for jack has a myriad of problems, and most of the time it just plain doesn't work.
This may improve in future, but for now it is extremely hit or miss, with most of the time being miss.
I never said it worked perfectly, just that there's been a commitment made to support this setup. PA is a new technology, and the basic concept of sharing an ALSA device between two sound-server-like apps is completely new as well. These things just don't magically start working overnight.
Better yet, try implementing them, I have.
Have you filed bug reports and tried to help fix the issues, or are you just complaining uselessly?
I'm sorry you have shitty drivers for your audio hardware, but cutting in PA as default for several distributions was a calculated move designed to quickly expose these sorts of problems so they could be fixed in the audio drivers themselves (PA exercises the ALSA API in many different interesting ways that most apps don't).
If you object to the idea of your distro using you as a guinea pig, I can certainly understand that, but that's a separate issue.
PulseAudio was a band aid with horrible latency,
I suffer no latency problems with PA. How is it a band aid? It's the way of the future, as long as proper software mixing and control is kept out of the kernel. PA gives Linux a decent audio API, starting to approach the kinds of things you can do on Windows or MacOS.
Only professional apps tend to support jack.
Because jack solves a problem that has nothing to do with regular ol' desktop audio.
Feel free to read up on things so you understand them before posting. PA and jack can coexist (and the developers of both have been working together for some time now to ensure this is so), and solve completely different problems.
No, not really. I was looking for a particular post from Benjamin Otte, the latest swfdec maintainer, but I couldn't find the one I wanted This one paints part of the picture, but not the whole thing.
The problem is that the Flash spec is very incomplete. It doesn't specify how errors should be handled, and, while it does specify what Adobe *wanted* the official Flash player to do, the official Flash player has tons of subtle bugs, many of which lots of real-world Flash apps depend on to function properly. So implementing the Flash spec isn't enough to run anything but trivial Flash apps. After you implement the spec, then you have to guess how various errors are handled, and compare it to how the official player does it. Then you have to figure out all the places where the official player deviates from the spec, and effectively make your player buggy. And then you have to take behavior that's specified as being undefined by the spec, and implement it in the exact same "undefined" way that the official player does. Unfortunately, they only way to find most of these things is to throw a *lot* of flash files at your player and then painstakingly debug to figure out why they don't work.
It's a mess, and of course Flash is a moving target, which doesn't help matters.
Except that they don't. A CS degree doesn't say squat about your ability to develop good software. It does say that you probably have a clue about at least one programming language, and *probably* know a fair bit about algorithms, data structures, and computing theory, but that may or may not be relevant to a particular "software development" position. And all that's completely ignoring the huge variety in the quality of education you'll get at various colleges and universities.
Besides, if I'm not mistaken, state programs like electrician licensing have mandatory renewal and re-testing. It's one thing to have gone through a recent, up-to-date licensing program, and another to have completed a BS in CS 15 years ago.
Not to mention the fact that a state licensing program is strictly tailored for performing a particular job. A college degree need not have anything to do with job skills.
How is this so hard to understand
It's not hard to understand, I just don't read code that way. Error handling is not a part of "what the function does." Error handling deals with exceptional conditions that you usually hope/assume won't happen, but of course the error handling needs to be there to catch the 0.2% of the time when they do.
So "what the function does" is all the statements that have nothing to do with error handling. In the "correct" case, the function is linear: in most cases you will just execute from top to bottom, and it's done. Reading someone else's code, it'll be clearer to me much faster what is going on without the nested "if pyramid" mess.
But hey, dif'rent strokes for dif'rent folks. That's why everyone has their own coding style.
Heh, I assume you mean "while(0)" ...
While the goto in this case does usually end up resulting in an "only one return" (or two, depending on how it's implemented), the purpose of it is to avoid copy and paste for a lot of cleanup code. Without goto, if you do multiple returns, you end up with something like:
/* keep going... */
if(do_something(bar)) {
free_bar(bar);
return -1;
}
if(do_something_else(bar)) {
free_bar(bar);
return -1;
}
If you have more than just one thing to clean up, or different things depending on how far you made it into the function before encountering an error, it gets worse. And if you later add code to the middle of the function that *also* needs cleanup code on errors, then you end up copy and pasting the existing error code, and then adding an extra cleanup line to all the extra error conditions below it.
With a simple goto on error, you can put all of your cleanup code in one place in the function, and only have a single copy of it. Not only does this make it clearer what the code above it does (the error handling, while necessary, only serves to obscure the real purpose of the code), but it's a lot more maintainable and easier to extend.
You could also achieve something similar with a series of nested if statements, such as:
if(do_something(bar) == 0) {
if(do_something_else(bar) == 0) {
}
}
... with the error handling code after each if block, but that quickly becomes unwieldy if you have more than 5 or so operations, as you end up 6 or more indentation levels deep. I use 4-space indentation, but I know people who like 8, which makes the problem occur twice as fast. Even ignoring the indentation issues, personally I find the "if pyramid" less readable than goto-based error handling.
Hopefully not, seeing as the "=" there will likely net you a syntax error when you try to use your preprocessor symbol in the program. (Unless you're doing something retarded, anyway.)
That would be a little more difficult here. Not only is the US orders of magnitude larger than the UK, but I doubt Dish or DirecTV have the resources to police the entire country. Not to mention they don't know how you're getting your signal. If you put your dish in your back yard and an eavesdropping Dish Network truck drives by, how do they know what you're watching, even assuming they can hear your TV (unlikely)? Maybe you're using cable. Maybe you're using free OTA broadcast. Maybe you're using one of their competitors. No way for them to know.
But what you have to remember is that they are the ones to decide what the prices are. If their prices is what it takes to do business, then that's what they'll charge.
Of course. I just happen to think their pricing model is flawed, and their "fix" for their piracy problem will cause them more problems than it solves. Only time will tell how it'll play out.
You have totally missed it. Linux Game Publishin publishes games. The companies you name are developers who happen to make the majority of their money on all platformas other than Linux. Maybe you should listen to what the developers actually think.
Heh, I don't particularly care that much.
If they can't then they will go bankrupt. But if they believe that DRM will help them, it's their right to use it.
Sure it is. My guess is that it won't work well for them. It'll probably reduce their piracy rate, but I doubt it'll increase sales. If anything, it'll probably decrease sales.
Windows users aren't particularly thrilled about DRM these days. How crazy does LGP have to be to think that all their current Linux users -- and a significant portion of their Linux pirates -- will swallow DRM?
But, again, only time will tell.
Ugh, more bad analogies.
I'm arguing that a software integrator need not be involved in the development of every piece of software they ship. I'm certainly not denying that the kernel needs work, but I think it's perfectly reasonable if Canonical decides they don't want to retain kernel expertise on their payroll. It's a business decision, like any other, and it doesn't seem to have been hurting them.
How is that ignorant? The BM organizers have set up a closed environment where they are nominally in control of photography and videography. Of course their control is not perfect, but it appears to be "good enough" to satisfy a lot of people.
So? They contribute to GNOME and to other software they use. Why is it required/expected that a company contribute to every single open source project whose software they use?
Except that's not true, at least on the surface. Settings -> Privacy -> Applications, Settings tab:
"You can use the controls on this page to limit what types of information your friends can see about you through applications. Please note that this is only for applications you do not use yourself:"
And there's a list of about 20 checkboxes that allow you to restrict what applications *that your friends add* can see about you. Whether or not it actually works is up for question, of course.
Now, annoyingly, any app *you* add yourself gets access to all of your information, regardless of your privacy settings ("When you authorize an application, it can access any information associated with your account that it requires to work"). It would be nice to be able to semi-sandbox apps you add as well. (It does say that they never share contact information through the app platform, which is nice.)
I remember when the app platform was new, you were prompted about the specific types of information the app required and could optionally use, and you could uncheck the optional ones you didn't want to share. The required ones were set in stone, but you'd at least know at that point what would be shared and could make a better decision to allow or deny. A shame that feature is gone.
Actually, scratch that. The Applications privacy settings page specifically is for your info that applications are allowed to see when a friend adds it. So it turns out I'm wrong. Unfortunately, there's *no* way to limit what applications that you add are allowed to see -- they're supposed to abide by your privacy settings, but that isn't enforced by any technical measures. In fact, it explicitly says: "When you authorize an application, it can access any information associated with your account that it requires to work." The "that it requires to work bit" is a bit misleading, because the apps get to self-define what they require. There aren't any measures in place to limit this.
No, the ACLU app says exactly what you said, and it *shows* you the information from your friends' profiles that it can see.
But that's the problem. When I set, say, the privacy setting for my birth date to "friends only," I expect my friends to be able to see my birth date, and no one else. This does not include the developers of an application that my friend installed.
This is even more confusing because each user has privacy settings for applications too. It's not clear to the average user that those settings only apply to what *you* share with applications that *you* add. If you've hidden your birth date from applications, then *your* addition of an app won't leak your birth date to that app, but if one of your friends (who can see your birth date) adds that same app, then the app can get your birth date through that connection.
I picked a mundane piece of information (birth date) as an example, but this becomes more of a problem when you think about home address or phone number.
What price they charge doesn't really matter.
Clearly you have no grasp of economics. If the CEO is correct in that for every sale they make, there are 3-4 pirated copies, they should look into figuring out *why* there are pirated copies. Sure, there will be a subset of people who will just never pay for anything and will only ever pirate software. But surely a percentage of those people would pay if the price was more reasonable. If they cut prices by 25% and that decreases the piracy ratio from 4:1 to 3:1, they make more money than they did before. Obviously my numbers are fabricated, but, as another poster has mentioned, Frictional and Introversion seem to get by ok without DRM with more reasonable prices. It's LGP's own damned fault if they can't price their products appropriately for their market.
You're completely ignoring platform integration issues. Creating, testing, and maintaining a self-extracting installer for win32, .app bundle and .dmg for mac, .deb/.rpm/.tgz for linux is non-trivial and can take up a bunch of time... and that's just one aspect of platform integration
Hell, even ignoring that, adding testing and tech support for the app itself on a new platform isn't free. A company considering a port to another platform certainly has to consider that aspect as well.