| |||||||||||||
Stable kernel 2.6.27.5Stable kernel 2.6.27.5Posted Nov 8, 2008 23:53 UTC (Sat) by ahoogerhuis (subscriber, #4041)Parent article: Stable kernel 2.6.27.5
Maybe this would be a starting point for a LWN article, show why here is such an allergy to invoking the "security fix" angle and keep using wording like "we strongly encourage users to upgrade"?
Although being far from a perfect comparison, if my car dealer came along and told me "we advise you to get the new car... strongly" and not coughing up some more to the point explanations then I'd question the whole car.
(Yes, I know the kernel is free as in beer and I'm not putting down the effort that goes in and it is by any means far more shiny than my own car, I'm just seeing this from a trust perspective.)
-A
(Log in to post comments)
what security fix? Posted Nov 9, 2008 2:32 UTC (Sun) by tialaramex (subscriber, #21167) [Link]
The work that it takes to comprehensively prove to yourself that a bug (in the kernel) has no security impact whatsoever is colossal, if it's even possible at all. If you aren't going to do that work (and nobody is volunteering) then it doesn't make much sense to call some bugs out as security bugs and thus imply that the others aren't.
what security fix? Posted Nov 9, 2008 3:03 UTC (Sun) by ahoogerhuis (subscriber, #4041) [Link]
This angle seems all fair and nice, but it seems that it is the case that there are various groups of people that are trying to say that there are bugs that are known security bugs, thus making the wording "please upgrade" slightly obfuscated when it might have been more approriate to say "we have fixed n security issues".
Feel free to take a look, but there has been some active campaigning on lwn.net from some people, and hardly a release has gone by without someone pointing out that there have been actual security issues fixed. Hence the comments such as posts #1 and #2.
-A
what security fix? Posted Nov 9, 2008 4:00 UTC (Sun) by bojan (subscriber, #14302) [Link]
> comprehensively prove to yourself
Nobody is asking for something like this to be done. What various people have asked for is that _known_ (by developers) security issues be called as such when fixed, instead of using euphemism like "strongly encouraged to upgrade".
what security fix? Posted Nov 9, 2008 12:36 UTC (Sun) by tialaramex (subscriber, #21167) [Link]
Feel free to provide the LKML with a list of actual things you could do with this information. Make sure you remove any items from the list which involve the closed world assumption (e.g. "I would prioritise fixing the security bugs") since those are bogus. Also remove any which actually negatively impact pragmatic security for the kernel's users (e.g. "I would make proof of concept exploits for the security bugs"), since obviously the LKML won't find those compelling. If you have any left, as well as posting to the LKML you might want to CC it here.
what security fix? Posted Nov 9, 2008 13:13 UTC (Sun) by PaXTeam (subscriber, #24616) [Link]
why is fixing known security bugs bogus? why do kernel devs fix them then?
what security fix? Posted Nov 9, 2008 13:21 UTC (Sun) by tialaramex (subscriber, #21167) [Link]
Huh?
Please, PaXTeam, slow down, and read things carefully before replying to them. I said that it is bogus to /prioritise/ fixing the bugs based on this arbitrary "security bug" label. Not that it is bogus to fix the bugs.
If the user wants bug fixes, this announcement makes it perfectly plain that it contains bug fixes. The question being asked is what use it would be to label /some/ of them as specifically "security bugs" and by implication, not the others.
what security fix? Posted Nov 9, 2008 14:17 UTC (Sun) by nix (subscriber, #2304) [Link]
There is a distinction that may be worthwhile: between 'this release
certainly contains security fixes' and 'this release may contain security fixes but we don't know'. However, this distinction is already being made (if in somewhat whimsical language).
what security fix? Posted Nov 9, 2008 14:57 UTC (Sun) by PaXTeam (subscriber, #24616) [Link]
you said that you want a list of things one would do with such information (meaning the known security impact of bugs). one obvious thing one does with it is to prioritize them (meaning, backport/apply to one's own trees, be that a distro or something in-house). you said and now confirmed again that such prioritization is bogus. now you can either claim that this bogus premise has a non-bogus consequence (something i assume you wouldn't based on your seeming inclination to logical methods) or i'm left wondering, hence my question in the previous post (which in turn you can also interpret as 'why prioritization is bogus?' - if it isn't then neither is applying security fixes from which it follows that withholding what is known to be a security bug is wrong).
now speaking of prioritization and that 'arbitrary' security label: why is it arbitrary? are you suggesting that non-security bugs are labeled as security ones (false positive issue) or that not all security bugs are labeled as such (false negative issue)? the former has no impact on one's security (just a bit of 'useless' work) and the latter assumes your bogus closed world model. so what is it you wanted to say here again?
what security fix? Posted Nov 9, 2008 16:39 UTC (Sun) by tialaramex (subscriber, #21167) [Link]
OK, so your actual question is:
"Given bug A and bugs B1-26, I think I should apply a patch for A but not for B1-26. Why is this bogus?" where:
Bug A is the subject of a long rambling Bugtraq post "Linux security is a joke" which claims that there's a serious buffer overflow and that it will "inevitably" be exploited in the wild. Linux writes and commits a two line patch, and nobody makes a working exploit, because unknown to everyone a structure alignment decision by the compiler makes the exploit condition impossible in the real world. Thus Bug A is a "security bug".
Bug B14 is 14th in a list of 26 patches fixing clearly incorrect use of an API for accessing the PCI bus. Only three people even read it, and Linus applied it because it looked similar to the other 25. But in reality it happens to fix a problem where anyone with access to play sound through an HDA compatible sound chip can also read & write arbitrary kernel memory using the right parameters to mremap(). Eventually someone will stumble on this problem and produce a POC, but not today. Thus Bug B14 is "not a security bug".
The answer is that it's bogus because it gives you (or your users) a false sense of security. You've fixed the "security bug" but actually you spent a lot of cycles on something that had no practical impact and left out the most important fix for something serious. Waiting three months for Bug B14 to "become" a security bug makes little sense, the fix is right there now. The easiest path, upgrading to stable, is in fact the best option if you don't have the cycles to do your own due diligence.
If you struggle to buy this argument, imagine that I have the set of all bug fixes, in the form of a hypothetical git branch against 2.6.27. Since my branch has no bugs, it also has no security bugs. Now, to cherry pick from my branch just fixes which you think are "security fixes" will certainly not produce a kernel which has /less/ security bugs than mine, indeed it will probably have more. Do you see?
what security fix? Posted Nov 9, 2008 17:26 UTC (Sun) by PaXTeam (subscriber, #24616) [Link]
no, that's a strawman, not my question. once more: why is it bogus to prioritize known security fixes (over others)? or better, in light of your last post: why does it give anyone a false sense of security? why would anyone feel secure by applying known security fixes but not others? why would anyone believe that other fixes definitely have no security impact? why do you think the people maintaining distro and other kernels are stupid?
summary: your problem is, as was explained back in july or so, that you're living in a black&white world (pretty ironic from someone who called the closed world model bogus ;). real life ain't anything like that. in real life people manage risks and often take them - it's not up to you or anyone else to make that call for them.
last but not least: you can't have that hypothetical git branch because that's only possible in a closed world model which according to you is bogus. nor can you have assurance that your supposed fixes don't introduce more problems which is what actually happens in real life at times (witness the frequent reverts). so no, i still don't see what you're trying to say but i'm beginning to feel that i'm up against an armchair security expert turned kernel programmer with no real life experience in either matter and i've seen that where that leads.
what security fix? Posted Nov 9, 2008 18:41 UTC (Sun) by tialaramex (subscriber, #21167) [Link]
Well now you've got lots of different questions again. I don't think there's any profit in me answering each question only for you to repeat that I'm wrong and offer yet more...
Let me suggest one thing to you: Pragmatism.
what security fix? Posted Nov 9, 2008 21:52 UTC (Sun) by ncm (subscriber, #165) [Link]
How's this for pragmatism: there are more IP protocols I don't use than protocols I do use. There are more devices I don't use than devices I do use. A bug, or a security hole, in one I don't use doesn't affect me at all. If a kernel is released to fix bugs only in protocols and drivers I don't use, there's no pragmatic reason at all for me to upgrade. Saying "you really would be better off upgrading", then, isn't just being obtuse; it's actually a falsehood.
A useful remark would be "this fixes a bug in SCTP", which means I can skip it, and be the better off for skipping it if I don't run any programs that use SCTP.
what security fix? Posted Nov 10, 2008 14:09 UTC (Mon) by tialaramex (subscriber, #21167) [Link]
Are you /sure/ you can skip it? Do you disable SCTP in your builds? If you don't, then it may be that the bug can be tripped by a remote attacker despite the fact that you "don't use" SCTP. And that's just the first example that comes to mind.
It would be relatively easy to carve out patches that only touch code in a specific area of the tree (for example, the SCTP implementation). But the recent e1000e bug illustrates beautifully that bugs aren't very good at respecting modularisation of design, since they're not designed but are instead unintentional.
If you do want to try this, as I said, it's fairly possible, Git makes it very practical for you to knock together a script that lists only those patches which touch your subset of the kernel, assuming you have the technical knowledge to understand how the kernel is laid out, and you have a complete list of the components you do or don't use, plus the time to examine architectural changes that might alter that list.
One thing that's going on is that there are many different constituencies who think that the kernel developers ought to make /their/ lives easier by doing just a minute or two's extra work. Since the kernel developers are a very precious resource I suggest that wherever possible you should look for ways to make things better without asking the developers to do more paperwork for you.
what security fix? Posted Nov 10, 2008 14:54 UTC (Mon) by PaXTeam (subscriber, #24616) [Link]
> One thing that's going on is that there are many different
> constituencies who think that the kernel developers ought to > make /their/ lives easier by doing just a minute or two's extra work.
huh? are you sure you understood the discussion at all? since when is withholding information *less* work than simply passing along what they already have?
what security fix? Posted Nov 10, 2008 18:00 UTC (Mon) by tialaramex (subscriber, #21167) [Link]
Well that rather depends on what it takes to "withhold" information.
I have a copy of the novel "A Fire Upon the Deep" here but those tired of this increasingly long thread will be glad to know that it was perfectly simple to "withhold" the contents of the novel from this message, I simply didn't choose to manually retype the entire thing into this little text box, saving myself hours of work.
On the other hand, this post will automatically identify me as the poster. To create another account in order to disguise my true identity would be a considerable amount of work just to withhold some information...
what security fix? Posted Nov 10, 2008 19:24 UTC (Mon) by PaXTeam (subscriber, #24616) [Link]
are you suggesting that kernel developers send patches on paper and integrators retype them carefully avoiding the security impact related info? impressive assumption, to say the least. because if that's not how kernel development works than your example has nothing to do with this thread's topic. as a sidenote, if you have to retype something then you don't 'have' it. you would 'have' it if you could copy-paste or attach it. incidentally, that's much more like how patches flow in kernel development. so give this one another try ;).
what security fix? Posted Nov 10, 2008 18:23 UTC (Mon) by iabervon (subscriber, #722) [Link]
Actually, I think it would be nice to have a version of the -stable patches which only updates a version number that's not in a file used by the build system. That way, you'd be able to apply the patch to your source tree and it would only rebuild anything if it affected code that you build.
Then everybody would want to apply the patch, since either it would provide a benefit (either stability or security) or it would not require any downtime to apply. For that matter, it would be nice to have a make target that wouldn't recopy modules that hadn't changed, and an lsmod flag to show modules which are different on disk from what's loaded.
what security fix? Posted Nov 10, 2008 18:31 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
read the detailed list of fixes, not just the first paragraph, if you don't use anything listed, don't worry about it
what security fix? Posted Nov 9, 2008 22:15 UTC (Sun) by efexis (guest, #26355) [Link]
"Pragmatic" disproves your point! To be pragmatic one needs information to base decisions upon. Simply following "we urge you to upgrade" isn't pragmatic at all, that's faith, faith in the developers to now what's best. Now nine times out of ten that might be just fine, but the one time out of ten, where an upgrade breaks some other part of your system, can still be often enough to be problematic.
If there are known security issues, I need to know, because I need to protect my servers and my clients, either by applying the fix, or by creating a seperation between the bug and potential triggers of it. If not, if it's say, timing tweaks to the schedulars to undo a regression, I need to make sure that it applies to me. If the regression hasn't affected my workloads, changes to the schedular could, and I wouldn't want to apply it without some stress testing during a planned upgrade time (we lost *loads* during early 2.6.2x kernels as IO would grind to a halt under certain loads as each of the cores just seemed to be blocking... the problem went away dropping back to the maintained 2.6.16 series, and post 2.6.25 seems okay, but boy did it cost us and did we learn our lesson).
Note that this isn't a complaint, I play about with risky experimental code because I enjoy the new stuff. If I thought they were crap, I wouldn't be using their kernel.
what security fix? Posted Nov 10, 2008 2:01 UTC (Mon) by qg6te2 (guest, #52587) [Link]
One can go around in circles with arguments about what is a "known possible security bug" vs "bug with unknown security implications". To add to the hyperbole one could also ask what does it take to become a "security issue" (e.g. is a bug that causes a crash/lock-up but otherwise doesn't provide root access a security issue? One may shrug off a lock-up on a personal laptop, but many clients will be very annoyed with lock-ups on servers running essential services).
Personally I'd like to know whether a kernel upgrade fixes a "known possible security bug", where the bug can be triggered by a deliberate and remote attack. However, one can also suspect that a reason for the rather obfuscated security warnings by Greg KH et al (i.e. "strongly encouraged to upgrade") is not the definition of a security issue, but the politics of the Linux Foundation. Once a bug has a CVE number, the count of security issues in Linux goes up. Obviously it's very useful for marketing reasons if the number of security issues in Linux is lower than other systems. Hence why add to the count of security bugs (even though they may lack CVEs), through kernel update disclosures ?
what security fix? Posted Nov 10, 2008 7:21 UTC (Mon) by nix (subscriber, #2304) [Link]
My understanding was more 'once a bug has a CVE number, really annoying
embargo rules come into play, with the result that many people would rather rip off their own legs than try to get a CVE number assigned'.
what security fix? Posted Nov 10, 2008 8:12 UTC (Mon) by PaXTeam (subscriber, #24616) [Link]
asking for a CVE is independent of asking for an embargo. one does the latter out of courtesy to distros or to please the corporate bosses (say, if one's employed by one of the commercial distros), but otherwise there's nothing that would force anyone to observe any embargo. so yes, those arguments have always been bogus too.
what security fix? Posted Nov 10, 2008 16:02 UTC (Mon) by mrshiny (subscriber, #4266) [Link]
Given bug A, which appears to be a security vulnerability, and bugs B1-26 which are not known to be vulnerabilities, does it make sense to apply patch B13, which contains its own bug which renders the iwl4965 driver inoperable (again)? Or patch B25, which introduces its own security vulnerability?
Bugs can be categorized as follows:
Known vulnerability, known to be exploitable
Now obviously we'd like to have patches for all of the first three classes, but we can't include the third because they're unknown. But clearly getting the KNOWN problems solved is better than nothing? And from a risk management perspective, fewer changes is better. Believe me, if I could just upgrade the parts of the kernel which required security fixes, I would. The last year I've had nothing but pain when upgrading my kernel and minimizing the changes makes sense. Thankfully I don't have to maintain a bunch of servers, just my one laptop. I'd hate to deploy a security fix to my enterprise and find that my entire workforce's wifi cards stopped working, making it extremely difficult for them to go back to a working kernel.
what security fix? Posted Nov 9, 2008 21:04 UTC (Sun) by bojan (subscriber, #14302) [Link]
LKML: These aren't security problems you're looking for.
Me: These aren't security problems we're looking for.
what security fix? Posted Nov 9, 2008 21:44 UTC (Sun) by bojan (subscriber, #14302) [Link]
Jokes aside, the following story is actually true. It happened to me last week.
I noticed an intermittent grinding sound coming out of my car's steering. Although the mechanic said that it probably wasn't dangerous and they couldn't replicate the problem when I brought the car to service, I insisted the car stays with them. On the second day, they called me and told me they replicated the problem and that they will be replacing the whole steering mechanism. I picked my car up on the third day, so I was willing to be without the car for almost three days to get this fixed, because I didn't want to risk the lives of my kids over it.
I also have a broken air conditioning vent coming out in front of the back seat. I didn't even remember to mention it to the mechanics.
I know you'll now ask "how is this relevant to the kernel". Gee, I don't know...
what security fix? Posted Nov 9, 2008 10:47 UTC (Sun) by PaXTeam (subscriber, #24616) [Link]
you keep repeating two fallacies.
> The work that it takes to comprehensively prove to yourself that a bug
this is about as wrong as it can get. why? because the correct answer is 'it depends'. there're many many fixes where it's very obvious whether the given bug impacts security or not. in my experience the tricky ones are those that can cause some non-trivial memory corruption and the prudent approach there is to simply call out their potential security impact.
or to explain it another way: consider how the kernel evolves. it's through patches adding/fixing/removing stuff. based on your assumption above we can't actually know if any of those fixes a bug (security ones included). the consequence of which is that to make any statement about the security of linux would take a colossal effort. i think most developers would disagree with you on that but feel free to remind them next time they make some bold statement about how secure linux is.
> [...] it doesn't make much sense to call some bugs out as security bugs
back during the summer discussions several people in the anti-security camp had kept repeating this even when it was thoroughly debunked. tell me, where does that implication come from? can you prove with anything (statistics or else) that people actually believe that the kernel has only those security bugs that are explicitly called out as such? because i have yet to see such person and, frankly, such a person wouldn't be in anyone's employment for long as he'd be unfit for any job having to do with the kernel (ever heard of undiscovered bugs, security or otherwise?).
put another way, when i call the sky blue, it doesn't imply that nothing else in the world is.
what security fix? Posted Nov 9, 2008 12:18 UTC (Sun) by tialaramex (subscriber, #21167) [Link]
"it depends" is the closest you come to the truth in that whole rant. The trouble is that "it depends" on too much, to be really /sure/ you have to do far too much work for it to be practical.
A bug is an unexpected behaviour, and because we're talking about the kernel there is no safety net. Unexpected behaviours have security implications. Sometimes very obvious "ordinary users can overwrite any file" and sometimes more subtle e.g. a race condition which sometimes leaks an fd into a child process that shouldn't have it and often far too subtle to describe in this small text box. You can only analyse those implications in a given context. What seems like "no security impact whatsoever" to you may be a huge problem for somebody else.
Since kernels don't have "just one bug" the analysis becomes even more difficult. Maybe a particular bug just makes it possible to force a particular kernel function to run a little slowly, maybe it takes 500x longer than usual. No security impact? And maybe another bug causes a race condition, where it seems that the winner will always be the safe choice, because the other side of the race is too hard. And you combine them, and suddenly you can reliably win the race.
Whose job will it be to explain to a user how the first bug has "no security impact" although without it nobody would have broken into their machines and cost them millions of dollars?
Your "blue sky" argument isn't a blue sky argument at all, but a simple straw man. You're claiming that people always operate the open world assumption, which is a laughable supposition. But worse, you try to equate caution (not claiming to know whether bugs have a security impact for the user) with something quite opposite (claiming to know that no bugs have a security impact).
BUT you can prove me wrong on my main point. Just provide a detailed commentary for a few months of all the bug fixes, stating categorically whether they do or don't have security implications. If you can do this reliably you'll silence me because you'll have proof by example, rather than just a lot of ranting in forums.
what security fix? Posted Nov 9, 2008 20:31 UTC (Sun) by efexis (guest, #26355) [Link]
You've completely missed the point, which is very very simply, that if there are known security implications regarding a bug, people want to know. We're not talking about putting a risk factor score against every bug so people can weight up how much of a security threat every bug is, that'd quite obviously get silly. We're not talking about studying all the bugs scientifically so we know what the effects and interactions with others are, that would be more work than fixing the things! But, when there already /is/ knowledge about a *specific* bug having security implications, then people want that knowledge shared.
When the e1000 bug hit that bricked peoples network cards, everyone knew about it, which was the responsible thing to do, so people with that card could avoid those releases. Does that mean people expect all bugs to be released with a "chances of destroying your hardware:" score? No. We're talking about sharing any known information. If the information isn't known, then it is outside of the scope of the discussion of what is being asked for.
what security fix? Posted Nov 9, 2008 22:40 UTC (Sun) by bojan (subscriber, #14302) [Link]
I think this is the simplest and best explanation of the issue so far. Thanks!
what security fix? Posted Nov 10, 2008 11:16 UTC (Mon) by tialaramex (subscriber, #21167) [Link]
You should take /that/ complaint to the list of people in the release notes.
Unless you think the Linux kernel should have a policy of not accepting bug fixes if it is suspected that the person who wrote the fix knows more than they're saying about its security implications. In which case, I think you're actually asking for /less security/ although perhaps with a very noble long term goal.
Stable kernel 2.6.27.5 Posted Nov 9, 2008 14:04 UTC (Sun) by sbergman27 (guest, #10767) [Link]
I would prefer a more professional "Just the facts, Ma'am" approach to these things. When one is trying to convince superiors, coworkers, and clients that Linux is a serious choice, crap like the wording of Greg's announcement doesn't help.
Stable kernel 2.6.27.5 Posted Nov 9, 2008 14:20 UTC (Sun) by nix (subscriber, #2304) [Link]
Just show such doubters a random Linus kernel announcement mail and
they'll soon grasp that whimsy and humour in release announcements is an l-k tradition.
(Anyone who equates reliability with 'professionalism' and professionalism
Stable kernel 2.6.27.5 Posted Nov 9, 2008 14:51 UTC (Sun) by endecotp (guest, #36428) [Link]
> I would prefer a more professional "Just the facts, Ma'am" approach
> to these things
I agree absolutely.
I honestly can't tell from the quoted message how important it is that I upgrade. On the face of it, it says I should upgrade. But it says it about four times with what look like jokes; is there some sort of "ironic" hidden message there that only regular LKML readers will understand? I'd be happiest if these announcements said - delete as appropriate -
(a) This release fixes known security problems;
And get rid of the jokes.
Stable kernel 2.6.27.5 Posted Nov 9, 2008 16:11 UTC (Sun) by TRauMa (guest, #16483) [Link]
Why don't you use a vendor kernel, ie. one from redhat or novell. That way you get update notices without any trace of humor and clear upgrade instructions (basically, "install this, now, security fixes"). If it troubles you that the *release notes* are too unprofessional for direct enterprise consumption, you really should be more worried about the kernel itself.
Stable kernel 2.6.27.5 Posted Nov 9, 2008 16:29 UTC (Sun) by PaXTeam (subscriber, #24616) [Link]
> Why don't you use a vendor kernel, ie. one from redhat or novell.
what makes you think that all the world's needs can be satisfied with those kernels? clearly that's not the case.
Stable kernel 2.6.27.5 Posted Nov 9, 2008 17:31 UTC (Sun) by xorbe (subscriber, #3165) [Link]
If OP is in a position that he must roll out bleeding edge kernels, and he can't figure out what was fixed from kernel to kernel without being spoonfed endecotp-approved emails that accompany a kernel patch announcement...
World's needs? No. Enterprise needs? Sure. Posted Nov 9, 2008 17:32 UTC (Sun) by khim (subscriber, #9252) [Link] The fact is: nobody is interested in security. Not really. That's not what is selling. What you can sell (and for pretty hefty sum BTW) is perception of security. Vendor's kernels are perfect for this. As for real security... Nothing is designed for it: linux is not designed for security, hardware is not designed with security in mind, etc... Yes, there are some things which can be used to enforce some [small] degree of security, but real protection is exchanged for 15%, 10% sometimes even 1% of additional speed! I'm not even sure that's bad thing: sure OpenBSD is much better then Linux security-wise, but it can not be used as replacement because it's just too ineffective. If your OS can not process the data you want processed it does not matter if it's secure or not. Linux is learning this the hard way: Windows is chosen 9 times out of 10 instead of Linux because Linux (or rather set of programs available under Linux) is just not capable enough...
World's needs? No. Enterprise needs? Sure. Posted Nov 9, 2008 22:26 UTC (Sun) by bojan (subscriber, #14302) [Link]
> perception of security
Yeah, that's what's being sold, just like with all other products. But, if a security hole gets fixed, it still makes the reality of running that kernel more secure.
World's needs? No. Enterprise needs? Sure. Posted Nov 9, 2008 22:27 UTC (Sun) by efexis (guest, #26355) [Link]
That's not really too true. Security is very important to many people, just that as you move more into the corporate world, 'security' covers more aspects than purely hacker-proof. Unless your business is security, you're often not going to know it was well as someone else whose is, and you become more susceptible to marketing drives and "common knowledge" (which is fed by those who have the money to make what they want know to be "common knowledge").
There is plenty of interest in security, which is why so much /is/ designed with security in mind. But people have to learn, we're not born with the knowledge that we choose to live by or ignore. Most people just want it to be taken care of for them, and will pay, as learning how to secure your website, your computer, your car, your home, your communications... is a bit much for one person. Better to have different people specialise in different areas.
Stable kernel 2.6.27.5 Posted Nov 9, 2008 23:05 UTC (Sun) by endecotp (guest, #36428) [Link]
I'm not remotely concerned about how "professional" it seems. I am not an "enterprise" person. For example, I'm not much concerned about things like spelling mistakes. I just want to be able to actually understand it.
OpenSolaris is your choice then... Posted Nov 9, 2008 16:16 UTC (Sun) by khim (subscriber, #9252) [Link] It looks like you want "professional" service like Sun and Microsoft are offering. Where release notes are carefully designed to cause retching assault in reader from too much bombast. Well, you know there are choices. Solaris, Windows or even MacOS X. Linux developers don't play these games - if you can not understood from the announcement that you really need to upgrade then probebly you should use something else...
OpenSolaris is your choice then... Posted Nov 9, 2008 16:41 UTC (Sun) by sbergman27 (guest, #10767) [Link]
"""
It looks like you want "professional" service like Sun and Microsoft are offering. """
Linux, you're 17 years old now, and your mother and I know that you want to be treated like an adult. But if you want people to do that, you must start acting like one, at least in public. What you do privately on the mailing lists with your friends is your own business, of course, as it always has been. But when making public announcements on serious topics it's a different matter.
OpenSolaris is your choice then... Posted Nov 10, 2008 15:18 UTC (Mon) by edmon (guest, #26395) [Link]
there is exact word for behavior that you just describe and the word is: hypocrisy
Stable kernel 2.6.27.5 Posted Nov 9, 2008 20:48 UTC (Sun) by efexis (guest, #26355) [Link]
These people don't serve you, they do what they do because they enjoy it. The idea of squeezing the life out of programmers to please bosses is just terrible. They already allow people to use their work for free, and allow anyone else to strip out the fun and make it corporate if they wish, which means there are people you can pay to get what you wish from it.
What you're talking about should happen at the distros. --strip-fun should not be applied upstream. Anyone who doesn't like it can go get their own hobby to not enjoy.
Stable kernel 2.6.27.5 Posted Nov 9, 2008 20:58 UTC (Sun) by sbergman27 (guest, #10767) [Link]
"""
These people don't serve you, they do what they do because they enjoy it. """
So Linux is a hobby OS?
Stable kernel 2.6.27.5 Posted Nov 9, 2008 22:58 UTC (Sun) by nix (subscriber, #2304) [Link]
Where does !hobby imply 'humour is not permitted, all signs of life and
personality must be squeezed out'?
Stable kernel 2.6.27.5 Posted Nov 9, 2008 23:34 UTC (Sun) by sbergman27 (guest, #10767) [Link]
I make a distinction between horseplay on the mailing lists and inappropriate flippancy in release announcements, intended for public consumption, pertaining to serious subjects like, say, security vulnerabilities. Why some people are so eager to extrapolate from that position to one which prohibits the expression of emotion entirely is unknown. There is a time and place for levity, and a time and place for serious presentation of information. Confuse the two and credibility suffers. Most people learn that by the time they graduate from high school.
Stable kernel 2.6.27.5 Posted Nov 9, 2008 23:47 UTC (Sun) by bojan (subscriber, #14302) [Link]
To me, this:
> are strongly encouraged to upgrade. Very strongly. Did I mention that you all should upgrade? Seriously, what are you waiting for?
Is not even funny. It's sad that people releasing the kernel need to pretend like this and use euphemisms for "we fixed known security bugs in this release". And all while claiming that security bugs should not be treated differently than any other bugs.
If one knows about the problem and admits to it, at least one walks away from it with honesty still intact. Otherwise, one turns in a politician-like word-mincer.
Stable kernel 2.6.27.5 Posted Nov 10, 2008 10:28 UTC (Mon) by tialaramex (subscriber, #21167) [Link]
Watch that victory speech one more time. Isn't it (by your definition) inappropriate flippancy to use an address to the entire population of the world, upon being elected to the highest office in the most powerful nation, to tell your kids they can have a dog?
There's a saying in the army (a deadly serious profession if ever there was one) that if you can't take a joke you shouldn't have joined. Black humour indeed since the saying is thought to originate from the period of conscription. But they're quite serious. Refusing to see the funny side doesn't give you credibility, it makes you look inhuman.
This announcement conveys its message (what was released, and what you should do about it) and it has a little fun. I'm sure any number of software release RSS feeds relayed it in a form suitable for machines, lacking any humour or humanity and you are welcome to subscribe.
Stable kernel 2.6.27.5 Posted Nov 10, 2008 11:58 UTC (Mon) by bojan (subscriber, #14302) [Link]
> to tell your kids they can have a dog
So, he was referring there to some specific policy of the new administration? I don't think so.
On the other hand, this release of Linux refers to serious security issues with weasel words in an (unsuccessful) attempt to be funny. If the release notes were peppered with real words explaining the reasons for being strongly encouraged to upgrade, then it may even have been funny.
Stable kernel 2.6.27.5 Posted Nov 10, 2008 14:46 UTC (Mon) by sbergman27 (guest, #10767) [Link]
I find it fascinating just how far some fans will go in defending their team when a member of that team exercises poor judgement in public.
Stable kernel 2.6.27.5 Posted Nov 10, 2008 17:05 UTC (Mon) by drag (subscriber, #31333) [Link]
To be honest I don't think being flippant is a very bad thing. Even in public. It's somewhat bad, but not enough to make me care.
I am tired of P.C. and corporate-speak and all that shit. I've been hearing it all my life and all it's really used for is trying to obscure the facts and slip in subtle advertisements rather then transmitting honest information. It's confusing, irritating, and usually somewhat dishonest. That is what I call a 'bad thing'.
Between this kernel announcement and the horseshit, misleading information, and out and out lies that I see continuously on anti-virus websites and all sorts of other security-related software and corporate announcements/pronouncements/press releases... I'll take a flippant kernel announcement every time.
|
|||||||||||||