That's the point though: they disallowed MS from using that model -- so that can't be a factor in OEMs decisions regarding non-Windows OSes or no OSes on their laptops.
Because, of course, MS would NEVER ignore the law. (except when they do)
On this point, if we accept MS is guilty of nefarious licensing terms, then the
No, it's more like when people rack up multiple related convictions around the world you get the idea they may not be perfectly trustworthy. It's not like I'm advocating skipping due process.
If the conversation has devolved to this, there's probably no point in continuing it.
There's also a built-in assumption here, that the z% will want Windows -- but it's not a stretch -- not everyone has a nerd at hand to install Linux and configure it to make it work for them.
And now you have just made the assumption that OEMs would not configure Linux for their own machines like they do with Windows. Assuming that they handled installation and hardware support as usual, people might possibly prefer Linux over Windows. Too bad we will never know.
That's an excellent point, but it actually applies to the x% population that wants Linux, and the installation and hardware support adds to the cost of providing that option. Also note that with current adoption levels, that cost gets distributed across significantly fewer customers than the same costs for Windows.
The z% population is assumed to not know what they want, and to be ill-equipped to make a choice.
That solution inconveniences the x% folks (who want windows) and z% folks (who now have to make a choice that they are ill equipped to make) and costs them more as well. The OEMs choosing the model they have, suggests that x% and z% outnumber y% by a good margin.
The DOJ and EU have both slapped MS's wrists for doing exactly that in the past. It's a matter of public record.
That's the point though: they disallowed MS from using that model -- so that can't be a factor in OEMs decisions regarding non-Windows OSes or no OSes on their laptops.
Given the history of MS as a habitual offender, I don't think it's at all unlikely that they would pay both lip service while just obfuscating their behavior rather than actually reforming.
On this point, if we accept MS is guilty of nefarious licensing terms, then the count of guilty offenses gets incremented, adding to their repeat offender status, which in turn means the next accusation must also be true based on repeat offender status, and so on and so forth, ad-infinitum. There should be a higher standard for these conversations.
As for the refunds, that's also publicly known from Windows refund day and other efforts to make them actually live up to the terms of their own EULA. Google Windows EULA refund and see for yourself. You'll see how people did get refunds but only after hours on the phone over a period of months or actually going to small claims court.
I'm not even debating this.. as stated in TFA people have even gone to court over this now, so *something* is definitely wrong here. As I stated earlier, if the court finds foul play, MS and/or the OEMs will (and should) be made to pay for it. I'm merely saying that your statement about their licensing terms doesn't stand to reason.
...will be just fine with Windows, and never know what they are missing or that there is a life outside of Microsoft's corporate clutches.
The concerted spread of a pro-Linux/free OS message could help counteract this.
Nobody cares outside of this community -- they simply don't care. And why should they? In your very words -- the vast majority of "average" computer users without specific computing needs (programming, design, etc.) will be just fine with Windows -- so what problem does this solve for them? The community's objective might be to spread Linux -- but if it doesn't solve some issue for the lay user, how does it make sense to expect them to care about this cause?
The answer is to ACTUALLY provide the refunded license cost...
No arguments from me on that score -- you stated that non-Windows machines cost more because of Windows licensing terms, which/. seems happy to accept as a fact, but I don't see why it's so readily accepted. The Italian courts will surely penalize MS and/or the OEMs (and rightly so) if they are indeed unfairly not refunding license fees.
MS is doint things like telling them to install Windows on 100% of their machines or the price per machine doubles
The US DOJ disallows this, and I *think* the EU does as well. Please correct me if I'm wrong.
The fact that buying a bare laptop is more expensive is a nasty side-effect of MS's licensing arrangements with OEMs.
There are some unstated assumptions in that statement. I don't know what the real numbers are, but here are some thoughts:
Suppose OEMs did offer a simple checkbox for wheter you want Windows pre-installed:
1. Some % of people buying laptops want Windows on it -- let's say x% 2. Some % of people buying laptops don't want Windows on it -- let's say y% 3. Some % of people buying laptops have no clue and will go with whatever is cheapest (i.e. will exclude windows w/o realizing what they're doing, if it was offered as an option by the OEM) -- z%
For x%, the economics remain mostly unchanged. For y% the economics improve due to no Windows OEM price. For z% the purchase just got quite painful because they saved the OEM price, but now they need an OS, and they are no longer eligible for OEM pricing. Worse -- they get angry at the OEM that sold them a useless machine, and vow never to do business with them, and they spend a lot of time (i.e. spend a lot of OEM's money) on the phone with support trying to figure out what the hell is going on.
The final economics for the OEM depends on the exact percentages of x%, y% and z%, and the final number for how much z% costs them in support calls, alienated customers (future sales), etc. Of course, you also need to factor in the same thing for the y% folks.
There's also a built-in assumption here, that the z% will want Windows -- but it's not a stretch -- not everyone has a nerd at hand to install Linux and configure it to make it work for them.
I don't know the answers to these questions -- but I do question the veracity of the statement that MS's licensing arrangements make purchasing an OS-less laptop more expensive. I think if this wasn't slashdot, an assertion like that would need more substantiation. I suspect that OEMs would offer whichever options give them the best combination of customer satisfaction, and profit margins. The checkbox to purchase w/o Windows being absent certainly does mean that it costs more for them to give us that option -- on this we agree. But the actual cause of that cost is what I am questioning here.
Spot on. The age data point is merely incidental -- swap the knowledge/skillsets between them, and you'll swap the salaries as well. Whatever industry a person might work in, it's up to them to observe trends, understand their impact on demand/supply for their skills, and update their skills to get the demand/supply equation to work in their favor.
I don't know about consumer sites, but regarding slashdot let me paint you a picture:
Consider if you will, Fox News. They have a clear tilt. Their viewership is skewed based on that tilt. To maintain their viewership they have to maintain or increase their tilt. It's a closed, positive feedback loop. Fox can't change its tilt. Substitute, say, Huffington Post in place of Fox and you get the same result.
Slashdot works a little differently -- but it's the same result. More potent in fact, because the feedback loop is much more immediate and direct.
Example of said tilt -- barely anyone in this thread has anything to say about the issue mentioned in TFA. Not one single piece of insight, or information. Nada. The only discussion is about how bad MS is, and how bad they've been, and how they will continue to be bad, etc. Why even have a topic if that's the case? Why not just have a weekly "discuss how MS sucks" thread? At least that would be honest.
Another example of said tilt -- any thread involving DRM.
Also -- any comment by Miguel De Icaza.
Slashdot has chosen its sides a long time ago. There are voices of dissent or voices of reason from time to time, but they always get drowned out, and suppressed (modded down) by the groupthinkers/lemmings.
So finally, coming back to your question:
And they don't even bother with Slashdot or any consumer site that says their product is crap?
Why would anyone who is disliked by slashdot bother to read it then? What insight can they gain from it? What will they come away with, other than the opinion that they cannot get any useful criticism from this site, and they cannot ever 'win' over this crowd, so why even try?
I don't believe, I have to explain those things to someone who supposedly understands what strcpy() is. No wonder, there is shit code everywhere.
Listen child - first of all, you keep referencing strncat/strncpy as if it's your only (so-called) safe string function available. Search harder son. The issue you called out, is the reason strncpy is a terrible example of a safe-string function -- but apparently you stopped there and came to a prematue conclusing instead of researching the issue the end, and you also decided you're a superprogrammer with all the answers. I'll leave the discovery of 'safer' functions to you as an exercise, mostly because the answer is platform dependant. Sometimes you might actually not have something better than strncat, so you end up having to roll your own. I'll leave the exact nature of the 'roll your own' function to you as an exercise as well, because in the process of figuring out what it should look like (or if you research a little and emulate something better than strncpy) you'll become a better coder.
This could have been a cordial conversation. Informative even. But you chose to be an asshole/internet tough guy. Do yourself a favor and research the topic a little. You have a glaring hole in your knowledge here, and I guarantee you within about 2 hours of reading you'll understand just how bad it is.
On the other hand, calculating the size of the buffer when it is being allocated, or some when large, possibly complex, but predictable operation is started -- so it will not be possible for you to be wrong again -- is one calculation. Once you have passed this hurdle, you can be safe that your subsequent parts of this operation will not be able to overrun this buffer.
Just to give you a hint along your research -- you're thinking along the right lines here. You merely need to expand on this thought a little, and you can come up with a 'safer' string function that takes advantage of this known-to-be-corret buffer size.
quote>strncat(), when applied to unexpectedly long string, unpredictably alters the data the program processes. Formally, that's just as insecure as running arbitrary code
How so??
This captures the essence of our disagreement.
Altering data by inadvertently truncating a string is bad, and buggy -- absolutely -- you gotta do the work to validate your data beforehand to that doesn't happen. Absolutely. You're saying constantly pay attention, etc. etc. -- here's where you do that. Validate your data when it crosses trust boundaries, and use the right string functions, that *tell* you when your buffer was too small and your data got truncated, and handle that correctly in your code. I don't quite understand why everyone points out strncat() at the drop of a hat as if that's your only so-called safe option (it isn't, and it's only a slight improvement on straight up strcat).
That's true actually.. the automated stuff should just be part of your post-build process, the guy writing the code gets immediate feedback on completing a build and fixes that crap before asking for a peer review.
You still need to run a build (and post-build verification) as part of a code review, to account for differences (if any) between your dev environments. Ideally there should not be any, but we know how that works. The most time-efficient way (on big projects) is to kick of the build so it can do it's thing, and then the post-build tools can do their thing, while you're reading code.
If those are unsafe, then dereferencing a pointer or using an array is unsafe, too -- and that means, a programmer is unable to write safe code no matter what.
You are just being stubborn for the sake of being stubborn. It's not about being unable to do your own buffer calculations. It's about using the tools available to you, to reduce the risk of making mistakes.
People do manage to make asses of themselves even with so-called 'safe' string APIs, but there's no good reason to not use them.
What?
The only kind of "safe" strings handling that I am aware of, is operations on strings that are combined with allocation (in object-oriented or almost-object-oriented way). Their purpose is to simplify common operations, any "safety" is at best a side effect that shouldn't matter if programmer is not a moron in the first place.
Hence the words "so-called"...
Strcpy()
strcpy()
Case-sensitive names should be written as they are defined, no matter where they are in a sentence.
What kind of pedantic asshole insists on capitalization on a message board, but refuses to see the basic sense in using functions that give you a little help?
or strcat() have pitfalls that are really esoteric, and if you keep using them you'll eventually make a mistake and end up with some absolute motherfucker of a bug with security ramifications you wouldn't even have imagined.
I repeat -- if you can mess up strcpy(), you can mess up anything, and should not be allowed to write any code to begin with. It does not matter how many opportunities you are given to jump in front of a bus or a train -- what is important is that you should not do it.
Get off your high-horse. Even the most elite programmers make mistakes.
I often deliberately choose a string manipulation that involves strcpy() and even strcat(), just to make a point that those are perfectly valid and useful functions, despite some morons writing insecure code with them.
The only really unsafe function is gets().
That's just stubbornness for it's own sake. These are violently unsafe functions. People do manage to make asses of themselves even with so-called 'safe' string APIs, but there's no good reason to not use them. Strcpy() or strcat() have pitfalls that are really esoteric, and if you keep using them you'll eventually make a mistake and end up with some absolute motherfucker of a bug with security ramifications you wouldn't even have imagined.
#1 - If you are a programmer, BE A PROGRAMMER and manage the pointers and memory allocations yourself. Garbage collection is for little boys. Men deal with it on their own with techniques that work and are efficient.
So mega-strongly disagree dude. Not saying you shouldn't do heavy lifting when necessary -- just that you should only do it when necessary. Don't re-invent the wheel every time. Frameworks exist that do work for you for a reason. Chose your frameworks well, understand them in depth, and you can do good things. If you "start from the first principles" every time, you end up with a humongous fucking surface of new code -- which is bound to have a nasty bug or three. It comes down to choosing the best tools for the job.
#2 - Initialize all variables to known values. int i; doesn't cut it. int i=0; does.
True dat. Lots security pitfalls here too -- not just garden variety bugs.
#3 - Use descriptive variable names
So true. Corollary to that: because a variable name is descriptive, don't make wanton assumptions about it.
#4 - you shouldn't be allowed to program anything new until you've been a maintenance programmer for a few years and seen the crap code that others puke into the world. Your crap code stinks too, BTW.
I'd modify this to say "always, always, always have a peer-review process". Junior devs are prevented from checking in crap because it gets caught by senior devs. The junior devs also learn quality habits from reviewing senior devs' code. Multiple reviewers is always a good thing. Review your design among the entire team before anyone writes a single line of code. Remember to keep security in mind when reviewing code. Use static analyzers when you're done with the "human" aspect of the review. Apply every imaginable quality bar to your code, and only check it in once it has passed scrutiny.
Dig a little deeper. I know this because I followed the whole thing incredibly closely and I remember my anger at Jobs when he appropriated the DRM-free movement without so much as even a nod towards the people that had been fighting for this for so long.
I don't have a problem with Apple. I do have a problem with Steve Jobs, primarily because I think he's deceitful. I don't understand why saying something unfavorable means that I hate Apple, and from your reaction it really looks like you idolize them (or Jobs, or both). No company is worth that. But as I said, to each their own.
Your original post said something about us being thankful to Apple, which made me puke a little because Apple in no way led the movement, they merely used it to escape regulatory scrutiny in Europe, the timing was brilliant for them, and as usual their PR was masterful. They did good by offering us the privilege to buy non-DRMed tracks for 30 cents extra. But thank them??? Hell fucking no.
Anyway.. I'm breaking my own rules now.. threads like this rarely result in anyone changing their mind, and I hate becoming a caricature of the internet tough guy meme.. I hope I have the strength to not respond to the next message on this thread.
DRM harms the legitimate consumer to some extent, (restricting fair use, reducing platform compatibility, preventing resale, and so forth) thus there should be a good argument for its implementation.
This is often true, but its not a given. In Netflix's case you can't claim fair use has been restricted. And the catalog being available at all, is because of it being protected (otherwise, the studios would simply not license it to netflix) -- the platform compatibility comes a pretty distant second when the alternative is to not have a business at all.
The content is on the torrent sites already, taken from the DVDs or blu-rays. If there's already at least one bit-perfect DRM free copy circulating, what possible difference can it make how many more are made?
Many reasons. You can actually remove pirated copies from circulation (essentially going after the torrent sites, going after the downloaders and uploaders, etc. etc. to the point where pirating stuff is risky enough that nobody does it -- or to stick to the same point as DRM -- where you reduce piracy to the point where the 'lost sales minimized' recoup the money you spent on prosecuting people). Another reason -- bittorrent + codec hell + virus/trojan risks + watching a movie on a computer monitor or using shitty upscaling to TVs is already a fairly convoluted way to get content, compared to legit options. The more you keep working away at reducing the options for pirates, the more inconvenient the piracy options become.
Despite what you may think, I don't support copyright infringement
Acknowledged. I know -- we're just having a conversation -- I certainly don't automatically assume everyone who disagrees with me is a freeloader, and I often have to fight the perception that I am pro-DRM -- the labels aren't helpful because it assumes that people on each side don't see the shades of grey -- I'm sure we both do.
I just vehemently oppose what the industry is doing to harm me, a legitimate consumer, in the name of preventing copyright infringement.
But that's the thing -- they can never harm you. They can harm a lot of people who don't know better, but nobody on this site can claim that. We know how DRM works, we know what our rights are, and we know which DRM systems trample on them, and which ones don't etc. We know everything we need to, to make educated decisions, and to not buy media that's encumbered in DRM that will hurt us, and to not oppose media that uses DRM that does not -- or at least we should. The blanket opposition, even in cases where it does not hurt, hurts the credibility of the larger cause.
I have yet to see a convincing argument (or any argument at all, for that matter) for why anybody would rip a Netflix stream from their paid subscription rather than renting & ripping a DVD/BD or (far more likely) downloading a torrent from someone who's already done so.
Why do you even need an argument for that? Just because you have one content delivery mechanism that's easy to pirate, you should just give up on securing your content and allow the pirates to fuck you over? Hell no -- secure what you can, and prosecute the ones that pirate anyway.
It stops you from becoming a customer -- yes. But the catalog that is available for streaming, is available because it's DRM-protected. Without DRM, the studios would not have agreed to make it available. Because the content is available, Netflix has a business.
So they lose customers in your situation, but they gain everyone else. Easy trade-off. Note that there's no good reason that there can't be a DRMed streaming solution on Linux as well. It probably won't be open source -- but that doesn't mean it can't be done. It's probably just a function of demand -- how many Linux-only users there are (so revenue to be generated from them) vs. the cost of creating a linux netflix solution.
Apple had been asking for some time to be able to do so before Amazon ever started, and EMI finally caved with the others following shortly.
I'm afraid you're the revisionist. EMI announced that they will make their catalog available w/o DRM before Job's open letter. Job's letter came well after Amazon had launched and enjoyed some success, after EMI's announcement, and right after iTunes + FairPlay came under regulatory scrutiny in Europe.
Not interested in getting into a conversation about it.. believe what you will.. to each their own.
Slashdot Mirror
This would be relevant if Nokia were moving to Windows Mobile.
That's the point though: they disallowed MS from using that model -- so that can't be a factor in OEMs decisions regarding non-Windows OSes or no OSes on their laptops.
Because, of course, MS would NEVER ignore the law. (except when they do)
On this point, if we accept MS is guilty of nefarious licensing terms, then the
No, it's more like when people rack up multiple related convictions around the world you get the idea they may not be perfectly trustworthy. It's not like I'm advocating skipping due process.
If the conversation has devolved to this, there's probably no point in continuing it.
There's also a built-in assumption here, that the z% will want Windows -- but it's not a stretch -- not everyone has a nerd at hand to install Linux and configure it to make it work for them.
And now you have just made the assumption that OEMs would not configure Linux for their own machines like they do with Windows. Assuming that they handled installation and hardware support as usual, people might possibly prefer Linux over Windows. Too bad we will never know.
That's an excellent point, but it actually applies to the x% population that wants Linux, and the installation and hardware support adds to the cost of providing that option. Also note that with current adoption levels, that cost gets distributed across significantly fewer customers than the same costs for Windows.
The z% population is assumed to not know what they want, and to be ill-equipped to make a choice.
It's not the case now, so it cannot be a factor in the current pricing models.
That solution inconveniences the x% folks (who want windows) and z% folks (who now have to make a choice that they are ill equipped to make) and costs them more as well. The OEMs choosing the model they have, suggests that x% and z% outnumber y% by a good margin.
The DOJ and EU have both slapped MS's wrists for doing exactly that in the past. It's a matter of public record.
That's the point though: they disallowed MS from using that model -- so that can't be a factor in OEMs decisions regarding non-Windows OSes or no OSes on their laptops.
Given the history of MS as a habitual offender, I don't think it's at all unlikely that they would pay both lip service while just obfuscating their behavior rather than actually reforming.
On this point, if we accept MS is guilty of nefarious licensing terms, then the count of guilty offenses gets incremented, adding to their repeat offender status, which in turn means the next accusation must also be true based on repeat offender status, and so on and so forth, ad-infinitum. There should be a higher standard for these conversations.
As for the refunds, that's also publicly known from Windows refund day and other efforts to make them actually live up to the terms of their own EULA. Google Windows EULA refund and see for yourself. You'll see how people did get refunds but only after hours on the phone over a period of months or actually going to small claims court.
I'm not even debating this.. as stated in TFA people have even gone to court over this now, so *something* is definitely wrong here. As I stated earlier, if the court finds foul play, MS and/or the OEMs will (and should) be made to pay for it. I'm merely saying that your statement about their licensing terms doesn't stand to reason.
But that suggestion only accounts for the z% people. What about the x% folks?
...will be just fine with Windows, and never know what they are missing or that there is a life outside of Microsoft's corporate clutches.
The concerted spread of a pro-Linux/free OS message could help counteract this.
Nobody cares outside of this community -- they simply don't care. And why should they? In your very words -- the vast majority of "average" computer users without specific computing needs (programming, design, etc.) will be just fine with Windows -- so what problem does this solve for them? The community's objective might be to spread Linux -- but if it doesn't solve some issue for the lay user, how does it make sense to expect them to care about this cause?
The answer is to ACTUALLY provide the refunded license cost...
No arguments from me on that score -- you stated that non-Windows machines cost more because of Windows licensing terms, which /. seems happy to accept as a fact, but I don't see why it's so readily accepted. The Italian courts will surely penalize MS and/or the OEMs (and rightly so) if they are indeed unfairly not refunding license fees.
MS is doint things like telling them to install Windows on 100% of their machines or the price per machine doubles
The US DOJ disallows this, and I *think* the EU does as well. Please correct me if I'm wrong.
Odds are, if your brother knows what Linux is, then he knows what Windows is, so he does not fall into z%.
The fact that buying a bare laptop is more expensive is a nasty side-effect of MS's licensing arrangements with OEMs.
There are some unstated assumptions in that statement. I don't know what the real numbers are, but here are some thoughts:
Suppose OEMs did offer a simple checkbox for wheter you want Windows pre-installed:
1. Some % of people buying laptops want Windows on it -- let's say x%
2. Some % of people buying laptops don't want Windows on it -- let's say y%
3. Some % of people buying laptops have no clue and will go with whatever is cheapest (i.e. will exclude windows w/o realizing what they're doing, if it was offered as an option by the OEM) -- z%
For x%, the economics remain mostly unchanged. For y% the economics improve due to no Windows OEM price. For z% the purchase just got quite painful because they saved the OEM price, but now they need an OS, and they are no longer eligible for OEM pricing. Worse -- they get angry at the OEM that sold them a useless machine, and vow never to do business with them, and they spend a lot of time (i.e. spend a lot of OEM's money) on the phone with support trying to figure out what the hell is going on.
The final economics for the OEM depends on the exact percentages of x%, y% and z%, and the final number for how much z% costs them in support calls, alienated customers (future sales), etc. Of course, you also need to factor in the same thing for the y% folks.
There's also a built-in assumption here, that the z% will want Windows -- but it's not a stretch -- not everyone has a nerd at hand to install Linux and configure it to make it work for them.
I don't know the answers to these questions -- but I do question the veracity of the statement that MS's licensing arrangements make purchasing an OS-less laptop more expensive. I think if this wasn't slashdot, an assertion like that would need more substantiation. I suspect that OEMs would offer whichever options give them the best combination of customer satisfaction, and profit margins. The checkbox to purchase w/o Windows being absent certainly does mean that it costs more for them to give us that option -- on this we agree. But the actual cause of that cost is what I am questioning here.
And you get modded a troll for your efforts.. group think re-reinforces itself again -- death to those who think different!
Spot on. The age data point is merely incidental -- swap the knowledge/skillsets between them, and you'll swap the salaries as well. Whatever industry a person might work in, it's up to them to observe trends, understand their impact on demand/supply for their skills, and update their skills to get the demand/supply equation to work in their favor.
I don't know about consumer sites, but regarding slashdot let me paint you a picture:
Consider if you will, Fox News. They have a clear tilt. Their viewership is skewed based on that tilt. To maintain their viewership they have to maintain or increase their tilt. It's a closed, positive feedback loop. Fox can't change its tilt. Substitute, say, Huffington Post in place of Fox and you get the same result.
Slashdot works a little differently -- but it's the same result. More potent in fact, because the feedback loop is much more immediate and direct.
Example of said tilt -- barely anyone in this thread has anything to say about the issue mentioned in TFA. Not one single piece of insight, or information. Nada. The only discussion is about how bad MS is, and how bad they've been, and how they will continue to be bad, etc. Why even have a topic if that's the case? Why not just have a weekly "discuss how MS sucks" thread? At least that would be honest.
Another example of said tilt -- any thread involving DRM.
Also -- any comment by Miguel De Icaza.
Slashdot has chosen its sides a long time ago. There are voices of dissent or voices of reason from time to time, but they always get drowned out, and suppressed (modded down) by the groupthinkers/lemmings.
So finally, coming back to your question:
And they don't even bother with Slashdot or any consumer site that says their product is crap?
Why would anyone who is disliked by slashdot bother to read it then? What insight can they gain from it? What will they come away with, other than the opinion that they cannot get any useful criticism from this site, and they cannot ever 'win' over this crowd, so why even try?
This captures the essence of our disagreement.
No, it does not.
Sure, whatever, tough guy..
I don't believe, I have to explain those things to someone who supposedly understands what strcpy() is. No wonder, there is shit code everywhere.
Listen child - first of all, you keep referencing strncat/strncpy as if it's your only (so-called) safe string function available. Search harder son. The issue you called out, is the reason strncpy is a terrible example of a safe-string function -- but apparently you stopped there and came to a prematue conclusing instead of researching the issue the end, and you also decided you're a superprogrammer with all the answers. I'll leave the discovery of 'safer' functions to you as an exercise, mostly because the answer is platform dependant. Sometimes you might actually not have something better than strncat, so you end up having to roll your own. I'll leave the exact nature of the 'roll your own' function to you as an exercise as well, because in the process of figuring out what it should look like (or if you research a little and emulate something better than strncpy) you'll become a better coder.
This could have been a cordial conversation. Informative even. But you chose to be an asshole/internet tough guy. Do yourself a favor and research the topic a little. You have a glaring hole in your knowledge here, and I guarantee you within about 2 hours of reading you'll understand just how bad it is.
On the other hand, calculating the size of the buffer when it is being allocated, or some when large, possibly complex, but predictable operation is started -- so it will not be possible for you to be wrong again -- is one calculation. Once you have passed this hurdle, you can be safe that your subsequent parts of this operation will not be able to overrun this buffer.
Just to give you a hint along your research -- you're thinking along the right lines here. You merely need to expand on this thought a little, and you can come up with a 'safer' string function that takes advantage of this known-to-be-corret buffer size.
Next time, check your fucking ego at the door.
quote>strncat(), when applied to unexpectedly long string, unpredictably alters the data the program processes. Formally, that's just as insecure as running arbitrary code
How so??
This captures the essence of our disagreement.
Altering data by inadvertently truncating a string is bad, and buggy -- absolutely -- you gotta do the work to validate your data beforehand to that doesn't happen. Absolutely. You're saying constantly pay attention, etc. etc. -- here's where you do that. Validate your data when it crosses trust boundaries, and use the right string functions, that *tell* you when your buffer was too small and your data got truncated, and handle that correctly in your code. I don't quite understand why everyone points out strncat() at the drop of a hat as if that's your only so-called safe option (it isn't, and it's only a slight improvement on straight up strcat).
That's true actually.. the automated stuff should just be part of your post-build process, the guy writing the code gets immediate feedback on completing a build and fixes that crap before asking for a peer review.
You still need to run a build (and post-build verification) as part of a code review, to account for differences (if any) between your dev environments. Ideally there should not be any, but we know how that works. The most time-efficient way (on big projects) is to kick of the build so it can do it's thing, and then the post-build tools can do their thing, while you're reading code.
These are violently unsafe functions.
If those are unsafe, then dereferencing a pointer or using an array is unsafe, too -- and that means, a programmer is unable to write safe code no matter what.
You are just being stubborn for the sake of being stubborn. It's not about being unable to do your own buffer calculations. It's about using the tools available to you, to reduce the risk of making mistakes.
People do manage to make asses of themselves even with so-called 'safe' string APIs, but there's no good reason to not use them.
What?
The only kind of "safe" strings handling that I am aware of, is operations on strings that are combined with allocation (in object-oriented or almost-object-oriented way). Their purpose is to simplify common operations, any "safety" is at best a side effect that shouldn't matter if programmer is not a moron in the first place.
Hence the words "so-called"...
Strcpy()
strcpy()
Case-sensitive names should be written as they are defined, no matter where they are in a sentence.
What kind of pedantic asshole insists on capitalization on a message board, but refuses to see the basic sense in using functions that give you a little help?
or strcat() have pitfalls that are really esoteric, and if you keep using them you'll eventually make a mistake and end up with some absolute motherfucker of a bug with security ramifications you wouldn't even have imagined.
I repeat -- if you can mess up strcpy(), you can mess up anything, and should not be allowed to write any code to begin with. It does not matter how many opportunities you are given to jump in front of a bus or a train -- what is important is that you should not do it.
Get off your high-horse. Even the most elite programmers make mistakes.
I often deliberately choose a string manipulation that involves strcpy() and even strcat(), just to make a point that those are perfectly valid and useful functions, despite some morons writing insecure code with them.
The only really unsafe function is gets().
That's just stubbornness for it's own sake. These are violently unsafe functions. People do manage to make asses of themselves even with so-called 'safe' string APIs, but there's no good reason to not use them. Strcpy() or strcat() have pitfalls that are really esoteric, and if you keep using them you'll eventually make a mistake and end up with some absolute motherfucker of a bug with security ramifications you wouldn't even have imagined.
#1 - If you are a programmer, BE A PROGRAMMER and manage the pointers and memory allocations yourself. Garbage collection is for little boys. Men deal with it on their own with techniques that work and are efficient.
So mega-strongly disagree dude. Not saying you shouldn't do heavy lifting when necessary -- just that you should only do it when necessary. Don't re-invent the wheel every time. Frameworks exist that do work for you for a reason. Chose your frameworks well, understand them in depth, and you can do good things. If you "start from the first principles" every time, you end up with a humongous fucking surface of new code -- which is bound to have a nasty bug or three. It comes down to choosing the best tools for the job.
#2 - Initialize all variables to known values. int i; doesn't cut it. int i=0; does.
True dat. Lots security pitfalls here too -- not just garden variety bugs.
#3 - Use descriptive variable names
So true. Corollary to that: because a variable name is descriptive, don't make wanton assumptions about it.
#4 - you shouldn't be allowed to program anything new until you've been a maintenance programmer for a few years and seen the crap code that others puke into the world. Your crap code stinks too, BTW.
I'd modify this to say "always, always, always have a peer-review process". Junior devs are prevented from checking in crap because it gets caught by senior devs. The junior devs also learn quality habits from reviewing senior devs' code. Multiple reviewers is always a good thing. Review your design among the entire team before anyone writes a single line of code. Remember to keep security in mind when reviewing code. Use static analyzers when you're done with the "human" aspect of the review. Apply every imaginable quality bar to your code, and only check it in once it has passed scrutiny.
Dig a little deeper. I know this because I followed the whole thing incredibly closely and I remember my anger at Jobs when he appropriated the DRM-free movement without so much as even a nod towards the people that had been fighting for this for so long.
I don't have a problem with Apple. I do have a problem with Steve Jobs, primarily because I think he's deceitful. I don't understand why saying something unfavorable means that I hate Apple, and from your reaction it really looks like you idolize them (or Jobs, or both). No company is worth that. But as I said, to each their own.
Your original post said something about us being thankful to Apple, which made me puke a little because Apple in no way led the movement, they merely used it to escape regulatory scrutiny in Europe, the timing was brilliant for them, and as usual their PR was masterful. They did good by offering us the privilege to buy non-DRMed tracks for 30 cents extra. But thank them??? Hell fucking no.
Anyway.. I'm breaking my own rules now.. threads like this rarely result in anyone changing their mind, and I hate becoming a caricature of the internet tough guy meme.. I hope I have the strength to not respond to the next message on this thread.
DRM harms the legitimate consumer to some extent, (restricting fair use, reducing platform compatibility, preventing resale, and so forth) thus there should be a good argument for its implementation.
This is often true, but its not a given. In Netflix's case you can't claim fair use has been restricted. And the catalog being available at all, is because of it being protected (otherwise, the studios would simply not license it to netflix) -- the platform compatibility comes a pretty distant second when the alternative is to not have a business at all.
The content is on the torrent sites already, taken from the DVDs or blu-rays. If there's already at least one bit-perfect DRM free copy circulating, what possible difference can it make how many more are made?
Many reasons. You can actually remove pirated copies from circulation (essentially going after the torrent sites, going after the downloaders and uploaders, etc. etc. to the point where pirating stuff is risky enough that nobody does it -- or to stick to the same point as DRM -- where you reduce piracy to the point where the 'lost sales minimized' recoup the money you spent on prosecuting people). Another reason -- bittorrent + codec hell + virus/trojan risks + watching a movie on a computer monitor or using shitty upscaling to TVs is already a fairly convoluted way to get content, compared to legit options. The more you keep working away at reducing the options for pirates, the more inconvenient the piracy options become.
Despite what you may think, I don't support copyright infringement
Acknowledged. I know -- we're just having a conversation -- I certainly don't automatically assume everyone who disagrees with me is a freeloader, and I often have to fight the perception that I am pro-DRM -- the labels aren't helpful because it assumes that people on each side don't see the shades of grey -- I'm sure we both do.
I just vehemently oppose what the industry is doing to harm me, a legitimate consumer, in the name of preventing copyright infringement.
But that's the thing -- they can never harm you. They can harm a lot of people who don't know better, but nobody on this site can claim that. We know how DRM works, we know what our rights are, and we know which DRM systems trample on them, and which ones don't etc. We know everything we need to, to make educated decisions, and to not buy media that's encumbered in DRM that will hurt us, and to not oppose media that uses DRM that does not -- or at least we should. The blanket opposition, even in cases where it does not hurt, hurts the credibility of the larger cause.
I have yet to see a convincing argument (or any argument at all, for that matter) for why anybody would rip a Netflix stream from their paid subscription rather than renting & ripping a DVD/BD or (far more likely) downloading a torrent from someone who's already done so.
Why do you even need an argument for that? Just because you have one content delivery mechanism that's easy to pirate, you should just give up on securing your content and allow the pirates to fuck you over? Hell no -- secure what you can, and prosecute the ones that pirate anyway.
It stops you from becoming a customer -- yes. But the catalog that is available for streaming, is available because it's DRM-protected. Without DRM, the studios would not have agreed to make it available. Because the content is available, Netflix has a business.
So they lose customers in your situation, but they gain everyone else. Easy trade-off. Note that there's no good reason that there can't be a DRMed streaming solution on Linux as well. It probably won't be open source -- but that doesn't mean it can't be done. It's probably just a function of demand -- how many Linux-only users there are (so revenue to be generated from them) vs. the cost of creating a linux netflix solution.
Apple had been asking for some time to be able to do so before Amazon ever started, and EMI finally caved with the others following shortly.
I'm afraid you're the revisionist. EMI announced that they will make their catalog available w/o DRM before Job's open letter. Job's letter came well after Amazon had launched and enjoyed some success, after EMI's announcement, and right after iTunes + FairPlay came under regulatory scrutiny in Europe.
Not interested in getting into a conversation about it.. believe what you will.. to each their own.