"Open Source" doesn't buy you much. Sure, you can see what the program is "supposed" to do. But do you fully understand what the compiler does with it? Do you trust the compiler to be both bug free and non-malicious? I've filed far too many bugs against compilers to trust them to be bug free. Even if you assume they are, what about the compiler that was used to build your compiler? How do you know that the hardware on which the program is running doesn't leave it open to attack?
If you want "actual trust" you use machine code that has been proven correct running on hardware that has been proven correct and exhaustively tested. You don't care about whether or not the code is "open source". Most people don't require that level of paranoia, of course, nor can they afford the expense of doing such verification, but you shouldn't pretend that "publishing" or "open source" is magic security fairy dust.
Why on earth should any consumer be able to "tell you a single technical statistic about their smart phone like processor speed or even processor type?" It's wholly irrelevant to a phone's suitability. Either it works or it doesn't. Either it's enjoyable to use or it isn't. Either it's fast enough or it isn't. Either it has the functionality they need or it doesn't. None of those things are predicated on hardware specifications like processor speed or type. They're a function of both hardware and software, and exactly how the performance is achieved is totally irrelevant to the end user.
"If your code is so generic that your employer is fine with it being published because it gives them no competitive advantage, then you're probably not worth hiring."
I'm exaggerating, of course, but it cuts both ways. Some of my best work is not open source, and will never be published, precisely because it's substantially better than publicly available tools, and my employer paid me well to write it for that exact reason. I happen to also have some open source and public domain work that I'm very proud of and can point an interviewer to, but it's easy to imagine that someone else might not, especially a more junior person.
Except that you can't "do surgery full time with only the experience and training you got in medical school", which is why (in the US) surgeons go through a 5-7 year residency after medical school (often followed by a fellowship), during which time they work their asses off for less than my intern makes. After that point, they have a large body of work to prove their ability, and are able to get paid according to their skills.
I would be completely thrilled to hire someone fresh out of graduate school and work him 80 hours a week for 50k a year (after a year, he'd either be up. How many junior engineers would put up with that? I don't think you realize how easy we have it by comparison to surgeons.
The Wired article a published a month or two ago claims that the suicide rate at American colleges is higher than at Foxconn.
You are missing something: The suicide rates for the US which you're quoting are for entire lifetimes (the Americans had up to 70 years or so to decide to commit suicide)
What portion of the college-age population is over 70?
Actually, thinking long term would be using the superior format, knowing that the patents will expire within 20 years (in fact, most of them will expire long before then).
Apple has been sitting at (or around?) 4-5 billion in revenue for the better part of this last decade.
Apple's did $20B of revenue last quarter. That's considerably more than $5B/year, and it's grown considerably -- the same quarter last year revenue as $12B. It hasn't been "sitting" anywhere. Unit sales growth is something like 50% year over year.
It doesn't make it okay; it makes it unlikely that the work environment increases the likelihood that the factory employees would choose to commit suicide.
Whether or not it's okay depends rather strongly on one's religious/moral views about suicide.
The factory in question supposedly employs 400,000 workers. The annual suicide rate in China (as reported by the WHO) is 16.7 per 100,000 people. That means that in a population of randomly selected Chinese the size of the factory workforce, we should expect to see 400000 people * 16.7 suicides/(100000 people * 1 year) * 5 months / 12 months = 27.8 suicides so far this year.
Can we conclude that assembling shiny gadgets makes it less likely that one will commit suicide? It meets the standards for publication...
Shrug. I was put in charge of a project with 4 million lines of source my second year out of school. You carefully analyze the code paths that you need to work on at any given point in time, you write good thorough tests, you make your changes, you re-run your tests, and fix any regressions. The killer isn't the number of lines of source, its the interdependency between different modules (and the Linux kernel really doesn't have the best reputation in that department, though I don't know how much of its bad rap is deserved).
Darwin is basically just BSD with an extra dose of weird.
... and tens of thousands of bug fixes and performance improvements, all of which have been released back to the community, even though (for the most part) Apple had no obligation to do so.
Pi is interesting in that regard -- there are algorithms that can compute the Nth digit without needing to compute the intermediate digits. If you want to compute all digits from 0 to N, however, there are more efficient algorithms.
Slashdot Mirror
Spot on, but I'm not sure I'd call Senator Collins a "guy".
With 10.6 I could quickly skip to any given month.
Command-Shift-T, still works. Faster than using the GUI in either version.
If anything, the news is that the iPad2 actually *wins* in half of the linked benchmarks.
Yes, security by obscurity is stupid. So is security by "openness". Security and openness are orthogonal.
"Open Source" doesn't buy you much. Sure, you can see what the program is "supposed" to do. But do you fully understand what the compiler does with it? Do you trust the compiler to be both bug free and non-malicious? I've filed far too many bugs against compilers to trust them to be bug free. Even if you assume they are, what about the compiler that was used to build your compiler? How do you know that the hardware on which the program is running doesn't leave it open to attack?
If you want "actual trust" you use machine code that has been proven correct running on hardware that has been proven correct and exhaustively tested. You don't care about whether or not the code is "open source". Most people don't require that level of paranoia, of course, nor can they afford the expense of doing such verification, but you shouldn't pretend that "publishing" or "open source" is magic security fairy dust.
Why on earth should any consumer be able to "tell you a single technical statistic about their smart phone like processor speed or even processor type?" It's wholly irrelevant to a phone's suitability. Either it works or it doesn't. Either it's enjoyable to use or it isn't. Either it's fast enough or it isn't. Either it has the functionality they need or it doesn't. None of those things are predicated on hardware specifications like processor speed or type. They're a function of both hardware and software, and exactly how the performance is achieved is totally irrelevant to the end user.
"If your code is so generic that your employer is fine with it being published because it gives them no competitive advantage, then you're probably not worth hiring."
I'm exaggerating, of course, but it cuts both ways. Some of my best work is not open source, and will never be published, precisely because it's substantially better than publicly available tools, and my employer paid me well to write it for that exact reason. I happen to also have some open source and public domain work that I'm very proud of and can point an interviewer to, but it's easy to imagine that someone else might not, especially a more junior person.
Except that you can't "do surgery full time with only the experience and training you got in medical school", which is why (in the US) surgeons go through a 5-7 year residency after medical school (often followed by a fellowship), during which time they work their asses off for less than my intern makes. After that point, they have a large body of work to prove their ability, and are able to get paid according to their skills.
I would be completely thrilled to hire someone fresh out of graduate school and work him 80 hours a week for 50k a year (after a year, he'd either be up. How many junior engineers would put up with that? I don't think you realize how easy we have it by comparison to surgeons.
The Wired article a published a month or two ago claims that the suicide rate at American colleges is higher than at Foxconn.
You are missing something: The suicide rates for the US which you're quoting are for entire lifetimes (the Americans had up to 70 years or so to decide to commit suicide)
What portion of the college-age population is over 70?
Actually, thinking long term would be using the superior format, knowing that the patents will expire within 20 years (in fact, most of them will expire long before then).
Apple has been sitting at (or around?) 4-5 billion in revenue for the better part of this last decade.
Apple's did $20B of revenue last quarter. That's considerably more than $5B/year, and it's grown considerably -- the same quarter last year revenue as $12B. It hasn't been "sitting" anywhere. Unit sales growth is something like 50% year over year.
-1 Wooooosh.
It doesn't make it okay; it makes it unlikely that the work environment increases the likelihood that the factory employees would choose to commit suicide.
Whether or not it's okay depends rather strongly on one's religious/moral views about suicide.
The factory in question supposedly employs 400,000 workers. The annual suicide rate in China (as reported by the WHO) is 16.7 per 100,000 people. That means that in a population of randomly selected Chinese the size of the factory workforce, we should expect to see 400000 people * 16.7 suicides/(100000 people * 1 year) * 5 months / 12 months = 27.8 suicides so far this year.
Can we conclude that assembling shiny gadgets makes it less likely that one will commit suicide? It meets the standards for publication...
One button for 3 seconds. Details, details.
Shrug. I was put in charge of a project with 4 million lines of source my second year out of school. You carefully analyze the code paths that you need to work on at any given point in time, you write good thorough tests, you make your changes, you re-run your tests, and fix any regressions. The killer isn't the number of lines of source, its the interdependency between different modules (and the Linux kernel really doesn't have the best reputation in that department, though I don't know how much of its bad rap is deserved).
Not at all. A large portion of the OS X user space has been open sourced by Apple as well. Windows, not so much.
Darwin is basically just BSD with an extra dose of weird.
... and tens of thousands of bug fixes and performance improvements, all of which have been released back to the community, even though (for the most part) Apple had no obligation to do so.
I read it.
Not only is it open source, but even the FSF considers the APSLv2 to be a free software license:
http://www.gnu.org/philosophy/apsl.html
There's no call for rudeness, even on slashdot.
It absolutely is open source. It's not copyleft, and it's incompatible with the GPL, but even the FSF considers it to be a free software license.
Patent licensing is an orthogonal issue, and Microsoft is certainly no better in that regard, either.
The rest of the hardware contains an OS that is just as open.
What the hell are you talking about?
Most likely this:
http://www.opensource.apple.com/release/mac-os-x-1063/
Far more open than windows.
It's just as closed as Windows
Awesome! Where do I go to download the Windows 7 kernel source?
Any US tech companies giving out 6 months of bonus this year?
Yes, though typically in some form of RSU rather than straight cash bonus.
Your point about average salary in Taiwan is spot on, though.
Ha! Mod parent informative.
Pi is interesting in that regard -- there are algorithms that can compute the Nth digit without needing to compute the intermediate digits. If you want to compute all digits from 0 to N, however, there are more efficient algorithms.