Melchior FRANZ wrote:
Frankly, I don't see how (d) can compete with (c), which is
used and cared for by several Linux distributions as well as
used and tested by several million people. Do we really want
to pull in maintainership of our own OpenAL implementation
(for no good reason)? And
Melchior FRANZ wrote:
Frankly, I don't see how (d) can compete with (c), which is
Yeah yeah, By the second time I got the message ;)
Erik
(Sorry, I couldn't resist)
-
This SF.Net email is sponsored by the Moblin Your
Melchior FRANZ wrote:
True, I'm sorry. The ultimate question is really only: can
we drop our current workarounds for buggy implementations,
and rely on a clean spec-compliant (i.e. working) OpenAL
version, and point people to an URL where this can be found
for optimal results. Ideally, this
Melchior FRANZ wrote:
* Erik Hofman -- Friday 24 October 2008:
the remaining problem might be hardware accelerated 3d
audio support from the Creative drivers. If that version
fails, then what?
Ugh ... no idea about that. Wouldn't implementations like
openal-soft care for that as well
Melchior FRANZ wrote:
* Erik Hofman -- Friday 24 October 2008:
Yeah yeah, By the second time I got the message ;)
In case you are referring to mail duplicates: As you can see
on the message ids, I didn't send it twice. This is a bug
in the sourceforge.net mail handling:
http
Vladimir Karmishin wrote:
Hello !
I'm still digging into FlightGear sound subsystem. :-)
Today, I make a small modification in AI Aircrafts, to let them
produce some noise.
This encouraged me to look at the FGFX change I made before but which
turned out to be less than ideal. I think
Vladimir Karmishin wrote:
Can you rememer back, is SGSoundMgr::set_source_pos_all( ALfloat
*pos ); is sort of hack, assuming
everything is happening inside cabin, or it's just sources enumerator,
which pass through a map
of loaded sounds updating their positions ? Of course I can play
Vladimir Karmishin wrote:
I need any thoughts,
imaginations about which way can it be modified to let it work with
multiple 3d sound emitters.
Reading this again there might be some confusion; aircraft can have
multiple 3d sound emitters already, they are just tied to the main
aircraft
Vladimir Karmishin wrote:
As I see around - the more and more of projects are moving
away from ALUT, and probally FG has to do it some time.
So, why not to start movement process now :-)
I find it rather annoying to have to move away from ALUT just because
Apple can't play nice. Bad for
Melchior FRANZ wrote:
* Erik Hofman -- Monday 20 October 2008:
I find it rather annoying to have to move away from ALUT just because
Apple can't play nice. Bad for them, let them straighten it out if they
don't obey the the specs. I vote against this.
The problem seems
Vladimir Karmisin wrote:
Eric, the only problem with ALUT - it is not a part of OpenAL, and
it doesn't have any strict specs. So nobody can guarantee it's reliability.
In fact, I have to agree with Melchior FRANZ, about the whole OpenAL
subsystem. Since Creative abadoned the development -
James Turner wrote:
On 20 Oct 2008, at 15:30, Erik Hofman wrote:
The main problem is that Apple never removed the alut functions from
their OpenAL library causing linking conflicts wehn linking both
freealut and OpenAL.
Well, to be fair that's to preserve binary compatibility. I work
Vladimir Karmisin wrote:
James, if it doesn't mean problem for you, could You send me your
framework and SG patches ?
About libsnd - Yes, you may be right in case of libsndfile. I've coded a
simple WAV reader,
which does nothig but read uncompressed wav file and fill out OpenAL
buffer
Vladimir Karmishin wrote:
Erik, it's just a simple startup code right now. Written only for test
purposes for myself.
Of course, if I feel I want to get it included in FG I'll polish it
and take a care
of endiannes. But thanks you for the care :-)
Actually I do have code laying around
Melchior FRANZ wrote:
aircraft.livery and aircraft.livery_update are now only
wrappers for more generic classes, which one can also
use directly instead. They allow to manage more than just
livery XML files. One could allow users to choose a
livery, seat covers, flight attendant uniforms,
Detlef Faber wrote:
It works extremly well, take a look at the F4U, it has livery selection
plus Logo selection.
It doesn't, I looked at a number of aircraft that use it and somehow it
doesn't apply to they way I have set op the PC-7. Not matter what I try.
After two days I lost interest.
Melchior FRANZ wrote:
* Melchior FRANZ -- Sunday 19 October 2008:
What was probably broken were your material animations
Patch attached ... s/object/object-name/
duh :(
anyway, thanks for the patch.
Erik
-
This
Heiko Schulz wrote:
I noticed the same effect when I tried to play a bit with the textures. I
tried some new one. Even when I saved them as .rgb or .rgba the textures
were screwed up. It seems for me that there is something hardcoded *on* the
textures- could that be?
I wouldn't be
Stefan Seifert wrote:
Hi,
attached is a little patch for the f16. It's VRP is obviously wrong, when
watching turns on the ground from outside. I did standard
slipping-of-the-edge tests and found an x-value of -180in to improve the
situation a lot.
Thanks, it's added tot the latest
Vivian Meazza wrote:
It's been possible to attach a sub-submodel to a submodel for some time now
(a year or so). See data\Aircraft\seahawk\Models\seahawk-submodels.xml and
data\Aircraft\seahawk\Models\seahawk-subsubmodels.xml to see how it's done.
Submodels are hard on frame rates, so if
Heiko Schulz wrote:
(wonders if Erik knows that we moved from plib to OSG... :-P)
I think I remember something like that .. :)
I've been busy for more than a year (maybe two) and didn't pay much
attention to FlightGear during that period.
Erik
gerard robin wrote:
That made me to open that topic Only to remember, that FG version 1.0.0 is
not the past.
FG plib Version 1.00 could get profit of that lot of improvements which are
included into FG OSG for instance the new JSBSim, the key features, the
Nasal improvement, and so on...
gerard robin wrote:
OSG script can be very complex with animations into animations regarding
particles shapes, particles colors ... and so on.
This is what I have been missing when playing with submodel particles;
when ejecting a flare I can get the flashlight modeled correctly but
all
I tried the imposters/billboards patch fro 3d clouds but didn't get the
problem you reported. It does make flightgear dog-slow however, 1 or 2
fps maximum. I played a bit with the rendering options but none of the
options did make any difference in frame rate (not even setting the
cloud
Stuart Buchanan wrote:
If you are doing all that work, it might be worth de-coupling the c172p from
all the other c172 Aircraft in CVS (c172, c172r), so it is self-contained and
we only have to include a single directory.
Actually I thought I had done that already quite some time ago?
Ron Jensen wrote:
Take a look at converting over from panels to OSG hotspots.
Just to be sure, is this the ´pick animation' or yet another method?
Erik
-
This SF.Net email is sponsored by the Moblin Your Move
Ron Jensen wrote:
On Sun, 2008-10-05 at 18:13 +0200, Erik Hofman wrote:
Ron Jensen wrote:
Take a look at converting over from panels to OSG hotspots.
Just to be sure, is this the ´pick animation' or yet another method?
Sorry for not being clear. Yes it is the pick animation.
No problem
Alexis Bory - xiii wrote:
Hi all, here is a major update for the Tomcat. (feed back welcome)
I must say this looks to be a great addition to FlightGear, great work!
I haven't spent much time with it yet since i've been working on my own
models but I did lend some gauges :)
Erik
Alexis Bory - xiii wrote:
Erik Hofman wrote:
Alexis Bory - xiii wrote:
Hi all, here is a major update for the Tomcat. (feed back welcome)
I must say this looks to be a great addition to FlightGear, great
work! I haven't spent much time with it yet since i've been working
on my own
Let me emphrase that OSG is the way forward and there is no going back.
Really.
That said, I did some updates to the 1.0 branch to get it in sync with
the base package in CVS.
It really was a trivial task and took no more than a few minutes.
Whether there will be a 1.1 release or not is not for
Let me emphrase that OSG is the way forward and there is no going back.
Really.
That said, I did some updates to the 1.0 branch to get it in sync with
the base package in CVS.
It really was a trivial task and took no more than a few minutes.
Whether there will be a 1.1 release or not is not
gerard robin wrote:
BTW: regarding JSBSim i am trying to implement the new FDM within the FG
stable version , it should work.
I just committed the CVS version of JSBSim to the 1.0 branch.
It looks like the latest version of nasal is already present?..
Next step is to commit YASim from the OSG
Would it be feasible to reserve the 'a' for aircraft specific and 'x'
for experimental features?
Erik
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based
Melchior FRANZ wrote:
* Erik Hofman -- Thursday 02 October 2008:
Would it be feasible to reserve the 'a' for aircraft specific and 'x'
for experimental features?
'x' for experimental seems fine. 'a' for aircraft is a problem, as I
think we should keep using that for the autopilot
Vivian Meazza wrote:
I'm profiling with absolutely _everything_ disabled (including replay). _If_
that had shown that the stagger went away I would have reintroduced features
one by one. But I can't even get that far atm. Still trying though, and
still trying to identify the cause. I note,
Curtis Olson wrote:
What aircraft is being flown in these tests? If hash.c looks like a
hotspot, that could also be triggered by an aircraft that had a lot of
new nasal code added. Or it could be newly added default system nasal
code? I don't know how much of FlightGear functions
Vivian Meazza wrote:
Er ... couple of words spring to mind there - grandmother and eggs :-). But
I know that you are trying to help.
Alright, I'm just about to lay down activities for FlightGear for the
second time (and now for good) because of this statement. There was a
time where i
Tim Moore wrote:
I think you misunderstand the sense of the idiom teaching your grandmother
to
suck eggs. It implies nothing about the maturity of the teacher. Vivian
meant
that you were treating him like a child -- that's the teaching an elderly
person
to suck eggs part -- but I
Martin Spott wrote:
Syd,
Converting to OSG , a lot of small updates stll to do...
Added a simple nasal gpws since the mk-viii appears to misbehave...
Did you already communicate the issue about the MK-VIII to other
developers in order to get it fixed ?
Yes, please report any
Heiko Schulz wrote:
So much as I know James Turner is working on that.
And the MKVIII was never ever working right, I can understand Syd doing a
workaround.
Last time I heard he was awaiting feedback.
Erik
-
This
Vivian Meazza wrote:
As you know, I am. I have profiled the cvs-head. Nasal/hash.c seems to be a
_very_ significant CPU hog, but I can't link it to the staggers. I note
however that when I profile an old FG/osg from last Apr, it is stagger free,
and hash.c doesn't figure in the profiling.
Syd wrote:
In the meantime , IRC is a much freindlier , helpful place.
Unfortunately IRC (like the forum) is not the place where problems are
solved, only the developers mailinglist is. This is because not everyone
can follow all he places where discussions are taking place.
Erik
dave perry wrote:
After updating SimGear and fgfs source from cvs this morning, the 3D
instruments in the pa24-250 and pa28-161 disappear and reappear
depending on the the viewing angle. This was not the case with cvs from
a week ago. After seeing this anomaly, I updated OpenSceneGraph
Curtis Olson wrote:
Hi Erik,
I just took off in the default cessna 172 and once airborne the engine
sound got really goofy. It was almost like there was a small positional
jitter going on that was triggering the doppler effect, producing a
wobbly pitch of the sounds.
The problem with
AJ MacLeod wrote:
On Friday 05 September 2008 10:23:05 Erik Hofman wrote:
Let me know if someone still got strange sound effects.
Hi Erik,
I still get broken sound, most notably with the F-16. I captured a sample so
you could hear it;
http://www.adeptopensource.co.uk/personal/fg
Fabian Grodek wrote:
On 9/4/08, *Alex Romosan* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Erik Hofman writes:
Alex Romosan wrote:
can you give me a pointer as to where i could get this data? thanks.
Search for NASA Technical Paper 1538
i've
Syd wrote:
Hello ,
After a recent update (within the week), I'm getting some really choppy
sounds in my b1900d and dhc-2 . I know there were changes to the sound
system , but don't know if that's the problem.
The only thing that did happen was moving the sound update code from the
main
Alex Romosan wrote:
can you give me a pointer as to where i could get this data? thanks.
Search for NASA Technical Paper 1538
Erik
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build
Fabian Grodek wrote:
Erik,
In the F16 aero config file I see there's indeed an increase in lift
for certain speedbrakes deflection, accompanied by the expected huge
increase in drag. But I don't see any pitching moment effect; from
what I see in NASA TP 1538
Alex Romosan wrote:
i hate to bring this up again but i still think the speedbrakes don't
work as they should, instead generating quite a lot of lift. i've
tested this on final approach at about 160-170 knots, speedbrakes on;
i can keep the plane level. retract the speedbrakes, the plane
Alex Romosan wrote:
Erik Hofman writes:
Believe me, this is correct behavior, and this is why:
i found a nice article about flying in an f16:
http://www.avweb.com/news/skywrite/181916-1.html
this is the part about the speed brakes:
Here's where the speed brakes come in handy
gerard robin wrote:
A Only my 2 cents, if the question is not stupid :)
How does the fly-by-wire, regarding the speedbrake lift effect ?
What happens (with regard to the fly-by-wire system) is this:
Speedbrake deflection causes a pitching moment which the FCS
automatically compensates
Alex Romosan wrote:
Erik Hofman writes:
Alex Romosan wrote:
I felt what happens! It seemed my face was being pulled from my
skull. I couldn't believe how effective those speed brakes were. An
F-16's speed brakes are located at the back of the fuselage either
side of the engine
Erik Hofman wrote:
Erik Hofman wrote:
+X = down, -X = up
Shoot, this should be:
-X = down, +X = up
This is getting embarrassing .. forget about it, it was described
properly (just like in the README file).
It's getting worse, there were local changes in my SimGear tree
Maik Justus wrote:
Hi Erik,
Erik Hofman schrieb am 21.08.2008 14:25:
Hi,
...
There are two options, modify the code to reflect what is described in
README.xmlsound or modify the README file.
I would prefer to modify the README file. I made some asymmetric sound
for helicopters (S58
Another update: the inner-angle and outer-angle range from 0-180 degrees
instead of 0-360 degrees.
Erik
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based
gerard robin wrote:
I mainly wonder if the basic calculation for the g-load is right. I have
copied from the F16 (by Eric) the g load corrected which is
summer name=g load corrected
inputaccelerations/n-pilot-z-norm/input
input-fcs/n-pilot-z-correction/input
/summer
It si both right
Hi,
I'm working on proper Listener positioning for sound playback in
FlightGear and encountered a difference between the coordinate system
described in README.xmlsound (which describes a right handed system that
doesn't exists, it describes a left handed system instead) and the
actual
James Turner wrote:
On 21 Aug 2008, at 13:25, Erik Hofman wrote:
I'm working on proper Listener positioning for sound playback in
FlightGear and encountered a difference between the coordinate system
described in README.xmlsound (which describes a right handed system
that
doesn't exists
gerard robin wrote:
Hello,
Does anybody, here, knows, how to know, which .ac model/object gives the
following warning message, during FG loading ?
osgDB ac3d reader: detected surface with less than 3 vertices!
Which model/object name is involved?
It is rather easy when the AC is
James Turner wrote:
On 21 Aug 2008, at 13:33, Erik Hofman wrote:
I knew it! :)
Ok, I' l take a look at that, good idea.
One of the things on my medium-term list is to carry on the subsystem-
ification work. To reach the ultimate goal (mainloop just does
'update' on the subsystemgr
James Turner wrote:
Ah, what I was really hoping to do, was to break the dependency on the
FGViewer, and globals-get_aircraft_model(), by getting the equivalent
position and orientation from the property tree. I haven't checked how
straightforward that is, but having the sound code so
James Turner wrote:
On 21 Aug 2008, at 17:50, Erik Hofman wrote:
But .. it might well be in this case.
No, I'm not sure either, it was just a gut feeling that depending on
FGViewer was a bit weird, for sound code.
Well, it's called a Listener for OpenAL, but they are both located
John Denker wrote:
5) Using textranslate to implement the frequency digits on a digital radio is
still a
kludge. The xml required to do this is long-winded, to say the least. The
patches
presented here do not remove the pressure for a nicer api. Some sort of
sprintf and
substr
Erik Hofman wrote:
If I understand this correctly I think FlightGear already provides a way
to do that. I've recently attached a 2d-panel text animation to a 3d
model to display all sorts of text information in an Data Entry Display
(DED).
See FlightGear/data/Aircraft/f16/Models/ded
Hi,
I have been busy updating the F-16 flight computer lately which turned
out the have quite some problems. After extensive (and many, many hours
of) work I'm pleased to announce it is finished now. I know others have
been using this FDM to model other aircraft, so I've added a bit of
Tim Moore wrote:
They are using the new feature that allows a generic protocol
playback file to be played back in an infinite loop.
Nice going!
I think I've heard this announced a few weeks back .. ;-)
Indeed, nice going. Both for ATI and for the FlightGear contributors.
Erik
Hi,
Ever since I switched to the CVS version of FlightGear I wondered
whether the black-out behavior really is that realistic . Although I
never experienced it I couldn't imagine this would happen in real life,
at least not with an anti-g suit.
In an excerpt from a nasa document describing a
Ok, I think I have most of it figured out. I might even consider
upgrading the status to 'production' the way it is now.
Erik
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest
Alex Romosan wrote:
hmm, i don't know how the real f-16 behaves but i still find the
current behaviour a bit strange. level flight, ~350 knots extend the
brakes the aircraft pitches up slightly and really starts to climb (no
effect on the speed at all). push the nose down (quite a lot) to
Ok, tested it again. The only way I could reproduce your scenario is not
to have the throttle near idle.
As I did state earlier, the speeedbrakes of the F-16 are quite small and
as it turns out the engine can easily produce enough thrust to overcome
the increased drag.
Erik
Alex Romosan wrote:
i think there is still something wrong with the speedbrakes but i am
not sure how to quantify this. basically i think they provide way too
much lift (which makes me suspect there is a sign problem somewhere).
the effect is more pronounced at slower speeds (250 - 300 knots
Jon S. Berndt wrote:
Erik worked on the F-16 quite a bit this past couple of weeks (with some
good comments supplied to help narrow down the problem) and it appears to be
flying well, now. I know this model has given some strange behavior in the
past. Hopefully, that's behind us.
Actually I
Jon S. Berndt wrote:
I'm looking for a few high quality (fairly large) screen shots of JSBSim
aircraft models in FlightGear. Can anyone point me to some? I want to use
them as background illustrations in the JSBSim manual now being drafted.
I've put a few screenshots of the F-16 over here:
Tatsuhiro Nishioka wrote:
So here is my suggestion.
First, we use my patch as a temporal fix just to prevent the fps drop.
Second, we investigate a reasonable means of loading and unloading AIModels
on reset (and remove my patch).
Any opinions?
Sounds good to me.
Erik
James Turner wrote:
Yeah, I've also (just) been looking at the state of the art in SVG -
GL rendering. I was hoping to find something reasonably compact, but
there's various dead links and so on.
This might be exactly what you need:
http://fabrice.bellard.free.fr/TinyGL/
Erik
Tatsuhiro Nishioka wrote:
Hi forks,
I've encountered a weird fps drop in resetting on Nimitz (with
--carrier=Nimitz).
It happens since AIBase loads AIModels on every reset, which should not.
The same problem happened on 0.9.11-pre2 and I made a patch to fix it, but
the patch was not
Alex Romosan wrote:
i noticed that on the f16 the speedbrakes have no effect at all and i
managed to track it down to the fact that the various coefficients use
fcs/mag-speedbrake-pos-rad on input which never gets set anywhere (so
it is always 0).
digging through the cvs logs i found that
Alex Romosan wrote:
Erik Hofman writes:
Looking at the code it looks like setting speed-break-pos-norm should be
the same as setting speed-break-pos-rad so the patch shouldn't have any
effect.
look at aero/coefficient/CDDsb or fcs/mag-speedbrake-pos-rad in the
property browser. when
Alex Romosan wrote:
Erik Hofman writes:
Looking at the code it looks like setting speed-break-pos-norm should be
the same as setting speed-break-pos-rad so the patch shouldn't have any
effect.
look at aero/coefficient/CDDsb or fcs/mag-speedbrake-pos-rad in the
property browser. when
Tim Moore wrote:
To add my two cents:
I mostly favor putting using declarations at the top of source files
instead
of using namespace qualifiers in the code. On the other hand, I would
probably
use the namespace qualifer explicitly if the symbol in question is somewhat
obscure, to give
To continue this discussion a bit (please add your comments) James an I
had a short discussion about using std::string (for example) everywhere
in the file or using using std::string; at the beginning. James
pointed out that the suing std:: statement in header files might not be
a good idea,
Melchior FRANZ wrote:
* Erik Hofman -- Wednesday 30 July 2008:
To continue this discussion a bit (please add your comments) James an I
had a short discussion about using std::string (for example) everywhere
in the file or using using std::string; at the beginning.
I think this shouldn't
James Turner wrote:
I think this is a good example of why 'using std::xxx' is potentially
problematic in headers (especially public library headers, i.e
Simgear), but fine in sources. So if I'm doing future cleanups, that's
the approach I'd take - remove 'using' from headers, and add it
I've now committed two patches provided by James Turner that does a lot
of header and declaration cleanups;
* SG_USING_STD is now replaced by: using std::
* SG_GL_H is replaced by osg/GL
* SG_GLU_H is replaces by osg/GLU
* All STL_* includes are replaced by their proper names
As far as I
Melchior FRANZ wrote:
Just for the record: the old HUD will also be removed very soon,
probably within the next two weeks. I only have to check what
needs to get ported first. (The f16 is one such candidate. :-)
Yeah I know it uses the old HUD, but I didn't even know there was a
new
Durk Talsma wrote:
Just for your information, I just reverted FDM/SP/Makefile.am back to it's
original shape. I'd been a bit too quick in deciding these two FDMs had been
removed altogether, but now I see they are back. :-)
Melchior pointed out to me I had forgotten to add these files
Durk Talsma wrote:
I did just remove a reference to FDM/Balloon/ in Main/Makefile.am, which
looks
like a genuine leftover from the old situation...
Thats ok, somehow this didn't show up in my build..(?)
Erik
-
This
Durk Talsma wrote:
Is it possible you still have the library there from an older build?
That could well be.. good thinking.
Erik
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the
Hi,
I was about to move the BalloonSim and MagicCarpet fdm's to the Special
Purpose directory but since JSBSim now supports balloons:
Are these fdm's still used for anything?
I know MagicCarpet was used for scenery browsing but I think is has been
replaced by the UFO hasn't it?
Erik
James Turner wrote:
The key question is, are all of the above #defines safe to be killed?
And are there any others I've missed? There's occasional references to
Borland and IRIX compilers (i.e ancient versions of gcc, like pre
3.x!) in some #defines which I guess could also be cleaned
James Turner wrote:
Patch to remove macintosh and MWERKS from Simgear.
Tested on Mac only - I'd verify Linux compilation normally but
currently travelling.
Tested for Linux and committed.
Note, screen/colours.h contains some code relating to gamma which
looks very, very unlikely to be
Hi,
Now that I've installed the CVS version of FlightGear I noticed a few
things;
* I don't have 3d clouds and shrub/tree cover anymore.
Is this based on shaders these days?
* Rain/Snow is rendered like dots on my system (not like the screenshots
I've seen) and doesn't originate at the
AJ MacLeod wrote:
The F-16 looks good here - the only transparency problem I can find is with
the star and bars markings (bottom right of f16.rgb) and that could easily be
worked round by removing the transparency in that part of the texture.
It sounds like you're seeing something much
Detlef Faber wrote:
This is most likely sorting order. I usually fix this by putting the
transparent parts in a seperate xml file and load it at the very end of
my model.xml file. This works with plib too.
Avoid transparent parts in textures. Weird things can happen.
Ok, thanks for the
The README.xmlpanel file shows what I already seemed to remember:
Regarding Window Geometry:
-
For the sake of simplicity the FGFS window is always considered to be
1024x768 so all x/y values for instrument placement should relative to
these dimensions. Since FG
Curtis Olson wrote:
Is it possible to leverage the --generic protocol to automatically
replay a flight from a data file created originally with the --generic
protocol? If so, does anyone have an xml config file setup to capture
all the important variables?
I once created a quick hack at
Melchior FRANZ wrote:
It's well known that Nasal has an io module with wrappers around
fopen(), fclose(), etc. An aircraft that you install, or even
scenery objects with embedded Nasal could in the past use this
to delete the contents of your whole home directory, or to append
commands to
Melchior FRANZ wrote:
* Sven Almgren -- Monday 16 June 2008:
like --io-read=/myDir --io-read=/tmp --io-write=/etc/passwd ?
One could, of course, use this instead:
--prop:io-read=/myDir --prop:io-read[1]=/tmp ...
I don't consider any command line option a security thread since writing
to
Melchior FRANZ wrote:
It's funny that nobody cared a year long, and now that the danger
is supposed to be banned, people get scared and nervous. :-}
I don't, I just though I could help here.
Erik
-
Check out the new
801 - 900 of 1053 matches
Mail list logo
