Your aesthetics, my aesthetics, or any other programmers' aesthetics are just personal opinions, don't need to be justified, and really have no particular value. On the contrary... you need to justify 100% a violation of some sort before code can be considered objectively bad, instead of just "Not how [you] would have gone about writing that, if you had been the person to write it".
As long as the code does exactly what it's supposed to do, and nothing more, and follows
standard programming structure defined by the language and basic stylistic conventions (such as indentation), then the code is not shitty, no matter what my (or your) opinion is about its aesthetics.
P.S. It's not expected to be bug free but to have a much smaller
volume of noticeable bugs than closed-source software release of equivalent age and complexity, after elapse of a bit of time.
Of course more complex closed-source software can be expected to be more buggy, and younger closed-source software can be expected to be more buggy.
The surprising result that is predicted by Linus would be that when unstable/development OSS released first at time X, while at the same time similar unstable/development closed-source is released at time X...
After a duration 'Y' elapses, the OSS software is much more stable after various releases than the closed source software (over the same time period)
Due to the 'many eyes' finding the issues in the OSS software code.
And the closed source nature of the other product resulting in lots of bug reports (potentially), but many unfixed, and in any case, much fewer of the actual bugs addressed than in the OSS software for the same time period and usage patterns.
I'm guessing it's a reference to security features.
Such as "UAC", "File permissions", "Protected mode", "Data execution protection", "Firewall".
Or this new technology MS just came up with and will surely soon be patented.. it's called a "Password", and it's really quite innovative -- it's basically a secret code, and the computer won't let you begin to use it or start a program before typing the secret password.
Well, taken separately, they may be not sufficient.
He's not considering the combination though of:
Auditing, code review, extensive testing playing with and looking at by many people, features, and attack.
Including people searching for vulnerabilities or ways to exploit things, not merely reviewing code.
This type of auditing is outside the vocabulary of a company that deals in closed source software -- but with OSS, it can be expected to be a common thing.
... Code review alone is not sufficient. Testing is not sufficient. Tools are not sufficient. Features are not sufficient. None of the things we do in isolation are sufficient. To get software truly correct, especially to get it secure, you have to address all phases of the software development lifecycle, and integrate security into the day-to-day activities."
What is it you are trying to sell exactly?
Microsoft Secure Development Lifecycle?
"Eyes" on the source code aren't just code reviewers... they also consist of the attackers.
Ok.. attackers have to find vulnerabilities to exploit somehow.
The same techniques used by would-be attackers against the source to find exploitable holes can be used by the community (with source code access as a pre-requisite) to more effectively and with greater number people searching for things they can take advantage of, the more likely any issue is quicky found.
The only way to find faster, would be perhaps for someone to offer a bounty for anyone finding verifiably exploitable privilege escalation or remote exploitable security bugs in a default build of a stock kernel:)
The funny thing is... even addressing "at all phases" of the software development lifecycle and "integrating security into the day-to-day activities" is not enough to be secure.
Observation: This is the closest thing I believe I have seen so far, to an admission, from a Microsoftian, that their software can be inherently insecure (by design).
Seeing as the initial design is one of the most important parts of the software "lifecycle" by some views of the situation.
But the above quotation didn't argue merely AGAINST more eyes.
It argued that essentially you can't make software more secure by looking at it, having code reviewed, and testing it.
That's absurd.
While there can be security weaknesses that won't be detected by thorough testing or code review, very large classes of security weaknesses can be.
Also, the complexity of the software systems interacting comes into play here...
Applications with simple well-controlled interactions and stable API (E.g. not like Windows) are less likely to have security issues that can escape a good code review.
Your argument is basically a fallacy. Without any basis whatsoever, you've magically created some sort of line between a software company's tax rate, and the consumer price of goods.
The consumer price of goods isn't based directly on taxes MS pays though, it's based on what the consumer is willing to pay, and what the demand is for the product. Software publishers charge the highest price the market will bear within their desired sales volume (i.e. number units available) in order to maximize their profit.
The great thing about software is the costs to produce are very very low (on average) per unit, and the profits are extremely high.
But to get those extreme profits, they are already charging as much for it as they felt they could charge, and increased costs do not change the retail price. Only changes in pricing pressure do that.
Here's the thing... since they are taxes they haven't already paid.. charging them now doesn't retroactively increase the price of already-purchased copies of Windows.
Also, due to competitive pressures in the marketplace, Microsoft can't simply raise the prices of their existing products.
They would kill Windows 7 if they decided to raise the OEM price to $300 for Home Premium.
They can't increase the price in the past, so there's only one thing that can give their past profits get reduced.
This reduces the value of their company, and works against developing new products in as cost-effective a way, but it doesn't make the old products more expensive in practice.
Well, copyrights are contained in both.
Neither the useful arts nor the sciences have a monopoly on the benefits from copyright, the constitutional mandate is to promote both, and copyright can promote progress in both.
The product of writing a software program such as a computer operating system is useful art.
Composing a piece of music, a theatrical production, or writing a poem or philosophical piece is science.
I'm not bolding necessarily the most important parts of sentences, only the parts that make my point the most vivid.
Anyways, the point is... the purpose that was most cleanly expressed by the result of the version of the text accepted into the constitution is that it's about progress.
The purpose of copyright is not merely to increase the sheer number of works available to the public.
But to actually promote progress in the arts/sciences.
If more works does that, then great.
But it's not automatically true that fewer works doesn't do that, or that fewer works means copyright has "failed"
That depends. Accessing individual paper records through old printouts is inefficient though, the info is outdated -- you can probably get that generally, via dumpster diving anyways.
But for students a likely goal is to change personal records, or more specifically... to alter personal grading records.
I would also guess...
There were also few/no viruses.
And hacking was kind of pointless, since
there was no security to hack.
But a skill barrier, since knowledge of such equipment was not generally publicized (no internet)... and probably not nearly as much damager a 'hacker' or intruder could easily do without being identified.
er. Man, there was some juicy stuff on the flip-side of that stuff - names, addresses and IQ rating of all your class mates, payroll runs, all sorts of entertainment!
Boring... did they ever actually have anything useful accidentally leaked through for "paper reuse"... As in superuser passwords and addresses of important computers?:)
They were crypted... why would you need to hide a strong password that was crypted?
Shadow'ed passwords are an ugly hack.
Also, if you restrict "shadow" passwords so only root can see them, then suddenly every program that needs to perform authentication must be setuid root...... this is a security risk.
In that era, possibly a much larger security risk than the risk of a strong password being cracked.
The problem wasn't failing to use shadow passwords.
It was (1) UNIX users who set weak passwords, and (later), an (2) explosion in computing power, making it easier to attempt to crack the passwords.
Also, the reverse-engineering of the original DES-based crypt binaries allowed inefficiency that was intentionally contained in the algorithm to slow it down (making use for cracking improbable), to be removed, after years of study.
The DES-based crypt() algorithm was optimized into fast-crypt which was orders of magnitude faster, and actually made password cracking feasible.
If a harder cryptographic algorithm would have been used -- then matters could be very different.
The latter bit they should have seen coming.
The explosion in computing power was by no means a certain development, it wasn't an immediate issue at the time.
The first large-scale denial of service attack was perhaps a military blockade
Or barbarians/robbers taking down mail couriers.
Since the beginning of human civilization, wherever there has been communications infrastructure or commerce, there have been people intercepting it for the purpose of denying service.
Backups are designed to protect against loss regardless of cause...
The "1984 fiasco" caused Amazon to pledge to not ever again delete eBooks from consumers' devices. By contrast, Apple, BN, Sony, and others have not made such a promise.
It's kind of pointless to pick on the kindle about problems that should be ancient history.
By the way, iTunes and Amazon are no different with music files. You get to download the file once, re-downloading would be another purchase.
Server bandwidth to transfer content is not free.
The chance Amazon will want to delete stuff off your device is slim.
The case where it happened seemed to be an exceptional situation.
It's a cause for concern that it happened in one case, but Amazon took some serious PR flak for that.
It's no different with other readers really...
I expect Apple will be able to revoke apps' on the iPad (or break them next update), just like they can with the iPhone.
Your best bet might be to preemptively keep wireless turned off on the device (or blocked) when not in use.
And to pre-emptively break DRM on any eBooks you have, to ensure you can always read it, even if whoever you bought the reader from decides to do something nasty later.
Keeping Squid alive is easy... make sure to feed it properly, meet the hardware requirements, ensure ample access to water, and follow basic care guidelines.
Well, both positions are valid for different audiences.
Three audiences: Pure TINKERERS who just want a hackable gadget (and don't care about necessarily reading purchased eBooks that much -- they want the maximum geek utility from a reading device), People who just want to read their things (as in purchased prepared eBooks), and People who want to read things, and get as much of their existing/other content readable on the deivce as possible
Yeah.. but part of the formula is availability of real books.
Many books are available as only DRM'ed eBooks in the first place. And it's not been shown that Amazon DRM is any worse than other DRM, for the customer.
It appears that there are a lot of books available on the kindle store, that are not otherwise available as eBooks, or are much more expensive in other eBook formats.
So that actually is a huge advantage of the Kindle over some other readers (easy acquisition of the materials you want to read).
I shouldn't have to forego reading certain books, or read certain alternatives instead just because it's not available for my reader. That would be an inconvenience, and indicate a deficiency of the reading platform.
Some eBooks being available only as AZW is a disadvantage all other readers have to count.
My example for the moment is: IPv6 Security - Eric Vyncke (Author), Scott Hogg
There is a kindle edition for $38.40.
You can get that particular one as an encrypted, DRM'ed PDF from publisher, but that requires $50 to purchase the same thing as a PDF.
Or a $500/year subscription through Safari.
In any case, that is one of thousands of examples...
You pay more for a PDF, and it is still protected by Adobe DRM and encrypted so it can only be registered on one eBook authorized reader.
it appears to be a lot easier and less expensive to legally purchase and ACQUIRE Kindle format eBooks than to acquire electronic versions of certain books for other readers.
Slashdot Mirror
"shitty" code does not equal buggy code.
Your aesthetics, my aesthetics, or any other programmers' aesthetics are just personal opinions, don't need to be justified, and really have no particular value. On the contrary... you need to justify 100% a violation of some sort before code can be considered objectively bad, instead of just "Not how [you] would have gone about writing that, if you had been the person to write it".
As long as the code does exactly what it's supposed to do, and nothing more, and follows standard programming structure defined by the language and basic stylistic conventions (such as indentation), then the code is not shitty, no matter what my (or your) opinion is about its aesthetics.
P.S. It's not expected to be bug free but to have a much smaller volume of noticeable bugs than closed-source software release of equivalent age and complexity, after elapse of a bit of time.
Of course more complex closed-source software can be expected to be more buggy, and younger closed-source software can be expected to be more buggy.
The surprising result that is predicted by Linus would be that when unstable/development OSS released first at time X, while at the same time similar unstable/development closed-source is released at time X...
After a duration 'Y' elapses, the OSS software is much more stable after various releases than the closed source software (over the same time period)
Due to the 'many eyes' finding the issues in the OSS software code. And the closed source nature of the other product resulting in lots of bug reports (potentially), but many unfixed, and in any case, much fewer of the actual bugs addressed than in the OSS software for the same time period and usage patterns.
But does anyone REALLY believe it's bug-free because there are lots of eyeballs on it?
You are drawing unwarranted absolutes.
There will be bugs because features are being added at a rapid pace, and not everyone fully uses/tests every feature.
It's not expected to be bug-free or even for bugs to be found until years after release of a certain kernel.
Presumably updates to the stable kernel series should remove such bugs as they get found and reported.
I'm guessing it's a reference to security features.
Such as "UAC", "File permissions", "Protected mode", "Data execution protection", "Firewall".
Or this new technology MS just came up with and will surely soon be patented.. it's called a "Password", and it's really quite innovative -- it's basically a secret code, and the computer won't let you begin to use it or start a program before typing the secret password.
Well, taken separately, they may be not sufficient. He's not considering the combination though of: Auditing, code review, extensive testing playing with and looking at by many people, features, and attack.
Including people searching for vulnerabilities or ways to exploit things, not merely reviewing code. This type of auditing is outside the vocabulary of a company that deals in closed source software -- but with OSS, it can be expected to be a common thing.
What is it you are trying to sell exactly? Microsoft Secure Development Lifecycle?
"Eyes" on the source code aren't just code reviewers... they also consist of the attackers. Ok.. attackers have to find vulnerabilities to exploit somehow. The same techniques used by would-be attackers against the source to find exploitable holes can be used by the community (with source code access as a pre-requisite) to more effectively and with greater number people searching for things they can take advantage of, the more likely any issue is quicky found.
The only way to find faster, would be perhaps for someone to offer a bounty for anyone finding verifiably exploitable privilege escalation or remote exploitable security bugs in a default build of a stock kernel :)
The funny thing is... even addressing "at all phases" of the software development lifecycle and "integrating security into the day-to-day activities" is not enough to be secure.
Observation: This is the closest thing I believe I have seen so far, to an admission, from a Microsoftian, that their software can be inherently insecure (by design).
Seeing as the initial design is one of the most important parts of the software "lifecycle" by some views of the situation.
But the above quotation didn't argue merely AGAINST more eyes. It argued that essentially you can't make software more secure by looking at it, having code reviewed, and testing it.
That's absurd.
While there can be security weaknesses that won't be detected by thorough testing or code review, very large classes of security weaknesses can be.
Also, the complexity of the software systems interacting comes into play here...
Applications with simple well-controlled interactions and stable API (E.g. not like Windows) are less likely to have security issues that can escape a good code review.
And I forbid you from being non-subversive. Take that!
Actually.. I think it's being designed by secretaries, and written by armies of trained monkeys.
Which explains the bugs.
The janitorial work was outsourced to a contracter that is (secretly) owned by a competitor, a long time ago.
Your argument is basically a fallacy. Without any basis whatsoever, you've magically created some sort of line between a software company's tax rate, and the consumer price of goods.
The consumer price of goods isn't based directly on taxes MS pays though, it's based on what the consumer is willing to pay, and what the demand is for the product. Software publishers charge the highest price the market will bear within their desired sales volume (i.e. number units available) in order to maximize their profit.
The great thing about software is the costs to produce are very very low (on average) per unit, and the profits are extremely high. But to get those extreme profits, they are already charging as much for it as they felt they could charge, and increased costs do not change the retail price. Only changes in pricing pressure do that.
Here's the thing... since they are taxes they haven't already paid.. charging them now doesn't retroactively increase the price of already-purchased copies of Windows.
Also, due to competitive pressures in the marketplace, Microsoft can't simply raise the prices of their existing products. They would kill Windows 7 if they decided to raise the OEM price to $300 for Home Premium.
They can't increase the price in the past, so there's only one thing that can give their past profits get reduced.
This reduces the value of their company, and works against developing new products in as cost-effective a way, but it doesn't make the old products more expensive in practice.
Well, copyrights are contained in both. Neither the useful arts nor the sciences have a monopoly on the benefits from copyright, the constitutional mandate is to promote both, and copyright can promote progress in both.
The product of writing a software program such as a computer operating system is useful art.
Composing a piece of music, a theatrical production, or writing a poem or philosophical piece is science.
I'm not bolding necessarily the most important parts of sentences, only the parts that make my point the most vivid.
Anyways, the point is... the purpose that was most cleanly expressed by the result of the version of the text accepted into the constitution is that it's about progress.
The purpose of copyright is not merely to increase the sheer number of works available to the public.
But to actually promote progress in the arts/sciences.
If more works does that, then great.
But it's not automatically true that fewer works doesn't do that, or that fewer works means copyright has "failed"
It sounds plausible.... mail a few big rocks or packages containing heavy lead.
I wonder if anything like that last bit ever actually happened though. :)
That depends. Accessing individual paper records through old printouts is inefficient though, the info is outdated -- you can probably get that generally, via dumpster diving anyways.
But for students a likely goal is to change personal records, or more specifically... to alter personal grading records.
I guess the question is paranoid of what.
I'd expect the paranoid CS student to do "chmod 700 ~/"
and mkdir ~/tmp; export TMPDIR=~/tmp
Create all their files on their local workstation, and PGP-encrypt the tarball before uploading to their home directory on the shared machine.
After running their source code files through a source-code obfuscator and rot13 scrambler.
I would also guess... There were also few/no viruses.
And hacking was kind of pointless, since there was no security to hack.
But a skill barrier, since knowledge of such equipment was not generally publicized (no internet)... and probably not nearly as much damager a 'hacker' or intruder could easily do without being identified.
er. Man, there was some juicy stuff on the flip-side of that stuff - names, addresses and IQ rating of all your class mates, payroll runs, all sorts of entertainment!
Boring... did they ever actually have anything useful accidentally leaked through for "paper reuse"... As in superuser passwords and addresses of important computers? :)
They were crypted... why would you need to hide a strong password that was crypted? Shadow'ed passwords are an ugly hack.
Also, if you restrict "shadow" passwords so only root can see them, then suddenly every program that needs to perform authentication must be setuid root...... this is a security risk. In that era, possibly a much larger security risk than the risk of a strong password being cracked.
The problem wasn't failing to use shadow passwords. It was (1) UNIX users who set weak passwords, and (later), an (2) explosion in computing power, making it easier to attempt to crack the passwords.
Also, the reverse-engineering of the original DES-based crypt binaries allowed inefficiency that was intentionally contained in the algorithm to slow it down (making use for cracking improbable), to be removed, after years of study.
The DES-based crypt() algorithm was optimized into fast-crypt which was orders of magnitude faster, and actually made password cracking feasible. If a harder cryptographic algorithm would have been used -- then matters could be very different.
The latter bit they should have seen coming. The explosion in computing power was by no means a certain development, it wasn't an immediate issue at the time.
Perhaps they identified that someone had sent the -ext command, but as far as they could tell it was some accident or usage mistake?
The first large-scale denial of service attack was perhaps a military blockade
Or barbarians/robbers taking down mail couriers.
Since the beginning of human civilization, wherever there has been communications infrastructure or commerce, there have been people intercepting it for the purpose of denying service.
Backups are designed to protect against loss regardless of cause...
The "1984 fiasco" caused Amazon to pledge to not ever again delete eBooks from consumers' devices. By contrast, Apple, BN, Sony, and others have not made such a promise.
It's kind of pointless to pick on the kindle about problems that should be ancient history.
No, I meant circumference..
You haven't seen the new 4.7-inch-wide airplane seats yet? :)
This is about saving airline costs by forcing all passengers to be thin
And exact measurements are meant to be satirical.
So backup your materials...
By the way, iTunes and Amazon are no different with music files. You get to download the file once, re-downloading would be another purchase.
Server bandwidth to transfer content is not free.
The chance Amazon will want to delete stuff off your device is slim. The case where it happened seemed to be an exceptional situation.
It's a cause for concern that it happened in one case, but Amazon took some serious PR flak for that.
It's no different with other readers really... I expect Apple will be able to revoke apps' on the iPad (or break them next update), just like they can with the iPhone.
Your best bet might be to preemptively keep wireless turned off on the device (or blocked) when not in use.
And to pre-emptively break DRM on any eBooks you have, to ensure you can always read it, even if whoever you bought the reader from decides to do something nasty later.
Keeping Squid alive is easy... make sure to feed it properly, meet the hardware requirements, ensure ample access to water, and follow basic care guidelines.
Don't abuse or torture your squid.
These are all good qualities.
However, I think the backlit LCD is a show-stopper.
For comfortable reading and sufficient battery life to read a book, eInk or something equivalent is a must.
If I read correctly, the maximum battery life of the iPad is 10 hours, and in practice will probably be much less.
Also, the Kindle has a big advantage with its text-to-speech capabilities.
Well, both positions are valid for different audiences.
Three audiences: Pure TINKERERS who just want a hackable gadget (and don't care about necessarily reading purchased eBooks that much -- they want the maximum geek utility from a reading device), People who just want to read their things (as in purchased prepared eBooks), and People who want to read things, and get as much of their existing/other content readable on the deivce as possible
Yeah.. but part of the formula is availability of real books.
Many books are available as only DRM'ed eBooks in the first place. And it's not been shown that Amazon DRM is any worse than other DRM, for the customer.
It appears that there are a lot of books available on the kindle store, that are not otherwise available as eBooks, or are much more expensive in other eBook formats. So that actually is a huge advantage of the Kindle over some other readers (easy acquisition of the materials you want to read).
I shouldn't have to forego reading certain books, or read certain alternatives instead just because it's not available for my reader. That would be an inconvenience, and indicate a deficiency of the reading platform. Some eBooks being available only as AZW is a disadvantage all other readers have to count.
My example for the moment is: IPv6 Security - Eric Vyncke (Author), Scott Hogg
There is a kindle edition for $38.40. You can get that particular one as an encrypted, DRM'ed PDF from publisher, but that requires $50 to purchase the same thing as a PDF.
Or a $500/year subscription through Safari.
In any case, that is one of thousands of examples...
You pay more for a PDF, and it is still protected by Adobe DRM and encrypted so it can only be registered on one eBook authorized reader.
it appears to be a lot easier and less expensive to legally purchase and ACQUIRE Kindle format eBooks than to acquire electronic versions of certain books for other readers.
Actually, what they should do is publicly disclose the maximum distance around your waist.
E.g. They can print something like "To get on this plane, you must have a waste circumference no larger than 15"
So then people can simply measure themsevles, and avoid any unanticipated embarassment.