"Newton wasn't *wrong*, he just didn't specify the parts he couldn't see."
Sorry, but Newton *was* wrong. Twofold. It was experimentally wrong since he predicted results that don't fit the observed measures and he was epystemologically wrong since he thougth space and time were absolute measures.
Or is it that if you asked Newton something like "what would be the relative speed of two objects travelling opposite directions at 150.000Km/s each? he would answer "Well, I don't know, that's something my theory doesn't predict" or, maybe, "Easy: 300.000Km/s"?
"It's part of every company's business to provide service to their customers in an ethical manner."
What's unethical about depolying to specs? The most you can do is rise concern and offer a remedy but then, if the customer doesn't buy in, what else do you expect to be done?
"I think the point of the story isn't that eating mislabelled raw fish might cause disease but that a lot of raw fish is mislabelled."
Certainly that it *should* be but sorrily it isn't: "A piece of tuna sushi has the potential to be an endangered species, a fraud or a health hazard [...] This new study shows that some sushi can actually make you sick."
"The tension between budget and business requirements can be useful but it is largely a paper tiger."
Yes indeed, but not because of the reasons you highlight. There is no tension between budget and requirements since budget is just a natural outcoming from the requirements themselves: you don't need 24x7 services; you lose XXX dolars per hour when the service is down. Once you factor in the risk management is wishing to take your budget is just a matter of a multiply: it's XXX dolars per downtime hour multiplied by the risk you are accepting. You lose 10.000 per downtime hour and you don't want to lose more than 100.000 on a risk you measured to have a 10% chance (a ten hours downtime)? Then your allowed front cost for this is 30.000 (for iron under three years amortization).
I'm used to hear about "I want uber-redundancy and 24x7 disponibility" "well, that'll cost you XXX" "But I can't pay that!" That means that you don't earn that much from that system. It's never "I can't afford it" but "it doesn't get me so much".
Certainly you are 26. When it became standard for a "real" alarm clock to tune radio? Mine still does "riiiiiiiiiiiiiiiing" and nothing more.
Next generation will talk about a "real wristwatch clock" when almost everybody will use their mobile and the next one will say they knew "the real mobile" when everybody is using the then standard brain communications interface.
"It's pretty obtuse to think that wristwatches are going to become obsolete."
At least somebody sensible. That's true. If you think about it Spock-like, there's nothing in current civilization as obsolet as the human being itself. But we (well, I'm not a robot, so I'm indeed part of "we"), being humans, can't deprive our obsolete selves of some kinds of things we feel comfortable with for very different reasons. We don't quite get free of roman numerals, which were made obsolete by arabic numerals; we don't get free of martial arts, obsoleted by fire weapons; we don't get free of bespoke taylors, obsoleted by pret-a-porter; we don't get free of pocket watches, obsoleted by wristwatches; we don't get free of mechanical wristwatches (I own two: an Omega and a Longines, and I use them daily), obsoleted by quartz watches, and we won't get free of quartz wristwatches because of mobile phones.
If any, I would consider the last one: quartz wristwatches are just utility objects, so they *might* be obsoleted by a better utility object (but I don't see a mobile phone being a better utility to tell the hour than a wristwatch). It might happen just as almost from night to day people abandoned hats. But even while hats are massively less used now that fifty years ago they are not completly obsoleted (I myself own and wear some Stetsons, Borsalinos and Lock and Co among others), but you can bet there will be a place for an ornamental watch for the next fifty to one hundred years (you can bet I'll wear watches and hats till I die and a lot of people will do too -hell, short-winged trilbys are fashioned again).
"Cool, NFS and automount works great for a workstation or server with a very fast LAN connection to the NFS server, now how do you provide that same service to a road warrior?"
AFS or gasp! a corporate laptop with all corporate sofware already installed.
"How are you going to slip something into a signed package?!? That's the whole point in signing it, it can't be tampered with or the signature becomes invalid."
But what do you exactly sign?
All you sign is that a certain piece of code is the very untampered one a given provider did release. Does signature provides a "fit for usage" meaning? Does it provide a "for your eyes only" security?
The most simple case: Take a DHCP daemon properly signed by Red Hat or even by your local authority. That's the real code, pristine and untampered just as the very signing process is meant to procure. Now, what happens when two or more instances of that very blessed piece of code happen to run out of control in the same network segment?
"We've had that on Windows since forever where we can publish applications to a user and allow them to install in on first run without requiring administrator access."
That's because Windows need it due to two historic circumnstances: 1) Lack of tools for properly remotely manage systems (so basically the "install on first run" was a way for the IT guy not having to go physically to the user's system to install it). That's not the case anymore 2) The registry which makes that a simple software installation requering local tweaking on the binary blob called registry
On environments that 1) Are properly and easily remotelly managed 2) Doesn't need to pollute the local system in order to run a program you don't need that (NFS and the automounter is all you need to allow users "to install the program on first use" on UNIX and Unix-like systems on a corporate environment).
"This assumes the user is different from a admin, which is not true for a personal desktop"
He asumes that the admin context is the same as the user context if they happen to be the same person, which is not true anywhere, not even personal desktops.
"this could be really useful within an organization to allow users to install company-authorized packages without having to run around and install everything for everyone"
A corporate environment where IT people has to run around to install everything for everyone is already fucked beyond repair and no amount of "really useful" tricks will help with that.
"I allow you to install any package which I have signed. You don't need to log in as a more-powerful user to do so, because I have already pre-approved this action [...] Sounds like a good idea, especially for a corporate environment (single deployment, but if some people need to install Eclipse, they don't need to contact support to do so)"
The proper way to "pre-approve" a package installation in a corporate environment is having it already installed, not raising privileges. If there's a need for a user to work with superuser privileges you give him root password for the box.
"The next step along the line is to tie this into the existing "that command doesn't exist, install Foo to use it", to turn that into "Foo isn't installed, do you want to install it?""
You know Debian allowed this for ages (auto-apt, but of course you need superuser privileges), don't you?
"so you would advise we somehow shipped fedora 12 with a kernel version - 2.6.32 - which barely even existed at the final version freeze date?"
It's always the same with technology: it's a moving target. There always will be the tomorrow's silver bullet. There will always be a newer faster processor, a newer better mobile, a newer better... just round the corner. If only we wait few weeks, if only we stretch our goals a bit... I am not saying ship Fedora with 2.6.32 if it's not ready, I say ship it with 2.6.31. You will have 2.6.32 on next Fedora release and you can bet that by that day there will be a new kernel version just a few days ahead then too.
"So you will want to make releases that aren't your new major version yet. But how do you label them? Obviously, calling them X.0 is not the way to go... but what is?"
ODS: The Odd Numbering Scheme. On major and minor, Odd means unstable; pair stable. Extra is only for bugfixes in pair releases and doesn't bear any special meaning on odd branches. So you know at a glance what to expect from a software release even without knowing about the project: 3.7.8? Eigth bugfix iteration on the stable 3.7 branch, where 7 is the fourth stable launch from the 3 branch. 2.x.y? The first strong rewrite towards stable version 3. Within the 2. branch, maybe 2.3 is quite usable since 3 is an odd number, but it's up to your bleed-edge liken to test it. At lest it has *some* features already stabilized. 3.4.7? A minor development version towards stable 3.5.
For whole desktops, they should abandon the idea of launching it as a whole since apps will live their own lives (so you can have Amarok 3.5.7 -stable for KDE 4.0.3 -highly unstable or for 3.5.10 -highly stable).
So, first KDE stable would have been 5.1.0. It might happen that while a stable desktop not a single app would have been developed for it yet (quite a different issue but still perfectly acceptable as any Windows customer would recognize: OS, desktop and zero productivity apps is what comes in the "Windows whatever box") but given the nature of KDE as an open collaborative project a bunch of "in core" apps can be develop on par with desktop releases (more or less like now but accepting that if you call kmail "a core member of KDE" then you can't call KDE-anything stable unless it comes with a stable plentily functional kmail version too).
Now about "cooling" periods. In the open source world, when an app would be considered stable enough? Easy when no critical bugs are opened and no critical bugs are filled within a given (maybe per-project stablished) period of time. Just give valour to the "given enough eyeballs, all bugs are shallow" motto. Open source means not only that we are gifted with the code but that responsibility is shared with users too. If no one is able to find and fill a bug in, say, 60 days for a new major version or 15 days for a minor one then it must be considered stable for all practical means. This would counter Torvalds' argument about why he abandoned his "soft" ODS (nobody wanted to test unstable so when we published stable there was a high spike in bugs): if you did your homework (cooling, say the to-be 2.4 for 60 days without major bugs filled) then no one has the right to fingerpoint you for after-the-fact found bugs. This would mean that major projects would get a better user-leveled QA because being cooling for the same time-span than a minor project more eyeballs would look at it, exactly as expected and needed.
"I shouldn't have to dig into your dev or user mailing list to determine if I should pick up a version."
While I'm with you about your overall message, I can't agree with the above sentence. You (as an end user) shouldn't go to the devs' mailing list *at all*; that's the distribution packagers' work (or yours, only if you happen to be a developer/integrator). For them it's easy (and kind of an obligation) to find what a release is meant to.
Where you really need to put the culprit (if anywhere) is at the distribution level since it's at that level where the decision of including or not including a given software/version is taken.
"Michael Moore and Al Gore have "documentaries" that at the very least have statements and facts proven to be untrue, and plenty of people believe them."
But at least Gore and Moore *pretended* to be producing documentaries, not fiction films.
Slashdot Mirror
"Newton wasn't *wrong*, he just didn't specify the parts he couldn't see."
Sorry, but Newton *was* wrong. Twofold. It was experimentally wrong since he predicted results that don't fit the observed measures and he was epystemologically wrong since he thougth space and time were absolute measures.
Or is it that if you asked Newton something like "what would be the relative speed of two objects travelling opposite directions at 150.000Km/s each? he would answer "Well, I don't know, that's something my theory doesn't predict" or, maybe, "Easy: 300.000Km/s"?
"It's part of every company's business to provide service to their customers in an ethical manner."
What's unethical about depolying to specs? The most you can do is rise concern and offer a remedy but then, if the customer doesn't buy in, what else do you expect to be done?
"I think the point of the story isn't that eating mislabelled raw fish might cause disease but that a lot of raw fish is mislabelled."
Certainly that it *should* be but sorrily it isn't: "A piece of tuna sushi has the potential to be an endangered species, a fraud or a health hazard [...] This new study shows that some sushi can actually make you sick."
It's an example of terrible journalism.
"The title asks if the sushi is hazardous, but the story is only about the fish"
The story is not even that: is a non-story. Eating a mislabelled piece of raw fish might produce disease. Well, yeah...
"My 70-odd technophobe maiden aunt has had a radio alarm clock for well over a decade."
Yes, but ask her if hers is a "real" alarm clock.
"The tension between budget and business requirements can be useful but it is largely a paper tiger."
Yes indeed, but not because of the reasons you highlight. There is no tension between budget and requirements since budget is just a natural outcoming from the requirements themselves: you don't need 24x7 services; you lose XXX dolars per hour when the service is down. Once you factor in the risk management is wishing to take your budget is just a matter of a multiply: it's XXX dolars per downtime hour multiplied by the risk you are accepting. You lose 10.000 per downtime hour and you don't want to lose more than 100.000 on a risk you measured to have a 10% chance (a ten hours downtime)? Then your allowed front cost for this is 30.000 (for iron under three years amortization).
I'm used to hear about "I want uber-redundancy and 24x7 disponibility" "well, that'll cost you XXX" "But I can't pay that!" That means that you don't earn that much from that system. It's never "I can't afford it" but "it doesn't get me so much".
"Maybe the first question should really be: what's your budget?"
Maybe the first question should really be: you are in charge for the transition but you are clueless about how to do it. What the heck?
"use a real alarm clock to wake up to the radio"
Certainly you are 26. When it became standard for a "real" alarm clock to tune radio? Mine still does "riiiiiiiiiiiiiiiing" and nothing more.
Next generation will talk about a "real wristwatch clock" when almost everybody will use their mobile and the next one will say they knew "the real mobile" when everybody is using the then standard brain communications interface.
It's hard to grow old.
"Maybe it's the Aspergers that makes me obsess"
Sorry not. I did make you anything.
"I fully admit that watches are valuable as a status-symbol. But that's not saying much. People are stupid."
That's not the point. The point is that it is not expected that people in the future will be any less stupid than they are now.
"In summary, fancy watches are for stupid yahoos."
Don't expect stupid yahoos being in extinction danger anytime soon either.
"My Nokia was GBP 10, and I can make phone calls with it. Try that with your wristwatch."
Uh!? You missed Q's note about your new phone-wristwatch?
"It's pretty obtuse to think that wristwatches are going to become obsolete."
At least somebody sensible. That's true. If you think about it Spock-like, there's nothing in current civilization as obsolet as the human being itself. But we (well, I'm not a robot, so I'm indeed part of "we"), being humans, can't deprive our obsolete selves of some kinds of things we feel comfortable with for very different reasons. We don't quite get free of roman numerals, which were made obsolete by arabic numerals; we don't get free of martial arts, obsoleted by fire weapons; we don't get free of bespoke taylors, obsoleted by pret-a-porter; we don't get free of pocket watches, obsoleted by wristwatches; we don't get free of mechanical wristwatches (I own two: an Omega and a Longines, and I use them daily), obsoleted by quartz watches, and we won't get free of quartz wristwatches because of mobile phones.
If any, I would consider the last one: quartz wristwatches are just utility objects, so they *might* be obsoleted by a better utility object (but I don't see a mobile phone being a better utility to tell the hour than a wristwatch). It might happen just as almost from night to day people abandoned hats. But even while hats are massively less used now that fifty years ago they are not completly obsoleted (I myself own and wear some Stetsons, Borsalinos and Lock and Co among others), but you can bet there will be a place for an ornamental watch for the next fifty to one hundred years (you can bet I'll wear watches and hats till I die and a lot of people will do too -hell, short-winged trilbys are fashioned again).
" It's like dropping a brick on a table: the weight will create a shock on impact and constant pressure afterwards."
It's nothing like droping a brick on a table. Not on the slightest.
"The key question, which TFA avoided giving details about, is what range they are talking about."
You think you are very clever, don't you? But the key question is "yeah, but is that beam machine shark-mountable?"
"Cool, NFS and automount works great for a workstation or server with a very fast LAN connection to the NFS server, now how do you provide that same service to a road warrior?"
AFS or gasp! a corporate laptop with all corporate sofware already installed.
"How are you going to slip something into a signed package?!? That's the whole point in signing it, it can't be tampered with or the signature becomes invalid."
But what do you exactly sign?
All you sign is that a certain piece of code is the very untampered one a given provider did release. Does signature provides a "fit for usage" meaning? Does it provide a "for your eyes only" security?
The most simple case: Take a DHCP daemon properly signed by Red Hat or even by your local authority. That's the real code, pristine and untampered just as the very signing process is meant to procure. Now, what happens when two or more instances of that very blessed piece of code happen to run out of control in the same network segment?
"We've had that on Windows since forever where we can publish applications to a user and allow them to install in on first run without requiring administrator access."
That's because Windows need it due to two historic circumnstances:
1) Lack of tools for properly remotely manage systems (so basically the "install on first run" was a way for the IT guy not having to go physically to the user's system to install it). That's not the case anymore
2) The registry which makes that a simple software installation requering local tweaking on the binary blob called registry
On environments that
1) Are properly and easily remotelly managed
2) Doesn't need to pollute the local system in order to run a program
you don't need that (NFS and the automounter is all you need to allow users "to install the program on first use" on UNIX and Unix-like systems on a corporate environment).
"This assumes the user is different from a admin, which is not true for a personal desktop"
He asumes that the admin context is the same as the user context if they happen to be the same person, which is not true anywhere, not even personal desktops.
"this could be really useful within an organization to allow users to install company-authorized packages without having to run around and install everything for everyone"
A corporate environment where IT people has to run around to install everything for everyone is already fucked beyond repair and no amount of "really useful" tricks will help with that.
"sudo bash .conf files."
works for Ubuntu without ever activating root login. It's what I use when I go in to edit
Which in turn shows why sudo is not a security tool.
"I allow you to install any package which I have signed. You don't need to log in as a more-powerful user to do so, because I have already pre-approved this action [...] Sounds like a good idea, especially for a corporate environment (single deployment, but if some people need to install Eclipse, they don't need to contact support to do so)"
The proper way to "pre-approve" a package installation in a corporate environment is having it already installed, not raising privileges. If there's a need for a user to work with superuser privileges you give him root password for the box.
"The next step along the line is to tie this into the existing "that command doesn't exist, install Foo to use it", to turn that into "Foo isn't installed, do you want to install it?""
You know Debian allowed this for ages (auto-apt, but of course you need superuser privileges), don't you?
"so you would advise we somehow shipped fedora 12 with a kernel version - 2.6.32 - which barely even existed at the final version freeze date?"
It's always the same with technology: it's a moving target. There always will be the tomorrow's silver bullet. There will always be a newer faster processor, a newer better mobile, a newer better... just round the corner. If only we wait few weeks, if only we stretch our goals a bit... I am not saying ship Fedora with 2.6.32 if it's not ready, I say ship it with 2.6.31. You will have 2.6.32 on next Fedora release and you can bet that by that day there will be a new kernel version just a few days ahead then too.
"So you will want to make releases that aren't your new major version yet. But how do you label them? Obviously, calling them X.0 is not the way to go ... but what is?"
ODS: The Odd Numbering Scheme. On major and minor, Odd means unstable; pair stable. Extra is only for bugfixes in pair releases and doesn't bear any special meaning on odd branches. So you know at a glance what to expect from a software release even without knowing about the project: 3.7.8? Eigth bugfix iteration on the stable 3.7 branch, where 7 is the fourth stable launch from the 3 branch. 2.x.y? The first strong rewrite towards stable version 3. Within the 2. branch, maybe 2.3 is quite usable since 3 is an odd number, but it's up to your bleed-edge liken to test it. At lest it has *some* features already stabilized. 3.4.7? A minor development version towards stable 3.5.
For whole desktops, they should abandon the idea of launching it as a whole since apps will live their own lives (so you can have Amarok 3.5.7 -stable for KDE 4.0.3 -highly unstable or for 3.5.10 -highly stable).
So, first KDE stable would have been 5.1.0. It might happen that while a stable desktop not a single app would have been developed for it yet (quite a different issue but still perfectly acceptable as any Windows customer would recognize: OS, desktop and zero productivity apps is what comes in the "Windows whatever box") but given the nature of KDE as an open collaborative project a bunch of "in core" apps can be develop on par with desktop releases (more or less like now but accepting that if you call kmail "a core member of KDE" then you can't call KDE-anything stable unless it comes with a stable plentily functional kmail version too).
Now about "cooling" periods. In the open source world, when an app would be considered stable enough? Easy when no critical bugs are opened and no critical bugs are filled within a given (maybe per-project stablished) period of time. Just give valour to the "given enough eyeballs, all bugs are shallow" motto. Open source means not only that we are gifted with the code but that responsibility is shared with users too. If no one is able to find and fill a bug in, say, 60 days for a new major version or 15 days for a minor one then it must be considered stable for all practical means. This would counter Torvalds' argument about why he abandoned his "soft" ODS (nobody wanted to test unstable so when we published stable there was a high spike in bugs): if you did your homework (cooling, say the to-be 2.4 for 60 days without major bugs filled) then no one has the right to fingerpoint you for after-the-fact found bugs. This would mean that major projects would get a better user-leveled QA because being cooling for the same time-span than a minor project more eyeballs would look at it, exactly as expected and needed.
"I shouldn't have to dig into your dev or user mailing list to determine if I should pick up a version."
While I'm with you about your overall message, I can't agree with the above sentence. You (as an end user) shouldn't go to the devs' mailing list *at all*; that's the distribution packagers' work (or yours, only if you happen to be a developer/integrator). For them it's easy (and kind of an obligation) to find what a release is meant to.
Where you really need to put the culprit (if anywhere) is at the distribution level since it's at that level where the decision of including or not including a given software/version is taken.
"Michael Moore and Al Gore have "documentaries" that at the very least have statements and facts proven to be untrue, and plenty of people believe them."
But at least Gore and Moore *pretended* to be producing documentaries, not fiction films.