well, as we know, "works" can be defined differently;) according to http://openprinting.org/printer_list.cgi?make=HP there are some hp printers in paperweight category, a couple in 'partially' and a lot in 'mostly' working categories.
i actually am basing my purchasing decisions on these lists in addition to other information sources, and i usually consider only devices in "perfectly" category.
additionally, i prefer devices that work with cups outofthebox, though this is harder to achieve.
"The original poster was quite correct that the GPL is a minefield."
just like any other licence. except maybe public domain, which isn't exactly a license as such.
"...then there are going to be some legal issues to watch out for, and legal issues that don't have really clear answers because the GPL is unlike any other "license agreement" that came before."
it is unlike in some aspects, but in general, almost all licence agreements that exceed two sentences have weird clauses, clauses that are open to misinterpretation and so on.
of course, one must remember that modifications to gpl code must be released to parties to whom changed code is shipped to - it is perfectly valid to modify gpl code, and keep modifications secret. until you distribute it.
overall i agree with your post - if a company is not obviously intentionally violating licence terms and is openly working to comply, that should be praised.
"Suppose we have another Alexandrian library fire (maybe thanks to Islamicists this time) and we collectively forget about the nasties buried deep underground - until some enterprising miners in a newly emerging industrial society find out the hard way."
this immediately reminded me of a material i was reading some time ago. after a long search i found the text - but it had pictures, envisioning different designs and concepts. the design was pretty awful (and current text page also is badly formatted;) ), but it was the content that was very interesting.
so, here's the text only : http://www.physics.uci.edu/~silverma/benford.html if anybody knows where this material could be found with the images of concepts, please, post here. the images really help to better envision the magnitude of the problem (though the text is very good and descriptive, too).
- faster, a lot faster fixes than for closed-source drivers;
The biggest cause for this is testing. Most companies will not release an updated driver until it has gone through quality assurance testing. Open source developers do not have dedicated QA teams. Yes, companies like RedHat do, but that's for their own releases, not for the mainstream ones.
Sure, some companies don't put any priority on bug fixing. But most hobbiest programmers prefer to focus their time on new featues rather than fixing obscure bugs. That's an issue with the people, not the process.
indeed, in most cases it's us, users who do the testing:) still, it's not that company testing is that much better. i think we have all seen crap pathes and changes. i would prefer an attempt at a fix that i would have to test myself (maybe because the developer does not have access to the same hardware) instead of waiting several months or more for some supposedly tested fix (which might be untested on my exact hw/sw combination anyway).
- fixes at all. a lot of vendors just don't fix some problems;
And most open source projects get abandoned. Look around at SourceForge some time. Don't say the code is available, fix it yourself. On a large code base, that's just not a realistic option.
hey, we're talking about linux (the kernel), few things in there really get abandoned, especially in regards to hardware support. hardware vendors drop their support for older products at least at the same rate as projects die on sf (just pulled that one out, but seeing no acpi fixes for a bios that is one year old...)
no need to toss out hardware because vendor has decided to stop supporting it (which happens pretty fast in most cases);
That's much less of an issue if the driver API is stable.
it has been suggested that, if developed, api is kept for some 3 years. i am using latest kernels on a hardware much older than 3 years. besides, 3 years is a long period for development (especially in such a fast moving place as kernel development), but it is a short period for api compatibility. both shortening ang enlarging it are not acceptable solutions, so wouldn't in the long run benefits from stable api be smaller than drawbacks ?
- faster driver availability for new kernel versions (no need to wait for nvidia, for example, to release new version);
That's only an issue because the driver API isn't stable. If there was a stable binary interface, you wouldn't need a new driver from nvidia every time the kernel changed.
but i would need one if i wanted to use latest kernel with older hardware. how long would nvidia or any other hw vendor commit to supporting older hardware ? 3 years ? 5 ? more ? i have an nvidia adapter in one of those boxes. it has at least 6 years, and it still works ok.
- i suppose also changes that improve security, stability & performance are easier to make.
Yes, incompatible changes are much easier to make. But it's only necessary because of the current development model. Kernel developers aren't concerned about getting things right the first time because there is very little penalty to changing things later. Moving towards a stable API implies doing much more planning early on. It's quite likely that this would lead to less work being done overall, as problems are cheaper to fix the earlier they are found.
this would require getting it right for the next, let's say, at least 3 or more years (i suppose for proprietary driver developers to be satisfied it would have to be more like 5 years). and that would include all the possible functionality and hw paradigm changes. power management isn't exactly great right now. with a stable api it would probably be nonexistant...
- much better support (vendors tend to be less interested how
then you are not a kernel developer, are you ? if you were one, you probably would be glad that there is no fixed abi/api. this would be similar like calling every application developer that runs on windows a "windows developer". if you were a kernel developer, your driver would be in kernel, and it would be updated for most changes, at least so i've heard.
as for what benefits not-fixed abi/api gives... i think http://lwn.net/Articles/159313/ has it quite well put (also see comments).
rephrasing what i can remember now (that article probably contains even more) in regards to benefits - but i'll list benefits from a user viewpoint, not a kernel dev viewpoint, where benefits are quite obvious.
- faster, a lot faster fixes than for closed-source drivers; - fixes at all. a lot of vendors just don't fix some problems; - no need to toss out hardware because vendor has decided to stop supporting it (which happens pretty fast in most cases); - faster driver availability for new kernel versions (no need to wait for nvidia, for example, to release new version); - availability of new functionality (like power management and probably a bunch of other things); - i suppose also changes that improve security, stability & performance are easier to make. - driver availability on other architectures (maybe less important for average user, but there were some problematic drivers on amd64 - and i suppose, having usb hw work on some more exotic hw would significantly ease the quest to build home complected low-heat and silent media computer, for example) - much better support (vendors tend to be less interested how their product works than most kernel driver devs) and bigger chances to diagnose the problem - solving problems with proprietary kernel modules is no fun...
and a bigger flexibility and better maintainability of kernel drivers gives kernel developers more time to work on other issues, which in turn give users a lot of indirect benefits:)
so, is your inconvenience (as a proprietary kernel module developer) less important than real kernel developers' and users' (read - _my_;) ) inconvenience ? sorry, but i think it is. proprietary hardware drivers are bad for users in longer term than "now", so if some aspect that is convenient for kernel developers also works as a motivator to get drivers in kernel - well, that is another one good thing. it's not like hw developers will run screaming in joy to write closed drivers if abi/api is made stable. those who are interested, write either closed or opensource drivers anyway, for others a decision like that is more political than technical (actually, providing one or two interested developers with reference hw and documentation would in most cases turn out much better drivers for much less money spent;) )
oh, i know opera people will be reading this thread;) please, please give us an open bugzilla. that will benefit you and that will benefit your users - problems will not be reported 10 times, only 2 or 3;), they will be reproduced and confirmed by more people and so on.
if you feel that some bugs (like security problems) would be much better handled in a non-public way - hey, most security researchers know how to contact security@whatever.org - and you probably could do what novell are doing - a checkbox in a bug submitting form "this should be viewable only by opera" and so on.
it was already mentioned that this pisses off most if not all distros who backpot patches. now, some distros, like suse/opensuse also have non-oss repositories that include opera. i wonder what would they do - and such a failure to disclose timely might piss off distros more, as they can not provide security updates in a timely manner.
i've tried the one in opensuse 10.2 - it does not expand all over the screen:) i didn't like that tabs were switched on mouseover instead of a click, and applications were 'sliding' instead on click of opening on mouseover (makes navigation much, much slower). but, on the other hand, you customise your favorites list, which is most you ever need - and for other things you can use search bar at the top.
suse linux upto opensuse 10.2 (i think 10.0 and 10.1, maybe others) had a classical start menu with a filter field at the top. writing in this field would filter the start menu, shading out menu an program entries that would not correspond to what you had entered. a really great way for finding that ksnapshot, kcalc or superkaramba entry:)
i'm still not sure which one i would prefer in a long run. if i could get tabs on mouseclick and applications popup on mouseover like in the classical menu (even if they pop out of that start menu window), i would seriously consider the new applet (named kickoff, by the way).
for now, i'm on slackware with the classical menu without filtering capabilities;)
well, it is even slightly worse... recently i requested information about wireless chipsets used in adapters manufactured by some prety large and well known company. you know, the information that is easily obtainable once you have the adapter by running lspci, for example. the response was... surprising. "Due to proprietary and copyright policies of our company, this information is not divulged for end users."
Give good names to the features. Give programs names that anyone know what they are.
yes, like... excel. the name itself is not important -
for example GIMP -> Graphics Editor or Photo Processor. Most people don't care if the program is GNU or not or if it is a native K application or Gnome application. So Just give the program a name that we know what it is. If they want to know what it actual program is so they can get new versions outside the distribution There is a Help -> About Appname to get the real name and the version.
...which is exactly what some desktop environments do - at least kde (and i am sure gnome does that, too). take a look at a recent kde menu - depending on how it is setup, it can display name and description. description is exactly what you have suggested - for example, "amarok/audio player", "the gimp/image editor", "firefox/web browser". it is possible to configure k menu to show one of four variants - name only, description only, name (description, description (name). some distributions even ship with the default set to "name only", so all you get in your menu is "image editor", "video player", "audio player" etc.
Which leads to the next problem... Common Menus. Menus need to be in a familiar order. File, Edit, View, Tools, Help. Are common command to change settings they can go to Tools -> Options to reconfigure the program for user settings. If the program has a GUI interface there should be a GUI front end to editing the configurations.
uh. that's the way it is in almost all programs i am using. some exceptions are applications for whom 'file' menu is kinda pointless and so on.
as for tools->options... this quite clearly shows that "i am used to it being that way" is stronger than actual logic or user-friendly behaviour/layout. _why_ should application settings un der tools menu ? is it a tool ? on linux, this is either edit->preferences or there is a top-level menu "settings", which contains options, keyboard shortcuts and so on. mozilla family apps, for example, have options/preferences in tools menu in their windows versions (for familiarity even though that is a bad choice), while linux versions have that in "edit" menu. different situation is with openoffice.org, which has 'options' in 'tools' menu, again - mostly to cater to windows users and their habits. fortunately, openoffice.org has page setup under "format->page", unlike retarted word way of "file->page setup" or how was that called;) (if we talk about word converts, it usually goes like this : "hey, where is page setup ? it was in the file menu in word !" - "well, where would be the most logical place where you would look ?" - and it takes a dozen of seconds at most to find "format->page".
Easy installation of programs. The tools out there for installing apps are great for server use. But for desktop use they are a big pain. Things like install the application and the Icon to the application is in the GUI menu, with the correct icon. Desktop users shouldn't need to hunt down dependencies to get the application to work nor can you assume your application will be part of the distribution list) People want to go the web site download a program and run it.
you either are trolling or haven't used linux in at least 5 years indeed... let me tell you - it goes like this : you open your favorite or shipped package manager; you search for the package you are interested; you click a checkbox next to it. package manager resolves all dependancies and installs them after you click on 'accept' or whatever button. you get icon in your menu. and that's about it. oh, at most you would have to add additional repository if package you are interested in for some reason is not in the default repo - but most distributions have instructions for doing this that your dog could follow. with
the thing, there is no java fault that most developers are shitty. i also have experienced crappy java apps from lucent/avaya, ibm and other "big brands" - on the other hand, i also have seen very nicely coded software that was like "wow. and this is done in java ?".
on example (that i have used only a couple of times) - azuerus. it's fast, it's responsive (especially for java app;) ). then there's tribal trouble - 3d strategy game. yep, that's right, written in java.
i am sure there are many more good examples, so don't judge whole platform bu the worst examples. of course, i have hopes that opensourcing of java will help it to become more stable, faster and so on:)
files on disk ? so it is not an addition to ram, but is instead used as cache for ondisk files, i suppose. using it as a real ram and removing would not leave you with any "files" on disk to mysteriously recover ram contents. simply mirroring on-disk swap also would not be of any benefit, as it either would at least as slow as disk swap itself or it would have 'windows' in time when removing the usb flashdisk would make machine quite... unstable (if it was using some delayed-to-disk-write mechanism).
If the remote server accepts mail, but never actually forwards it (deleting it instead), the source will believe that the mail was correctly delivered.
And how will Microsoft know that... without running software on my server/workstations?
right. but the first question i thought about - why the hell would an intermediate server (isp at most) would delete some mail ? in most situations there are few or no intermediate servers that are not controlled by either sending or receiving party. if there are any and they start silently dropping mail... kick the isp.
"...and quite a lot of that is people wondering why there is no reply to a joke or chain letter."
hey, this time you did not tell me to fsck off ! and you did not threaten to kick me in the nuts if i ever send you another chainletter ! are you allright ? there really are people who expect to get an answer to every dumb, 10 years old joke or worse - chainletter (i man a response that is not offensive) ?
"Actually this is promosing as it would solve the probelm of updaing 1001 desktop and just apply a patch to the firewall to get filtering."...because never ever can anything bad get through or around a firewall. never. really. oh, well. actually this would be kinda funny to see single laptop or some weirdly encoded exploit take down whole network using half a year old exploit;)
btw, how would exploit vs vulnerability ids approaches differ ? you can have all kinds of signatures for snort (and most other ids solutions) - i really don't see how this one could be any different.
well, those reports are just stack traces, which can and can not be helpful to determine the cause. you can register at oo.org qa project (http://qa.openoffice.org/) and submit your bugreports to issuezilla - this way you will know what is the status of your problem.
if you don't feel like doing it yourself, you can send the document to me and i'll try reproducing the crash.
i promise to handle the document appropriately if it is confidential, but you probably know that you should not trust random persons in the internet forums;)
oil for car engine can be changed in any service or by any person. a fact that is irrelevant to 90% of the population... not. imagine only the car manufacturer being able to change oil. would you buy such a car ? and how much would oil change cost ?
hmm. have you reported this issue (or issues) in issuezilla ? can you make the document available for testing ? oo.org team takes application stability and qa very seriously, so it seems surprising that crashes could be unfixed for such a long period.
Slashdot Mirror
i congratulate you on a joke that almost flew over my head :)
if modpoints would not expire exactly before i need them... yeah.
well, as we know, "works" can be defined differently ;)
according to http://openprinting.org/printer_list.cgi?make=HP
there are some hp printers in paperweight category, a couple in 'partially' and a lot in 'mostly' working categories.
i actually am basing my purchasing decisions on these lists in addition to other information sources, and i usually consider only devices in "perfectly" category.
additionally, i prefer devices that work with cups outofthebox, though this is harder to achieve.
"The original poster was quite correct that the GPL is a minefield."
just like any other licence. except maybe public domain, which isn't exactly a license as such.
"...then there are going to be some legal issues to watch out for, and legal issues that don't have really clear answers because the GPL is unlike any other "license agreement" that came before."
it is unlike in some aspects, but in general, almost all licence agreements that exceed two sentences have weird clauses, clauses that are open to misinterpretation and so on.
of course, one must remember that modifications to gpl code must be released to parties to whom changed code is shipped to - it is perfectly valid to modify gpl code, and keep modifications secret. until you distribute it.
overall i agree with your post - if a company is not obviously intentionally violating licence terms and is openly working to comply, that should be praised.
a-hha. crop circle origins discovered.
"Suppose we have another Alexandrian library fire (maybe thanks to Islamicists this time) and we collectively forget about the nasties buried deep underground - until some enterprising miners in a newly emerging industrial society find out the hard way."
;) ), but it was the content that was very interesting.
t ml
this immediately reminded me of a material i was reading some time ago. after a long search i found the text - but it had pictures, envisioning different designs and concepts. the design was pretty awful (and current text page also is badly formatted
so, here's the text only :
http://www.physics.uci.edu/~silverma/benford.html
if anybody knows where this material could be found with the images of concepts, please, post here. the images really help to better envision the magnitude of the problem (though the text is very good and descriptive, too).
it seems that something from those suggestions is accepted :
http://www.ocrwm.doe.gov/factsheets/doeymp0115.sh
indeed, in most cases it's us, users who do the testing :)
still, it's not that company testing is that much better. i think we have all seen crap pathes and changes.
i would prefer an attempt at a fix that i would have to test myself (maybe because the developer does not have access to the same hardware) instead of waiting several months or more for some supposedly tested fix (which might be untested on my exact hw/sw combination anyway).
hey, we're talking about linux (the kernel), few things in there really get abandoned, especially in regards to hardware support.
hardware vendors drop their support for older products at least at the same rate as projects die on sf (just pulled that one out, but seeing no acpi fixes for a bios that is one year old...)
it has been suggested that, if developed, api is kept for some 3 years. i am using latest kernels on a hardware much older than 3 years. besides, 3 years is a long period for development (especially in such a fast moving place as kernel development), but it is a short period for api compatibility. both shortening ang enlarging it are not acceptable solutions, so wouldn't in the long run benefits from stable api be smaller than drawbacks ?
but i would need one if i wanted to use latest kernel with older hardware. how long would nvidia or any other hw vendor commit to supporting older hardware ? 3 years ? 5 ? more ?
i have an nvidia adapter in one of those boxes. it has at least 6 years, and it still works ok.
this would require getting it right for the next, let's say, at least 3 or more years (i suppose for proprietary driver developers to be satisfied it would have to be more like 5 years). and that would include all the possible functionality and hw paradigm changes. power management isn't exactly great right now. with a stable api it would probably be nonexistant...
then you are not a kernel developer, are you ? if you were one, you probably would be glad that there is no fixed abi/api.
:)
;) ) inconvenience ? sorry, but i think it is. ;) )
this would be similar like calling every application developer that runs on windows a "windows developer".
if you were a kernel developer, your driver would be in kernel, and it would be updated for most changes, at least so i've heard.
as for what benefits not-fixed abi/api gives...
i think http://lwn.net/Articles/159313/ has it quite well put (also see comments).
rephrasing what i can remember now (that article probably contains even more) in regards to benefits - but i'll list benefits from a user viewpoint, not a kernel dev viewpoint, where benefits are quite obvious.
- faster, a lot faster fixes than for closed-source drivers;
- fixes at all. a lot of vendors just don't fix some problems;
- no need to toss out hardware because vendor has decided to stop supporting it (which happens pretty fast in most cases);
- faster driver availability for new kernel versions (no need to wait for nvidia, for example, to release new version);
- availability of new functionality (like power management and probably a bunch of other things);
- i suppose also changes that improve security, stability & performance are easier to make.
- driver availability on other architectures (maybe less important for average user, but there were some problematic drivers on amd64 - and i suppose, having usb hw work on some more exotic hw would significantly ease the quest to build home complected low-heat and silent media computer, for example)
- much better support (vendors tend to be less interested how their product works than most kernel driver devs) and bigger chances to diagnose the problem - solving problems with proprietary kernel modules is no fun...
and a bigger flexibility and better maintainability of kernel drivers gives kernel developers more time to work on other issues, which in turn give users a lot of indirect benefits
so, is your inconvenience (as a proprietary kernel module developer) less important than real kernel developers' and users' (read - _my_
proprietary hardware drivers are bad for users in longer term than "now", so if some aspect that is convenient for kernel developers also works as a motivator to get drivers in kernel - well, that is another one good thing.
it's not like hw developers will run screaming in joy to write closed drivers if abi/api is made stable. those who are interested, write either closed or opensource drivers anyway, for others a decision like that is more political than technical (actually, providing one or two interested developers with reference hw and documentation would in most cases turn out much better drivers for much less money spent
"If they unearthed pristine copies of VisiCalc floppies they would probably be pissed off that somebody buried trash in their back yard."
:)
of course they would. they probably would have never seen a floppy in their lives and there was no floppy drive in existance at that point
oh, i know opera people will be reading this thread ;) ;), they will be reproduced and confirmed by more people and so on.
please, please give us an open bugzilla. that will benefit you and that will benefit your users - problems will not be reported 10 times, only 2 or 3
if you feel that some bugs (like security problems) would be much better handled in a non-public way - hey, most security researchers know how to contact security@whatever.org - and you probably could do what novell are doing - a checkbox in a bug submitting form "this should be viewable only by opera" and so on.
it was already mentioned that this pisses off most if not all distros who backpot patches.
now, some distros, like suse/opensuse also have non-oss repositories that include opera. i wonder what would they do - and such a failure to disclose timely might piss off distros more, as they can not provide security updates in a timely manner.
i've tried the one in opensuse 10.2 - it does not expand all over the screen :)
:)
;)
i didn't like that tabs were switched on mouseover instead of a click, and applications were 'sliding' instead on click of opening on mouseover (makes navigation much, much slower).
but, on the other hand, you customise your favorites list, which is most you ever need - and for other things you can use search bar at the top.
suse linux upto opensuse 10.2 (i think 10.0 and 10.1, maybe others) had a classical start menu with a filter field at the top. writing in this field would filter the start menu, shading out menu an program entries that would not correspond to what you had entered. a really great way for finding that ksnapshot, kcalc or superkaramba entry
i'm still not sure which one i would prefer in a long run. if i could get tabs on mouseclick and applications popup on mouseover like in the classical menu (even if they pop out of that start menu window), i would seriously consider the new applet (named kickoff, by the way).
for now, i'm on slackware with the classical menu without filtering capabilities
obviously, you meant port to qt 4.2 :)
summary is wrong.
well, it is even slightly worse... recently i requested information about wireless chipsets used in adapters manufactured by some prety large and well known company. you know, the information that is easily obtainable once you have the adapter by running lspci, for example.
the response was... surprising.
"Due to proprietary and copyright policies of our company, this information is not divulged for end users."
yes, like... excel. the name itself is not important -
it is possible to configure k menu to show one of four variants - name only, description only, name (description, description (name).
some distributions even ship with the default set to "name only", so all you get in your menu is "image editor", "video player", "audio player" etc.
uh. that's the way it is in almost all programs i am using. some exceptions are applications for whom 'file' menu is kinda pointless and so on.
;) (if we talk about word converts, it usually goes like this : "hey, where is page setup ? it was in the file menu in word !" - "well, where would be the most logical place where you would look ?" - and it takes a dozen of seconds at most to find "format->page".
as for tools->options... this quite clearly shows that "i am used to it being that way" is stronger than actual logic or user-friendly behaviour/layout. _why_ should application settings un der tools menu ? is it a tool ?
on linux, this is either edit->preferences or there is a top-level menu "settings", which contains options, keyboard shortcuts and so on.
mozilla family apps, for example, have options/preferences in tools menu in their windows versions (for familiarity even though that is a bad choice), while linux versions have that in "edit" menu.
different situation is with openoffice.org, which has 'options' in 'tools' menu, again - mostly to cater to windows users and their habits.
fortunately, openoffice.org has page setup under "format->page", unlike retarted word way of "file->page setup" or how was that called
you either are trolling or haven't used linux in at least 5 years indeed...
let me tell you - it goes like this : you open your favorite or shipped package manager; you search for the package you are interested; you click a checkbox next to it. package manager resolves all dependancies and installs them after you click on 'accept' or whatever button.
you get icon in your menu. and that's about it. oh, at most you would have to add additional repository if package you are interested in for some reason is not in the default repo - but most distributions have instructions for doing this that your dog could follow. with
you didn't read whole comment, now did you ? :)
the thing, there is no java fault that most developers are shitty. i also have experienced crappy java apps from lucent/avaya, ibm and other "big brands" - on the other hand, i also have seen very nicely coded software that was like "wow. and this is done in java ?".
;) ).
:)
on example (that i have used only a couple of times) - azuerus. it's fast, it's responsive (especially for java app
then there's tribal trouble - 3d strategy game. yep, that's right, written in java.
i am sure there are many more good examples, so don't judge whole platform bu the worst examples.
of course, i have hopes that opensourcing of java will help it to become more stable, faster and so on
i suspect after 20 minutes i would start singing. bad is not the correct word here, though i can do it really loud.
files on disk ?
so it is not an addition to ram, but is instead used as cache for ondisk files, i suppose. using it as a real ram and removing would not leave you with any "files" on disk to mysteriously recover ram contents.
simply mirroring on-disk swap also would not be of any benefit, as it either would at least as slow as disk swap itself or it would have 'windows' in time when removing the usb flashdisk would make machine quite... unstable (if it was using some delayed-to-disk-write mechanism).
right. but the first question i thought about - why the hell would an intermediate server (isp at most) would delete some mail ?
in most situations there are few or no intermediate servers that are not controlled by either sending or receiving party. if there are any and they start silently dropping mail... kick the isp.
"...and quite a lot of that is people wondering why there is no reply to a joke or chain letter."
hey, this time you did not tell me to fsck off ! and you did not threaten to kick me in the nuts if i ever send you another chainletter ! are you allright ?
there really are people who expect to get an answer to every dumb, 10 years old joke or worse - chainletter (i man a response that is not offensive) ?
"Actually this is promosing as it would solve the probelm of updaing 1001 desktop and just apply a patch to the firewall to get filtering." ...because never ever can anything bad get through or around a firewall. never. really. ;)
oh, well. actually this would be kinda funny to see single laptop or some weirdly encoded exploit take down whole network using half a year old exploit
btw, how would exploit vs vulnerability ids approaches differ ?
you can have all kinds of signatures for snort (and most other ids solutions) - i really don't see how this one could be any different.
well, those reports are just stack traces, which can and can not be helpful to determine the cause.
;)
you can register at oo.org qa project (http://qa.openoffice.org/) and submit your bugreports to issuezilla - this way you will know what is the status of your problem.
if you don't feel like doing it yourself, you can send the document to me and i'll try reproducing the crash.
i promise to handle the document appropriately if it is confidential, but you probably know that you should not trust random persons in the internet forums
oil for car engine can be changed in any service or by any person. a fact that is irrelevant to 90% of the population... not.
imagine only the car manufacturer being able to change oil. would you buy such a car ? and how much would oil change cost ?
not that it deters most of them from pirating most of the software anyway ;)
hmm. have you reported this issue (or issues) in issuezilla ? can you make the document available for testing ?
oo.org team takes application stability and qa very seriously, so it seems surprising that crashes could be unfixed for such a long period.