On 11/26/2012 12:15 PM, Richard W.M. Jones wrote:
You're asking for something very open-ended, and which is not even
possible to implement in general -- what if the inspecting operating
system is Linux, and the inspected operating system needs custom Mac OS X
libraries?
Perhaps I am just
On Wed, Nov 28, 2012 at 01:43:48PM +0100, Simon Lukasik wrote:
On 11/26/2012 12:15 PM, Richard W.M. Jones wrote:
You're asking for something very open-ended, and which is not even
possible to implement in general -- what if the inspecting operating
system is Linux, and the inspected
Hi Simon,
On 28.11.2012 14:43, Simon Lukasik wrote:
I can't see how this is related to my latest post. And I can't see what
leads you to think that cross-platform scanning is feasible today
(standard-wise and performance-wise).
Please check this very informative post from Steve (OVAL board
On 11/25/2012 05:12 PM, Richard W.M. Jones wrote:
On Fri, Nov 23, 2012 at 11:43:01AM +0100, Simon Lukasik wrote:
On 11/22/2012 09:07 PM, Richard W.M. Jones wrote:
On Tue, Nov 20, 2012 at 12:52:30PM -0500, Przemek Klosowski wrote:
Interpreters do not preclude simple data: they just scale
You're asking for something very open-ended, and which is not even
possible to implement in general -- what if the inspecting operating
system is Linux, and the inspected operating system needs custom Mac OS X
libraries?
In any case, the correct place to request this is with the SCAP
standards
On Fri, Nov 23, 2012 at 11:43:01AM +0100, Simon Lukasik wrote:
On 11/22/2012 09:07 PM, Richard W.M. Jones wrote:
On Tue, Nov 20, 2012 at 12:52:30PM -0500, Przemek Klosowski wrote:
Interpreters do not preclude simple data: they just scale better,
from simple linear declarative data to
On Sun, Nov 25, 2012 at 04:12:36PM +, Richard W.M. Jones wrote:
systems. Steve will correct me if I'm wrong here, but I don't believe
there's no room for it to be calling out to arbitrary custom
s/no/any/
libraries.
Rich.
--
Richard Jones, Virtualization Group, Red Hat
On Tue, Nov 20, 2012 at 12:52:30PM -0500, Przemek Klosowski wrote:
Interpreters do not preclude simple data: they just scale better,
from simple linear declarative data to complex, Turing-cranking
swamp. The only argument against it is runtime overhead, which isn't
a problem in many, if not
Hi
On Tue, Nov 20, 2012 at 3:39 PM, Przemek Klosowski wrote:
It can be made simple, if you look at it the right way. One wouldn't start
with a generic interpreter, but rather evaluate the config script in a
domain-specific context.
I think you just agreed in a roundabout way It *could* be
On 11/21/2012 05:50 AM, Rahul Sundaram wrote:
On Tue, Nov 20, 2012 at 3:39 PM, Przemek Klosowski wrote:
It can be made simple, if you look at it the right way. One wouldn't
start with a generic interpreter, but rather evaluate the config
script in a domain-specific context.
I
Przemek Klosowski wrote:
You say it yourself---if you need Turing, you have to put him in
somewhere. You argue that the complex logic HAS to go in the native
code, but that is inflexible. PolicyKit needed flexibility so they used
weird data; they combined inflexibility of native code with
On 11/17/2012 12:26 PM, Kevin Kofler wrote:
Przemek Klosowski wrote:
Remember also that data is code: any config files could be seen as tiny
specialized interpreted languages, so it's not like you can avoid
interpretation anyway.
That's a bad view of things, it leads to WTFs like PolicyKit
Hi
Interpreters do not preclude simple data: they just scale better, from
simple linear declarative data to complex, Turing-cranking swamp. The only
argument against it is runtime overhead, which isn't a problem in many, if
not most, cases.
The problem is that, this design makes complex things
Przemek Klosowski wrote:
Remember also that data is code: any config files could be seen as tiny
specialized interpreted languages, so it's not like you can avoid
interpretation anyway.
That's a bad view of things, it leads to WTFs like PolicyKit using rules
written in JavaScript. A simple
On Thu, Nov 15, 2012 at 01:53:32AM +0100, Lennart Poettering wrote:
In fact, all system bus services should be configured to defer
activation to systemd, so that all services regardless how they are
triggered are executed in the same clean execution environment, and can
be manipulated with the
On 2012-11-15, 15:06 GMT, Matthew Miller wrote:
I was looking for resources on systemd and dbus activation. I realized
that
the documentation here is very scarce -- there's this tutorial on just dbus
activation http://raphael.slinckx.net/blog/documents/dbus-tutorial and our
wiki page
On Thu, Nov 15, 2012 at 04:15:25PM +0100, Matej Cepl wrote:
I was looking for resources on systemd and dbus activation. I realized
that
the documentation here is very scarce -- there's this tutorial on just dbus
activation http://raphael.slinckx.net/blog/documents/dbus-tutorial and our
On Thu, 15.11.12 10:06, Matthew Miller (mat...@fedoraproject.org) wrote:
On Thu, Nov 15, 2012 at 01:53:32AM +0100, Lennart Poettering wrote:
In fact, all system bus services should be configured to defer
activation to systemd, so that all services regardless how they are
triggered are
On 11/12/2012 02:15 PM, Miloslav Trmač wrote:
On Mon, Nov 12, 2012 at 7:54 PM, Kevin Kofler kevin.kof...@chello.at wrote:
Right. We need to stop writing core system components in scripting
languages!
Well, there _are_ significant advantages to using a higer-level
language than C.[1] Using
On Tue, Nov 13, 2012 at 2:48 AM, Jan Zelený jzel...@redhat.com wrote:
On 12. 11. 2012 at 17:59:00, Chris Adams wrote:
Once upon a time, Richard Vickery richard.vicker...@gmail.com said:
Change still frightens people to varying degree s., and many busy
end-users
may not have time to
On 11/13/2012 05:35 PM, Richard W.M. Jones wrote:
On Tue, Nov 13, 2012 at 02:41:44PM +, Pádraig Brady wrote:
It could be argued that python is more suited to long lived programs:
$ time /bin/true
real 0m0.002s
Hmmm:
$ echo '' true.ml
$ ocamlopt.opt true.ml -o true
$ time ./true
Roberto Ragusa wrote:
Just for fun, let's see who is the worst.
Challenge accepted. :-)
$ cat nothing.adb
procedure Nothing is
begin
null;
end Nothing;
$ gnatmake nothing.adb -o true
gcc -c nothing.adb
gnatbind -x nothing.ali
gnatlink nothing.ali -o true
$ time ./true
real0m0.001s
On 13.11.2012 18:35, Richard W.M. Jones wrote:
Hmmm:
$ echo '' true.ml
$ ocamlopt.opt true.ml -o true
$ time ./true
real 0m0.002s
user 0m0.000s
sys0m0.001s
time luajit -e require'os'; os.exit(42)
real0m0.001s
user0m0.000s
sys 0m0.000s
But, check here for a far more
On 12.11.2012 21:34, Steve Grubb wrote:
But the problem I see is a lot of libraries are wrapped by swig, which leaks
memory like a sieve. If swig didn't generate such leaky code, Python based
daemons wouldn't be as scary.
IMHO, Python is one of the best ways to express management logic. As
On Tue, 13.11.12 18:03, Thomas Woerner (twoer...@redhat.com) wrote:
The security team asked me not to make firewalld a D-BUS driven
mechanism, because of security concerns and also because of SELinux.
Uh? If you write a new D-Bus service and want to use bus activation,
then you should
Alek Paunov wrote:
On 13.11.2012 18:35, Richard W.M. Jones wrote:
This seems about right to me: Both ocamlopt gcc generate native
x86-64 programs, but there's a small amount of overhead in the OCaml
binary (initializing the minor heap of the GC).
luajit too (it is one of the fastest
How much Python code are you proposing someone ports to Lua? ;-)
On Wed, Nov 14, 2012 at 4:49 PM, Alek Paunov a...@declera.com wrote:
On 12.11.2012 21:34, Steve Grubb wrote:
But the problem I see is a lot of libraries are wrapped by swig, which
leaks
memory like a sieve. If swig didn't
On 15.11.2012 04:32, Kevin Kofler wrote:
Unlike the others, it generates the native code at runtime (Just In Time),
so there is a performance penalty (especially for nontrivial programs) for
the (JIT) compilation which gcc and ocamlopt won't have. The quality of the
generated code could also be
On 11/12/2012 08:53 PM, Matthew Miller wrote:
On Sat, Nov 10, 2012 at 09:53:13PM +0100, Kevin Kofler wrote:
I really don't understand why a core system component such as firewalld is
implemented in Python!
Here, I mostly don't see the reason for it to be running all the time.
Couldn't it be
On Tue, Nov 13, 2012 at 12:53:10PM +0100, Thomas Woerner wrote:
On 11/12/2012 08:53 PM, Matthew Miller wrote:
On Sat, Nov 10, 2012 at 09:53:13PM +0100, Kevin Kofler wrote:
I really don't understand why a core system component such as firewalld is
implemented in Python!
Here, I mostly don't
On Tue, Nov 13, 2012 at 01:19:36PM +, Richard W.M. Jones wrote:
Here, I mostly don't see the reason for it to be running all the time.
Couldn't it be dbus activated, and then go away when it's not needed? Then,
it would matter less what it was written in.
It would loose internal
On 11/12/2012 07:53 PM, Matthew Miller wrote:
On Sat, Nov 10, 2012 at 09:53:13PM +0100, Kevin Kofler wrote:
I really don't understand why a core system component such as firewalld is
implemented in Python!
Here, I mostly don't see the reason for it to be running all the time.
Couldn't it be
On Tue, Nov 13, 2012 at 02:28:17PM +0100, Tomasz Torcz wrote:
Here, I mostly don't see the reason for it to be running all the time.
Couldn't it be dbus activated, and then go away when it's not needed?
Then,
it would matter less what it was written in.
It would loose internal
On Tue, Nov 13, 2012 at 02:41:44PM +, Pádraig Brady wrote:
And for reducing space use: I think it might also be nice to break python
2to3 and idle out of the python-libs package.
splitting python-libs (25MB here), seems worthwhile.
python-libs can bb changed to a subpackage that just
Once upon a time, Pádraig Brady p...@draigbrady.com said:
It could be argued that python is more suited to long lived programs:
$ time /bin/true
real 0m0.002s
$ time python -c True
real 0m0.049s
Aside from that being a meaningless, worst case example, an overhead
of .047 seconds is
On Tue, Nov 13, 2012 at 08:51:59AM -0600, Chris Adams wrote:
$ time /bin/true
real0m0.002s
$ time python -c True
real0m0.049s
Aside from that being a meaningless, worst case example, an overhead
of .047 seconds is hardly worth worrying about unless the command in
On Fri, Nov 09, 2012 at 11:57:12AM -0500, Matthew Miller wrote:
- no way to run once and exit for cloud guests with *non-dynamic*
firewall
needs, and it's a non-trivial user of system resources
You can use the old firewall environment for static firewall use
cases. Everything
On Fri, Nov 09, 2012 at 11:57:12AM -0500, Matthew Miller wrote:
- no way to run once and exit for cloud guests with *non-dynamic*
firewall
needs, and it's a non-trivial user of system resources
You can use the old firewall environment for static firewall use
cases. Everything
On 11/13/2012 03:46 PM, Matthew Miller wrote:
On Tue, Nov 13, 2012 at 02:28:17PM +0100, Tomasz Torcz wrote:
Here, I mostly don't see the reason for it to be running all the time.
Couldn't it be dbus activated, and then go away when it's not needed? Then,
it would matter less what it was written
On 11/13/2012 04:02 PM, Matthew Miller wrote:
On Fri, Nov 09, 2012 at 11:57:12AM -0500, Matthew Miller wrote:
- no way to run once and exit for cloud guests with *non-dynamic* firewall
needs, and it's a non-trivial user of system resources
You can use the old firewall environment for
On Tue, Nov 13, 2012 at 02:41:44PM +, Pádraig Brady wrote:
On 11/12/2012 07:53 PM, Matthew Miller wrote:
On Sat, Nov 10, 2012 at 09:53:13PM +0100, Kevin Kofler wrote:
I really don't understand why a core system component such as firewalld is
implemented in Python!
Here, I mostly don't
On Tue, Nov 13, 2012 at 05:28:42PM +0100, Thomas Woerner wrote:
If you want to recreate rules, use reload. If you restart the
service with systemd, the servce gets stopped and started again, so
you will loose internal state. This is how services are working.
I understand that some services
On 11/13/2012 05:36 PM, Matthew Miller wrote:
On Tue, Nov 13, 2012 at 05:28:42PM +0100, Thomas Woerner wrote:
If you want to recreate rules, use reload. If you restart the
service with systemd, the servce gets stopped and started again, so
you will loose internal state. This is how services are
On 11/13/2012 05:28 PM, Thomas Woerner wrote:
On 11/13/2012 03:46 PM, Matthew Miller wrote:
On Tue, Nov 13, 2012 at 02:28:17PM +0100, Tomasz Torcz wrote:
Here, I mostly don't see the reason for it to be running all the time.
Couldn't it be dbus activated, and then go away when it's not needed?
On Tue, Nov 13, 2012 at 06:03:18PM +0100, Thomas Woerner wrote:
I understand that some services work that way. However, I don't think that
this is the best design for a firewall service. Is there some way to force
the internal state to be recorded?
Let's say there is a security fix for the
On 11/13/2012 06:16 PM, Dennis Jacobfeuerborn wrote:
On 11/13/2012 05:28 PM, Thomas Woerner wrote:
On 11/13/2012 03:46 PM, Matthew Miller wrote:
On Tue, Nov 13, 2012 at 02:28:17PM +0100, Tomasz Torcz wrote:
Here, I mostly don't see the reason for it to be running all the time.
Couldn't it be
On Tue, Nov 13, 2012 at 06:37:37PM +0100, Thomas Woerner wrote:
That's not correct. You can modify the firewall just fine without
restarting it.
This is related to system-config-firewall/lokkit. You are right, if
you are using iptables directly then you do not have this
limitation. firewalld
On Tue, 2012-11-13 at 10:03 -0500, Matthew Miller wrote:
On Fri, Nov 09, 2012 at 11:57:12AM -0500, Matthew Miller wrote:
- no way to run once and exit for cloud guests with *non-dynamic*
firewall
needs, and it's a non-trivial user of system resources
You can use the old
Matthew Miller (mat...@fedoraproject.org) said:
On Tue, Nov 13, 2012 at 06:37:37PM +0100, Thomas Woerner wrote:
That's not correct. You can modify the firewall just fine without
restarting it.
This is related to system-config-firewall/lokkit. You are right, if
you are using iptables
On Tue, Nov 13, 2012 at 06:16:49PM +0100, Dennis Jacobfeuerborn wrote:
On 11/13/2012 05:28 PM, Thomas Woerner wrote:
On 11/13/2012 03:46 PM, Matthew Miller wrote:
On Tue, Nov 13, 2012 at 02:28:17PM +0100, Tomasz Torcz wrote:
Here, I mostly don't see the reason for it to be running all the
On 11/09/2012 07:45 PM, Reindl Harald wrote:
Am 09.11.2012 17:45, schrieb Thomas Woerner:
On 11/09/2012 05:24 PM, Eric H. Christensen wrote:
Please have a look at the feature list for F-18.
firewalld replaces system-config-firewall/lokkit, and the iptables and
ip6tables services, not the
On 11/12/2012 07:28 AM, Seth Vidal wrote:
On Sat, 10 Nov 2012, Kevin Kofler wrote:
Richard W.M. Jones wrote:
- depends on Python stack
+1, we really need to get Python out of the minimal installation.
The focus should be on replacing the existing Python-based packages in
the
minimum set
Seth Vidal wrote:
Yum will likely be replaced with dnf afaik. I don't think zif is under
consideration at all.
That's exactly what I'm complaining about. Dnf is no improvement over yum at
all, zif would bring real advantages through the simple fact that it's
native code, not Python. Native C
Jan Zelený wrote:
Yes, that's the plan. But dnf is still Python. So if we really want to get
Python out of minimal install, there is a room for possible alternatives I
guess.
Right. We need to stop writing core system components in scripting
languages!
But none of this is certainly
On Mon, Nov 12, 2012 at 7:54 PM, Kevin Kofler kevin.kof...@chello.at wrote:
Jan Zelený wrote:
Yes, that's the plan. But dnf is still Python. So if we really want to get
Python out of minimal install, there is a room for possible alternatives I
guess.
Right. We need to stop writing core
Once upon a time, Miloslav Trmač m...@volny.cz said:
- Much easier access to higher-level (and more efficient!) data
structures. C programs frequently use linked lists instead of e.g.
hash tables simply because maintaining hash tables and the associated
memory allocation is just too complex.
On Monday, November 12, 2012 08:15:48 PM Miloslav Trmač wrote:
On Mon, Nov 12, 2012 at 7:54 PM, Kevin Kofler kevin.kof...@chello.at wrote:
Jan Zelený wrote:
Yes, that's the plan. But dnf is still Python. So if we really want to
get Python out of minimal install, there is a room for possible
On Mon, Nov 12, 2012 at 8:25 PM, Chris Adams cmad...@hiwaay.net wrote:
Once upon a time, Miloslav Trmač m...@volny.cz said:
- Much easier access to higher-level (and more efficient!) data
structures. C programs frequently use linked lists instead of e.g.
hash tables simply because maintaining
Once upon a time, Miloslav Trmač m...@volny.cz said:
Sure. Now create a hash table indexed by a tuple, or for more
challenge by an unordered set of strings. Or have all items of the
same type hashed by three different fields for fast lookups.
If I were trying to do all that, I'd probably
On Sat, Nov 10, 2012 at 09:53:13PM +0100, Kevin Kofler wrote:
I really don't understand why a core system component such as firewalld is
implemented in Python!
Here, I mostly don't see the reason for it to be running all the time.
Couldn't it be dbus activated, and then go away when it's not
On Mon, Nov 12, 2012 at 02:53:01PM -0500, Matthew Miller wrote:
On Sat, Nov 10, 2012 at 09:53:13PM +0100, Kevin Kofler wrote:
I really don't understand why a core system component such as firewalld is
implemented in Python!
Here, I mostly don't see the reason for it to be running all the
If dnf is no improvement, then I'd rather we stick with yum; messing with
something new just means spending time that I don't have trying to learn
that new command. This is incredibly cumbersome. If at all possible, please
stay with yum.
On Nov 12, 2012 10:53 AM, Kevin Kofler
Once upon a time, Richard Vickery richard.vicker...@gmail.com said:
If dnf is no improvement, then I'd rather we stick with yum; messing with
something new just means spending time that I don't have trying to learn
that new command. This is incredibly cumbersome. If at all possible, please
Change still frightens people to varying degree s., and many busy end-users
may not have time to read pages in order to learn a new command
On Nov 12, 2012 1:46 PM, Chris Adams cmad...@hiwaay.net wrote:
Once upon a time, Richard Vickery richard.vicker...@gmail.com said:
If dnf is no
Once upon a time, Richard Vickery richard.vicker...@gmail.com said:
Change still frightens people to varying degree s., and many busy end-users
may not have time to read pages in order to learn a new command
It is in _development_ and is just in F18 as a preview. If/when it is
ready to replace
On 12. 11. 2012 at 17:59:00, Chris Adams wrote:
Once upon a time, Richard Vickery richard.vicker...@gmail.com said:
Change still frightens people to varying degree s., and many busy
end-users
may not have time to read pages in order to learn a new command
It is in _development_ and is
On Sat, 10 Nov 2012, Kevin Kofler wrote:
Richard W.M. Jones wrote:
- depends on Python stack
+1, we really need to get Python out of the minimal installation.
The focus should be on replacing the existing Python-based packages in the
minimum set (e.g. yum) by native replacements (e.g.
On 12. 11. 2012 at 01:28:10, Seth Vidal wrote:
On Sat, 10 Nov 2012, Kevin Kofler wrote:
Richard W.M. Jones wrote:
- depends on Python stack
+1, we really need to get Python out of the minimal installation.
The focus should be on replacing the existing Python-based packages in the
On Fri, Nov 09, 2012 at 09:33:08AM -0500, Matthew Miller wrote:
- this turns out to be a big change!
- there's little to no documentation
- the UI is very confusing, with a large number of zones and no apparent
way to configure those zones
- toolset is not yet robust -- has funny
Richard W.M. Jones wrote:
- depends on Python stack
+1, we really need to get Python out of the minimal installation.
The focus should be on replacing the existing Python-based packages in the
minimum set (e.g. yum) by native replacements (e.g. zif). Adding more Python
stuff with additional
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, Nov 09, 2012 at 09:33:08AM -0500, Matthew Miller wrote:
https://fedoraproject.org/wiki/Features/firewalld-default
We have an accepted feature for Firewalld to be the default in Fedora 18.
This replaces iptables and ip6tables? Perhaps I
On 11/09/2012 03:33 PM, Matthew Miller wrote:
https://fedoraproject.org/wiki/Features/firewalld-default
We have an accepted feature for Firewalld to be the default in Fedora 18.
The old scripts are primitive and can't handle dynamic environments very
well, so having something new and modern is
On 11/09/2012 05:24 PM, Eric H. Christensen wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, Nov 09, 2012 at 09:33:08AM -0500, Matthew Miller wrote:
https://fedoraproject.org/wiki/Features/firewalld-default
We have an accepted feature for Firewalld to be the default in Fedora 18.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, Nov 09, 2012 at 05:45:23PM +0100, Thomas Woerner wrote:
I'd happily help document it in the Fedora Security Guide if I could get the
proper content or access to the developers. Heck, I'll even help write
stand-alone documentation for
On Fri, Nov 09, 2012 at 05:32:14PM +0100, Thomas Woerner wrote:
- this turns out to be a big change!
- there's little to no documentation
Have you had a look at the man pages?
I missed the top-level man page and was looking at firewall-cmd, which is
not very helpful on its own. Starting
Am 09.11.2012 17:45, schrieb Thomas Woerner:
On 11/09/2012 05:24 PM, Eric H. Christensen wrote:
Please have a look at the feature list for F-18.
firewalld replaces system-config-firewall/lokkit, and the iptables and
ip6tables services, not the iptables package
and command.
The
76 matches
Mail list logo
