from:"JB"

Hi,

I experience random shutdown delays of ca. 2 min (testing F16 RC1 thru
RC4, hd installation with LXDE).

To debug it I removed quiet and added systemd.log_level=debug in
/etc/defaults/grub (kernel boot params).

This are the only messages logged since shutdown command (regardless
whether delay occurred or not):
/var/log/messages:
...
Nov  2 11:16:24 localhost dbus[852]: [system] Activating service
name='org.freedesktop.UPower' (using servicehelper)
Nov  2 11:16:24 localhost dbus-daemon[852]: dbus[852]: [system]
Activating service name='org.freedesktop.UPower' (using servicehelper)
Nov  2 11:16:24 localhost dbus[852]: [system] Successfully activated
service 'org.freedesktop.UPower'
Nov  2 11:16:24 localhost dbus-daemon[852]: dbus[852]: [system]
Successfully activated service 'org.freedesktop.UPower'
Nov  2 11:16:30 localhost kernel: Kernel logging (proc) stopped.
Nov  2 11:16:30 localhost rsyslogd: [origin software=rsyslogd
swVersion=5.8.5 x-pid=873 x-info=http://www.rsyslog.com;] exiting
on signal 15.

What else can I look at or debug and how ?

I eliminated a possible case of too quick to shutdown after bootup or after
using firefox and terminal scenario.

I am wondering if there is something similar to 'systemd-analyze blame'
that would apply to shutdown/reboot (instead of boot-up) time ?
Also with 'systemd-analyze plot' capability ?

JB


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F16 - random shutdown delays - systemd related ?

Michal Schmidt mschmidt at redhat.com writes:

 ...
 Show us the shutdown-log.txt.
...

Here you go:

http://pastebin.com/EHTiuiR8

JB





-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F16 - random shutdown delays - systemd related ?

Michal Schmidt mschmidt at redhat.com writes:

 
 On 11/03/2011 04:47 PM, JB wrote:
  Here you go:
 
  http://pastebin.com/EHTiuiR8
 
 The parameters log_buf_len=1M systemd.log_level=debug 
 systemd.log_target=kmsg were not on the command line, so this log does 
 not contain all the information.
 
 Michal

Sorry. This one has the debug info.

http://pastebin.com/QsD9LDxb

JB


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F16 - random shutdown delays - systemd related ?

JB jb.1234abcd at gmail.com writes:

 
 Michal Schmidt mschmidt at redhat.com writes:
 
  ...
  Show us the shutdown-log.txt.
 ...
 
 Here you go:
 
 http://pastebin.com/EHTiuiR8
 
 JB
 

I see these NetworkManager activities that are repeated and seem to be
identical (if this is a problem, then systemd or NetworkManager related ?):

...
[   17.596968] NetworkManager[839]: info NetworkManager (version
0.9.1.90-5.git20110927.fc16) is starting...
[   17.596977] NetworkManager[839]: info Read config file
/etc/NetworkManager/NetworkManager.conf
[   17.596984] NetworkManager[839]: NetworkManager[839]: info NetworkManager
(version 0.9.1.90-5.git20110927.fc16) is starting...
[   17.596992] NetworkManager[839]: NetworkManager[839]: info Read config
 file /etc/NetworkManager/NetworkManager.conf
...

[  287.949443] NetworkManager[839]: info caught signal 15, shutting down
 normally.
[  287.949455] NetworkManager[839]: warn quit request received, 
terminating...
[  287.949464] NetworkManager[839]: info (wlan0): now unmanaged
[  287.949472] NetworkManager[839]: info (wlan0): device state change:
disconnected - unmanaged (reason 'removed') [30 10 36]
[  287.949481] NetworkManager[839]: info (wlan0): cleaning up...
[  287.949488] NetworkManager[839]: info (p4p1): now unmanaged
[  287.949496] NetworkManager[839]: info (p4p1): device state change:
unavailable - unmanaged (reason 'removed') [20 10 36]
[  287.949505] NetworkManager[839]: info (p4p1): cleaning up...
[  287.949512] NetworkManager[839]: info (p4p1): taking down device.

[  287.949520] NetworkManager[839]: g_dbus_connection_real_closed: Remote peer
vanished with error: Underlying GIOStream returned 0 bytes on an async read
(g-io-error-quark, 0). Exiting.

  287.949529] NetworkManager[839]: NetworkManager[839]: info caught signal
 15, shutting down normally.
[  287.950389] NetworkManager[839]: NetworkManager[839]: warn quit request
received, terminating...
[  287.950400] NetworkManager[839]: NetworkManager[839]: info (wlan0): now
unmanaged
[  287.950409] NetworkManager[839]: NetworkManager[839]: info (wlan0): device
state change: disconnected - unmanaged (reason 'removed') [30 10 36]
[  287.950417] NetworkManager[839]: NetworkManager[839]: info (wlan0):
cleaning up...
[  287.950425] NetworkManager[839]: NetworkManager[839]: info (p4p1): now
unmanaged
[  287.950433] NetworkManager[839]: NetworkManager[839]: info (p4p1): device
state change: unavailable - unmanaged (reason 'removed') [20 10 36]
[  287.950442] NetworkManager[839]: NetworkManager[839]: info (p4p1):
 cleaning up...
[  287.950449] NetworkManager[839]: NetworkManager[839]: info (p4p1): taking
down device.
...

[  287.992598] NetworkManager[839]: NetworkManager[839]: info exiting
 (success)
[  287.992610] NetworkManager[839]: info exiting (success)

JB


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 16 beta vice Knoppix

2011-10-23 Thread JB

Camilo Mesias camilo at mesias.co.uk writes:

 
 Hi,
 
 I tried some of these changes and they seemed to work reasonably well
 apart from the grub2 infrastructure is still a bit immature at running
 without initrd... specifically
 ... 
 I'm not sure where to report this? Bugs against grub2 or something
 else? Is there a specific forum for initrdless working?
 
 -Cam
 ...

With regard to initrdless boots:
https://bugzilla.redhat.com/show_bug.cgi?id=734274

JB


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

PackageKit vice shell

2011-10-16 Thread JB

Hi,

this is what PackageKit does to shell:

$ dmesh --help
Usage:
  pk-command-not-found [OPTION...]

PackageKit Command Not Found

Help Options:
  -h, --help   Show help options
$

# yum remove PackageKit-command-not-found
...
Removed:
  PackageKit-command-not-found.i686 0:0.6.12-4.fc14

Complete!
#

$ dmesh --help
bash: /usr/libexec/pk-command-not-found: No such file or directory
$
Note: exiting and restarting terminal will fix this one.

This is not a bug, this is a misfeature of PackageKit, it should not be in
it in the first place.
It has been discussed on the list at time of F13 and rejected by users.
I have reported it to PackageKit devs a year ago.
https://bugzilla.redhat.com/show_bug.cgi?id=641311

There is a good UNIX tradition and principle - one utility, one function.
Let PackageKit do package management.
Let shell utility do command language interpretation (command line, etc).

JB


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 16 beta vice Knoppix

2011-10-05 Thread JB

JB jb.1234abcd at gmail.com writes:

 ...

The only difference to previous run is that ethernet cable (with good ISP
service) was plugged in during boot time.
You can see userspace time, and thus total time reduced by more than 300%.

# less -i /var/log/messages
...
Oct  5 05:33:51 localhost systemd[1]: Startup finished in 1s 456ms
73us (kernel) + 12s 580ms 860us (initrd) + 1min 6s 747ms 352us
(userspace) = 1min 20s 784ms 285us.
...

# systemd-analyze blame
 35513ms livesys.service
 25004ms NetworkManager.service
 20153ms bluetooth.service
 20103ms ip6tables.service
 20101ms iptables.service
 19726ms sshd-keygen.service
 19710ms abrtd.service
 17752ms systemd-logind.service
 17708ms avahi-daemon.service
 13914ms udev-settle.service
 8484ms dbus.service
 6019ms fedora-loadmodules.service
 4972ms mcelog.service
 4782ms fcoe.service
 4659ms auditd.service
 4494ms multipathd.service
 4330ms systemd-vconsole-setup.service
 3862ms irqbalance.service
 3248ms media.mount
 3112ms udev-trigger.service
 3102ms rsyslog.service
 3046ms abrt-ccpp.service
 3022ms mdmonitor-takeover.service
 2987ms fedora-readonly.service
 2490ms console-kit-log-system-start.service
 2446ms systemd-remount-api-vfs.service
 2335ms udev.service
 1391ms systemd-tmpfiles-setup.service
 1225ms fedora-storage-init.service
  997ms systemd-sysctl.service
  759ms systemd-readahead-collect.service
  731ms remount-rootfs.service
  577ms sm-client.service
  518ms netfs.service
  218ms fedora-wait-storage.service
  131ms fedora-storage-init-late.service
  122ms sendmail.service
   92ms lvm2-monitor.service
   60ms livesys-late.service
   54ms console-kit-daemon.service
   37ms sandbox.service
   34ms iscsi.service
   22ms systemd-user-sessions.service
   21ms rtkit-daemon.service
   14ms accounts-daemon.service

Full outputs to analyze and plot are available below (valid for 30 days).

Full /var/log/messages:
http://pastebin.com/7jh2rHVk

Full 'systemd-analyze plot  plot.svg':
http://pastebin.com/VY8wFUkt

JB


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 16 beta vice Knoppix

2011-10-05 Thread JB

Jef Spaleta jspaleta at gmail.com writes:

 
 On Tue, Oct 4, 2011 at 6:40 PM, Adam Williamson awilliam at redhat.com 
 wrote:
  So essentially all that's going on here is 'wait for udev to be done',
  which is a fairly sensible prerequisite for all manner of other bits of
  boot.
 
  The reasons why udev takes a while to be 'done' are more interesting and
  Lennart went into some of them.
 
 Right, and as I've said..in the context of the comparison with Knoppix
 specifically I found evidence that udev settle use to be a long boot
 up blocker in previous Knoppix releases.  I wouldn't be surprised at
 all if Knoppix init had been changed in the newest release that JB
 tried to no longer call the settle function (or call it with a very
 short timeout)  But I'm not going to be downloading Knoppix and
 dissecting its init to prove that to myself. Its obvious from my
 testing that settle is one of the big blockers, a blocker multiple
 live distributions have hit in the last year actually.
 ...

Here it is.

# grep -ir udevadm /etc/
...
/etc/init.d/knoppix-autoconfig:  /sbin/udevadm settle
/etc/init.d/knoppix-autoconfig:  udevadm settle
/etc/init.d/knoppix-autoconfig: /sbin/udevadm settle
/etc/init.d/open-iscsi: udevadm settle
/etc/init.d/udev:if udevadm settle; then
...

All references to 'udevadm settle' are without parameters, so:
$ man udevadm
...
   udevadm settle [options]
   Watches the udev event queue, and exits if all current events are
   handled.

   --timeout=seconds
   Maximum number of seconds to wait for the event queue to become
   empty. The default value is 180 seconds. A value of 0 will check if
   the queue is empty and always return immediately.

You can see knoppix-autoconfig
http://pastebin.com/uU5Av6Pf

You can see open-iscsi
http://pastebin.com/9nRp5JGh

You can see udev
http://pastebin.com/aGgghx0s

JB


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Fedora 16 beta vice Knoppix

2011-10-04 Thread JB

Hi,

I performed a simple home test, a comparison of startup and shutdown times of:
- Live-CD Fedora 16 beta - systemd parallel boot, GNOME 3
- Live-CD Knoppix 6.7.1 - microknoppix-fast-parallel-boot (based on SysV/LSB
  scripts), LXDE;
  note that Knoppix does decompression while executing

The times measured were:
t1 - time between machine turned ON and showing of live system DE menu 
t2 - time between machine Shutdown from DE menu and actual machine shutdown

Note: no custom configuration or other user activities were performed.

Notebook 1:
---
Lenovo TP R61i, Intel Pentium Core 2 Duo 1.86 GHZ, Intel Mobile 965GM,
2 GB RAM, HD, CD-RW, sound, internal ethernet and wireless.

F16 beta
average t1=3m8s
average t2=10s

Knoppix
average t1=1m37s
average t2=20s

Notebook 2:
---
HP Nx6110, Intel Celeron M 1.3 GHZ, Intel Mobile 915GM, 768 MB RAM, HD, CD-RW,
sound, internal ethernet.

F16 beta
average t1=3m42s
average t2=26s

Knoppix
average t1=2m38s
average t2=20s

Results interpretation.
---
Knoppix won by a wide margin, while:
- Knoppix having microknoppix fast-parallel boot (based on SysV/LSB scripts)
  and DE with low resources usage and tailored for desktops
- Fedora having systemd parallel boot and DE tailored for small and simple
  devices

JB


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 16 beta vice Knoppix

2011-10-04 Thread JB

JB jb.1234abcd at gmail.com writes:

 ... 
 Notebook 1:
 ---
 Lenovo TP R61i, Intel Pentium Core 2 Duo 1.86 GHZ, Intel Mobile 965GM,
 2 GB RAM, HD, CD-RW, sound, internal ethernet and wireless.
 
 F16 beta
 average t1=3m8s
 average t2=10s
 ...

Let me append The Blame Game.

# less -i /var/log/messages
...
Oct  4 20:40:40 localhost systemd[1]: Startup finished in 1s 438ms
413us (kernel) + 12s 445ms 772us (initrd) + 3min 58s 333ms 952us
(userspace) = 4min 12s 218ms 137us.
...

# systemd-analyze blame
 32983ms livesys.service
 22828ms NetworkManager.service
 19438ms bluetooth.service
 19247ms iptables.service
 19245ms ip6tables.service
 18837ms abrtd.service
 18672ms mcelog.service
 18657ms auditd.service
 18035ms irqbalance.service
 16885ms rsyslog.service
 16814ms systemd-logind.service
 16766ms avahi-daemon.service
 16696ms abrt-ccpp.service
 16659ms mdmonitor-takeover.service
 13837ms udev-settle.service
 11392ms plymouth-start.service
 6264ms fedora-loadmodules.service
 4306ms systemd-vconsole-setup.service
 4258ms multipathd.service
 3850ms fedora-storage-init.service
 3744ms fcoe.service
 3453ms fedora-readonly.service
 3270ms media.mount
 3121ms udev-trigger.service
 2728ms console-kit-log-system-start.service
 2483ms systemd-remount-api-vfs.service
 2283ms udev.service
 2189ms dbus.service
 1994ms systemd-tmpfiles-setup.service
 1332ms fedora-storage-init-late.service
 1061ms systemd-sysctl.service
  790ms remount-rootfs.service
  456ms sm-client.service
  404ms netfs.service
  385ms fedora-wait-storage.service
  341ms lvm2-monitor.service
  279ms systemd-readahead-collect.service
  253ms rtkit-daemon.service
   77ms sendmail.service
   57ms console-kit-daemon.service
   45ms livesys-late.service
   44ms iscsi.service
   31ms sandbox.service
   15ms accounts-daemon.service
   12ms systemd-user-sessions.service

JB


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 16 beta vice Knoppix

2011-10-04 Thread JB

Jef Spaleta jspaleta at gmail.com writes:

 
 On Tue, Oct 4, 2011 at 3:32 PM, JB jb.1234abcd at gmail.com wrote:
  Let me append The Blame Game.
  # systemd-analyze blame
   32983ms livesys.service
   22828ms NetworkManager.service
 
 That timing for NM is so vastly different than what I'm seeing on my
 installed F15 system. I am intrigued.
 
 -jef

The ethernet cable was not plugged in, so it tried too hard ?
If so, it should be looked into (I noticed on F15 a few times that when I lost
my ISP service and checked for it again by restarting NM that it tried
I believe 3 times by many seconds before finally giving up).
The wireless and some 5 AP signals were identified.

JB


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

2011-08-24 Thread JB

Richard Hughes hughsient at gmail.com writes:

 
 On 24 August 2011 01:35, JB jb.1234abcd at gmail.com wrote:
  ...do not expect them to accept your sick world domination drive
 
 ...and this is why some upstream developers have unsubscribed from
 fedora-devel list. Ever wonder why people like David Zeuthen
 unsubscribed? People like you.
 
 I'm also --- --- this close to unsubscribing also.
 
 Richard.

Richard,

before you do it, read his post again and his insinuations about conspiracies
and other staff ! 

If this is his state of mind about the project quality and people on this list
who try to help him and themselves, then I propose that he unsubscribes from
this list as well.

Do you know how many people disappeared from Fedora orbit entirely or stopped
with F14 release due to his systemd project alone ?
Do you remember world's reaction on www.osnews.com to his world domination
plans with regard to systemd and GNOME project ?

This guy is a loose cannon, with an outsized ego, but lacking UNIX
understanding and design skills.

There is a video on Youtube (I can not find the link right now, it is on
www.osnews.com article in comments section) from a German Linux sysadmin
presentation in Munich, in 2009 I believe - with Lennart present in
the audience and constantly interrupting the presenter and putting him down.
Read the comments there by people who watched it !
Lennart, if you read this post go back to that video recording and experience
it again. After that come back here and apologize for your attitude !
You do not deserve to be treated so well by us !
 
It is an embarrassment to watch this list's threads regarding systemd, its
deficiencies, havoc it has caused, and these sysadmin software dev people
trying to straighten things up, and his refusal to do it (or even consider it).

JB


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

2011-08-24 Thread JB

JB jb.1234abcd at gmail.com writes:

 ...
 There is a video on Youtube (I can not find the link right now, it is on
 www.osnews.com article in comments section) from a German Linux sysadmin
 presentation in Munich, in 2009 I believe - with Lennart present in
 the audience and constantly interrupting the presenter and putting him down.
 Read the comments there by people who watched it !
 Lennart, if you read this post go back to that video recording and 
 experience it again. After that come back here and apologize for your
 attitude !
 You do not deserve to be treated so well by us !
 ...
 
Here it is.
http://www.osnews.com/comments/24926

I really couldn't just let this occasion pass
by Lennie on Thu 7th Jul 2011 22:12 UTC 

OK, this is a presentation by someone who manages many Linux-desktops and is
used to how things used to be in the Unix/Linux world.

Good or bad, things have changed in the last few years in most Linux 
distributions.

The presenter is trying to explain what is has become more complicated or
isn't even possible anymore with the new setup.

'luckily' Lennart Poettering was in the audience to 'help' explain why :

http://www.youtube.com/watch?v=_ERAXJj142o

The presentation is funny and sad at the same time. It shows you what he is
like and what he thinks.

Lennart Poettering has vision of what thinks need to be improved for Linux on
the desktop (possible server too). But he seems to always want to do big
changes and not every idea always actually reaches it's full potential.

His intensions are obviously good, but maybe he doesn't work well with others
as he doesn't let others choose what they want. Like with systemd, where he
has basically said: the Linux API is the new Posix

I've got a feeling Lennart Poettering will never be loved in the Linux
community because of it.

Especially not by the BSD-community ;-)

Edited 2011-07-07 22:17 UTC

Enjoy it !
JB


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

JB jb.1234abcd at gmail.com writes:

...

Here are some more detailed thoughts.

Sys init.
-
Sys init as a process #1 should be beyond approach by design, and delegate
all work to other process(es), whether in a permanent or an ad-hoc manner,
that can be operated by sysadmin if needed (e.g. restarted, initialized,
configured, fixed, etc).
We want it to be minimal in its size, minimal in its functions, simple,
stable, secure (no attack venues, direct or indirect) - yes,
beyond approach.

Sockets activation and on-demand services.
--
Here is a description of how it works:
http://0pointer.de/blog/projects/socket-activation.html

The essense begins here:
Socket activation makes it possible to start all (...) services completely
simultaneously, without any kind of ordering.
...
That means the scheduling of our services is entirely done by the kernel: ,,,

Then it continues:
But it's not just about parallelization. It offers a number of other
benefits:
...
We no longer need to configure dependencies explicitly. Since the sockets
are initialized before all services they are simply available ...

If a service dies its listening socket stays around, not losing a single
message. After a restart of the crashed service it can continue right where
it left off.
...

Well, it looks like a wunderwaffe :-)

Systemd and security - an example # 2 of an attack venue.
-
The above is dangerous as a design idea to achieve parallelization of
services.
Let's assume that service A is a dependency for service B (and others).
After A's on-demand socket has been put on hold (blocking), the A may die
or lock up for any reason, that is never to come up again by itself as
an active service.
That means there is a system lock-up possibility here while B (and others) are
on hold too (waiting for A to be unblocked), and wait ..., and wait ...

Systemd and security - an example # 1 of an attack venue.
-
Here is a possible known example:
http://www.securiteam.com/unixfocus/6U00P1PEVQ.html

We know that systemd owns the service socket-in-waiting (with its buffer).
In case of an attack on socket buffer availability via kernel the systemd is
grounded as well.
This should not be allowed to happen to process #1, the Mother of All
Processes.
One more reason to redesign the systemd to be minimal and beyond approach,
and instead have other restartable child process(es) take over the function
of on-demand socket handling.

Can you comment on that ?

http://news.icanhascheezburger.com/2010/06/22/political-pictures-make-a-windows-that-doesnt-crash/

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

Adam Williamson awilliam at redhat.com writes:

 
 On Tue, 2011-08-23 at 07:29 -0700, Toshio Kuratomi wrote:
 
   This is broken IMO ... there is nothing inherently wrong with on
   demand loading ... actually it is the opposite. (i.e should be done
   whenever possible).
  
  On demand loading is great.  But the system administrator needs to have
  control to be able to turn things on and off.  So we need Lennart to give us
  information on how to do that.
 
 I believe this has already been explained several times: if you
 *disable* a service, rather than *stopping* it, socket activation won't
 happen until you re-enable it.

 It's only if you just stop a service that
 socket activation will happily start it back up again. This is the
 'three levels of 'off'' stuff, IIRC.

I would say this is not a good idea with how stop works.
I usually stop a service for a reason. Perhaps I follow it up with
a reconfiguration or do other related work. I would not want it be started
during that time by systemd's magic.

JB




-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

Steve Clark sclark at netwolves.com writes:

 ...

 Sys init.
 - 
 Sys init as a process #1 should be beyond approach by design, and delegate
 all work to other process(es), whether in a permanent or an ad-hoc manner,
 that can be operated by sysadmin if needed (e.g. restarted, initialized,
 configured, fixed, etc).
 We want it to be minimal in its size, minimal in its functions, simple,
 stable, secure (no attack venues, direct or indirect) - yes,
 beyond approach.
 ...
 
 JB - do you mean beyond reproach ?
   Idiom:
   beyond reproach
   So good as to preclude any possibility of criticism.-- 
   Stephen ClarkNetWolves
   Sr. Software Engineer III
   Phone: 813-579-3200
   Fax: 813-882-0209
   Email: steve.clark at netwolves.comhttp://www.netwolves.com
 
   
 

No, not reproach.
I used the term approach.

approach definition:
To come near or nearer, ...

I meant by beyond approach to have systemd as a sys init process #1
god-like qualities and to be so developed and have such characteristics as
to not have any venues of attack or influence, directly or indirectly, in
context of its reliability and security.

JB


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

Lennart Poettering mzerqung at 0pointer.de writes:

 
 On Tue, 23.08.11 17:48, JB (jb.1234abcd at gmail.com) wrote:
 
  Systemd and security - an example # 2 of an attack venue.
  -
  The above is dangerous as a design idea to achieve parallelization of
  services.
  Let's assume that service A is a dependency for service B (and others).
  After A's on-demand socket has been put on hold (blocking), the A may
  die or lock up for any reason, that is never to come up again by itself as
  an active service.
  That means there is a system lock-up possibility here while B (and others)
  are on hold too (waiting for A to be unblocked), and wait ..., and wait
  ...
 
 A dep loop is a dep loop is a dep loop. Whether systemd is used or not
 does not change this. Services with ordering loops are borked services
 and won't work. If an service A synchronously calls into service B and
 the service B synchronously calls into A you'll have a dealock. No news
 there...

Well, let's consider how the lock-up/deadlock would work without socket
activation mechanism.
Concurrent programming provides techniques like process synchronization
constructs with a timeout. That would be the built-in safety mechanism that
would prevent any lock-up.

 ... 
  We know that systemd owns the service socket-in-waiting (with its buffer).
  In case of an attack on socket buffer availability via kernel the systemd
  is grounded as well.
  This should not be allowed to happen to process #1, the Mother of All
  Processes.
  One more reason to redesign the systemd to be minimal and beyond
  approach, and instead have other restartable child process(es) take
  over the function of on-demand socket handling.
  
  Can you comment on that ?
 
 systemd enforces limits on the number of sockets it keeps open. If you
 have a socket unit with Accept=yes (i.e. where systemd will accept() the
 socket and spawn one service instance per connection) then you can
 enforce a limit with MaxConnections= which defaults to 64.
 
 And on socket units with Accept=no (the much nicer way, where systemd
 will spawn a single instance and hand over the listening fd), this
 problem doesn't exist at all, since we only keep a single fd per unit
 open.
 
 Lennart
 

This does not help in this case. The attack's effect can happen at any time
and catch systemd with its pants down at any time in the scenarios you
described.
The attack is on socket buffer availability via kernel, it lasts until no
resource is available system-wide. At that point systemd or any other
socket-based communication is brought to a standstill.
The point is, systemd can not be stopped, or restarted/reinitialized/reset 
as any other stand-alone service daemon relying on sockets availability
manually.
The process #1, the GOD of all processes, is incapacitated, for good.

JB


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

Björn Persson bjorn at xn--rombobjrn-67a.se writes:

 
 JB wrote:
  This does not help in this case. The attack's effect can happen at any time
  and catch systemd with its pants down at any time in the scenarios you
  described.
  The attack is on socket buffer availability via kernel, it lasts until no
  resource is available system-wide. At that point systemd or any other
  socket-based communication is brought to a standstill.
  The point is, systemd can not be stopped, or restarted/reinitialized/reset 
  as any other stand-alone service daemon relying on sockets availability
  manually.
  The process #1, the GOD of all processes, is incapacitated, for good.
 
 I searched for attack and socket buffer availability trying to find out
 what kind of attack you're talking about. Duckduckgo had never heard about
 it. 
 Google gave me three hits, and all three were your previous message in this 
 list. It would help if you could explain how this attack works and how
 exactly it would cause SystemD to lock up.
 
 Is it perchance a syn flood you're talking about? If so, we have a good
 defense since ages. It's known as syn cookies.
 
 Björn Persson
 
 

The link is in one of my posts above, but here it is again:
http://www.securiteam.com/unixfocus/6U00P1PEVQ.html
It contains a detailed description and the original CVE link.
Once again, it is about DOS of a resource in question, that is a socket buffer
memory, with system-wide effect, obviously on any socket-based process.

JB


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

Lennart Poettering mzerqung at 0pointer.de writes:

 ...
 I really honestly wished the troupe of you four or five people who keep
 trying to noisily shoot systemd down on fedora-devel would actually try
 to understand what is going on. Try to get the bigger picture. Try for
 once to see if there might be something good in systemd, because there's
 a lot.
 ...

Lennart,

we are not going to sacrify UNIX/Linux, SysVinit, even systemd (the product
of you, your co-developers, and ... imported ideas from one song for one USD
company) for your ego, which is larger than life.

We try to help you understand the principles of UNIX development - you ignore
them and the poeple who were guided by them for 30-40 years in their
professional life.
You even try to belittle them, people who are clearly superior in their
professional experience and understanding of UNIX in general, and are quite
capable of assessing the value of systemd. 
It is obvious that you do *not* understand them.

You were once even so silly that you went to FreeBSD people and told them to
abandon it and join Linux world instead.
And you want to offer them what ? Your understanding of (or lack thereof)
this UNIX-like Linux principles we want to be guided by and preserve ?

Grow up, man !

These people here dedicate their time, exchange info and ideas, analyze, point
at problems, offer solutions, share experience and knowledge with you, and
that all to correct more and less obvious defficiencies in systemd project.
All they get in return is mine is bigger than yours attitude. As if anything
they said, and documented, and supported was not worth a dime because it is
agains your worldview.
Do you realise what kind of havoc you caused in Fedora releases, current and
future, not only in SysVinit area, but also in others. 
It is even worse, you blame them for problems of your own making, suspecting
us of some kind of conspiracy against you and the goals and quality of your
pet project called systemd.

Grow up, man !

You are offending all these good people who are on this list dealing with you
and your project.
You really do not expect them to accept your sick world domination drive
and its product as a viable UNIX/Linux standard to be included in this Fedora,
later Red Hat, and other distros, as you stated you expect it to happen, do
you ?

Grow up, man !

JB


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

2011-08-22 Thread JB

Steve Grubb sgrubb at redhat.com writes:

 ...
 You're not seeing the hundreds - no thousands of emails about systemd?
 You are not seeing that all the expected facilities of init are not covered?
 There is well founded rebellion here.
 ...

Yes, you are right. And the people (e-mails, posts) you refer to are too.

Your concerns and those of others point to a questionable (non-UNIX) systemd
design.
Once again I refer everybody to Denys Vlasenko's thread, where this is very
visible; go over it again and you will know why:
http://lists.fedoraproject.org/pipermail/devel/2011-June/152323.html

Sys init was, and should be (as it was expected to be in systemd):
- simple, limited-in-functions, stable, and thus secure in design
- no sys init *and* services manager roles (the last one should be done by
  another (child) process and inetd-like server)
- no networking exposure due to security concerns
- no pseudo-roles like handling user sessions, login's, etc
- etc

It is not by chance that people think about a Windows-like approach in concept
and design of systemd, and even Lennart admitted to it:
I like to see it as a modular platform to build an OS from.
It comes thru, he wants systemd, with its implied world domination attitude,
to be a base for some OS-to-be; he even expects it to be some kind of
a standard every distro would adopt.

I can only say I hope not !
I would suggest that Fedora will be first to reject it as it is now.
Fedora is a BETA distro by choice, so it should be easy, prudent, and proper
to stop here and redesign systemd, with community, users and testers input.

A propos, I have here a few links to sources on UNIX philosophy.
I would suggest to everybody to not just read them (skip over them quickly),
but also think for a few minutes about each principle.
It helps clear up one's mind.

http://en.wikipedia.org/wiki/Unix_philosophy

Eric Steven Raymond
The Art of Unix Programming
http://www.catb.org/esr/writings/taoup/
http://www.catb.org/esr/writings/taoup/html/

The Unix Philosophy
http://www.linuxjournal.com/article/2877

Enjoy it.
JB

Vivaldi - Da due venti il mar turbato - Angela Gheorghiu - 1987 (Very Rare!)
http://www.youtube.com/watch?gl=USv=8_MtYYCuFjk



-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

systemd vice SysV/LSB init systems - what next ?

2011-07-19 Thread JB

Hi,

My suggestion is that you keep both init systems, SysV/LSB and systemd,
as separate offerings out of many, and forever so.

You would install them as suitable for your individual system needs.
The SysV/LSB system init would be default as is now.

The reason for it is twofold:
- SysV/LSB init system
  - it is established, with a long history of familiarity within UNIX/Linux
OS environments, whether by a professional or amateur sysadmin, a system
programmer or architect, a technical or casual user
  - adherence to UNIX principles
  - ease of use due to shell scripting
  - transparency of code due to shell use
  - ease of system setup
  - ease of prototyping, editing, experimenting, etc
  - based on the above, it has a distincit advantage over systemd
- systemd
  - as of today, it does not offer any functional advantage over SysV/LSB,
except a new make-up with heavy use of lipstic in form of unit
configuration files (and control functions)
  - there is no promised land  of parallelization and speed, which can not
be achieved without applying concurrency and all system programming
models and tools available today (client-server/master-slave, sockets,
multithreading, synchronization constructs, synchronous/asynchronous
programming, or even hybrid event- and threads-driven programming where
appropriate, etc)
  - the project, to achieve full benefits of concurrency, should become fully
autonomous and self-contained
  - it should abandon any utilization of or allowing shell processing
(internally or externally)
  - it should use coding in C exclusively, with a separate execution
environment, data structures, config files, services definition and
execution, controls, secure programming, etc.
  - advantages:
- a separate development env
- speed
- clearer paths to utilization
- availability and possible customization for and in devices or systems
  that would have unique requirements, where traditional (script based)
  init systems would be impossible or inappropriate
- ability to tailor it for cooperation with other environments (GNOME, etc)
 
JB

ZZTop
http://www.youtube.com/watch?v=p-y33Uq6HGs



-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: systemd vice SysV/LSB init systems - what next ?

2011-07-19 Thread JB

Adam Jackson ajax at redhat.com writes:

 
 On Tue, 2011-07-19 at 11:11 +, JB wrote:
 
  My suggestion is that you keep both init systems, SysV/LSB and systemd,
  as separate offerings out of many, and forever so.
 
 We'll take that under advisement.
 
 - ajax
 
 

I am actually not discouraged.

The current state of systemd is neither here nor there, and will never be 
there as designed now, from the conceptual and technical point of view.
They have learned some stuff during these discussions here that clarified
the project's goals as they were and should be.

I think they know it - they are good system programmers.

There is nothing wrong with taking a breather, reflecting, and making a second
approach. In particular, if their testing platform is Fedora and they can
easily turn around now, without any problems.
In my eyes that would be a sign of maturity on their part.

We would give the systemd people a chance to do it right, big way !
They would have a great opportunity to show their talent in full by utilizing 
all that UNIX/Linux offers in system programming models and tools.

JB




-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: systemd vice SysV/LSB init systems - what next ?

2011-07-19 Thread JB

Jeff Spaleta jspaleta at gmail.com writes:

 ... 
  None of us who are deeply familiar with shell can You easily assess
 the relative merits of systemd because we aren't familiar with systemd
 yet.
Yes we are already - the discusions here were not useless, neither for me,
you, or anybody else who wanted to understand.

 ... 
 I'm utterly unmoved by any arguments which boil down to I'm familiar
 with this 20+ year old tech, and I don't want to learn something new
 ...

Not true. We want to bring it to a higher level that would represent true
progress and innovation. A killer init system by any standard yet.
And the project guys can do it.
 
 Familiar is not automatically easier or better, harder or worse. It is
 simply familiar and the longer we hold on to the familiar the harder
 it will every be for us to take the time to invest in better
 technologies so we can realize the full potential of those
 technologies.

That's what I have just said above too.
So you are already FOR, but you did not know about it up to now :-)
Welcome to the club !

 
 -jef

JB


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: BTRFS: The Good, The Bad and The Ugly

Josef Bacik josef at toxicpanda.com writes:

...
We aren't aiming for hopefully stable, we're aiming for actually stable
and reasonably safe. If we don't meet certain basic requirements no
switch will be made and everything will carry on as normal.

I'm not trying to shove Btrfs down peoples throats. The last thing I
want is to switch over to Btrfs before it's fully ready for everybody
to be using it, which is why there are a bunch of requirements that
need to be met before the switch is actually met.
...

Well, as a Fedora's point man and contributor to BTRFS, you sound good.
For that, we are glad to have you there.
But we want to test your dedication a bit ...

As you probably know, about a year ago, when BTRFS was still in early
experimental stage, during some elementary evaluation and testing that
yielded some really disastrous results, an issue was raised that the devs
corrupted the b-tree algorithm that underlies the fs in question.
The original b-tree algorithm was a result of an academic study, formulation,
and empirical testing, and was subjected to scientific scrutiny.

Obviously, when devs do some adjustments to such a finely tuned algorithm,
it is imperative that they should immediately submit them for review, as is
customary. The entire alogoritm has to be verified once again.

So, basically, the entire BTRFS fs design was called into question.

Even as of today, the status of BTRFS in Linux kernel, as described by its
devs, is:
[linux/kernel/git/torvalds/linux-2.6.git] / fs / btrfs / Kconfig config
and
[linux/kernel/git/next/linux-next.git] / fs / btrfs / Kconfig

BTRFS_FS
tristate Btrfs filesystem (EXPERIMENTAL) Unstable disk format
...
Btrfs is highly experimental, and THE DISK FORMAT IS NOT YET
FINALIZED. You should say N here unless you are interested in
testing Btrfs with non-critical data.
...
If unsure, say N.

There is a suspicion by some people who follow BTRFS development that it is
a botched attempt, right from the very beginning, at its fundament, and if
so any layers put on top of it to make it work are equivalent to asbestos
that provides fire protection but distorts quality of the building, but will
become a liability in due time :-)
In other words, it is a product of hillbillies, wielding a compiler and
a language a la ax men.
Btw, we have seen similar software dev's activism in Fedora that does
exactly that, and does not not stand up to scrutiny :-)

So, what is the true state of BTRFS ?

Do *you* think this is enough to be Fedora's *default* fs ?

Woman sues Disney, says pervy Donald Duck molested her.
http://articles.nydailynews.com/2010-08-12/news/27072557_1_donald-duck-molested-theme-park

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: BTRFS: The Good, The Bad and The Ugly

Ric Wheeler rwheeler at redhat.com writes:

 ...
 
 Given that my family is from the hills of eastern 
 Kentucky, I also find the hill billie comment off putting.
 ...

Ric, no offense ... injecting Kentucky hills was misguided ... I happened to
visit the state few times and was impressed with how nice it looked ... and
the girls ... and horses ... Wow !  :-)

 ... 
 We will not push for btrfs as a default unless it is safe.
 ...

I have difficulty swallowing the fact that there are so many Red Hat, Oracle,
and other famous technology names involved (officially or dev's private
contributions) in development of BTRFS, and at the same time they practice
such loosely approach to software development methodology.

You can not manipulate an algorithm or disregard it in part without botching
it as a whole, and at the same time be perceived as capable of handling BTRFS
development ...

I do understand that people contributing to BTRFS are of different ways of
life ... but those that assume leading positions anywhere in its dev life
cycle must be up to snuff (academically, technically, etc).
Otherwise, you will produce a Frankenstein fs !

The stakes are high because the features are advanced, attractive, and
compelling.

JB


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: BTRFS: The Good, The Bad and The Ugly

Martin Langhoff martin.langhoff at gmail.com writes:

 
 On Thu, Jul 14, 2011 at 4:50 AM, JB jb.1234abcd at gmail.com wrote:
  I have difficulty swallowing the fact that there are so many Red Hat, 
  Oracle,
  and other famous technology names involved (officially or dev's private
  contributions) in development of BTRFS, and at the same time they practice
  such loosely approach to software development methodology.
 
 Rather than vague accusations, can you provide some concrete problem?
 
 You're badmouthing the work of some rather experienced and respected
 people, yet you have provided no specifics whatsoever.
 
 m

Well, then you have to read the thread more carefully before you bark back -
right in the first OP's post you have references, e.g.

https://lkml.org/lkml/2010/6/18/144

Here is one more:

http://www.ilsistemista.net/index.php/linux-a-unix/6-linux-filesystems-benchmarked-ext3-vs-ext4-vs-xfs-vs-btrfs.html

They all confirm the same picture !

Enjoy it.
JB


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: BTRFS: The Good, The Bad and The Ugly

Matej Cepl mcepl at redhat.com writes:

 
 Dne 14.7.2011 09:28, JB napsal(a):
  The original b-tree algorithm was a result of an academic study, 
  formulation,
  and empirical testing, and was subjected to scientific scrutiny.
 
 Ehm, I don't claim to have any deep knowledge on the matter, but I have 
 here B-trees explained in Wirth (1975), and I know that all databases 
 (namely PostgreSQL) are all over them, so it is hard to say they are 
 fresh untested idea.
 
 Matěj
 

You misunderstood ...
I was talking about strictness of implementation of the algorithm, which was,
as I and you assume, verified by many bodies.

JB


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: BTRFS: The Good, The Bad and The Ugly

Ric Wheeler rwheeler at redhat.com writes:

 ...
 I think that it would be really rare to see pristine, academic algorithms 
 implemented exactly as a non-coding mathematician designed them in code :)
 ...

Well, not convinced ... :-)

The algorithm  has to be taken holisticly - it has been designed, tested,
fine tuned, optimized, tested again, and then submitted to internal rigor,
and then to external rigor (e.g. of academia, professional community, etc).

When an implementer picks it up, she can not interpret it second-handedly.
She has to take it as a whole. No games !

The algorithm *must* be coded as designed and *not* have programming coding
bugs.

Next, after coding it (even presumably as originally intended), you have
to submit it to that same rigor of testing as done by the original algorithm
inventor.
And make no mistake, you have to do it repeatedly, at every stage of 
development, iteratively. 

Your BTRFS fs's integrity relies on that !
 
So, no wobbling, strictly as the doctor prescribed :-)

JB


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: BTRFS: The Good, The Bad and The Ugly

Josef Bacik josef at toxicpanda.com writes:

 ... 
 I've already said
 that if it's not in good shape by Alpha the switch won't even be made,
 so quit your bitching.
 
 Josef

Josef,
would it be possible, BEFORE (in case that) you decide to switch on before
Alpha, to present some test suite results (a la Phoronix, etc) that would
assure yourselves and Fedora testers/users of BTRFS fitness ? 

If it came from you it would have a special weight and a sign that you
do no want to sell cats in a bag :-)

I hope, that the community at large will parallel it with their own tests.

JB


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: BTRFS: The Good, The Bad and The Ugly

Josef Bacik josef at toxicpanda.com writes:

 ...
 We've reached the point where we really need wider user
 testing, because no amount of testing we do will ever be able to match
 up to the crazy things users do.

Please understand - convincing people (technical and non-technical) to
install a regular Fedora with a new fs is always tricky.
Just a prospect of having your machine work for a month or so and
accumulating confidence and data ... and suddenly stairing into a black ...
is a bit unnerving :-)

Now just a loud thinking ...
Have you thought about first preparing a CD (even a live CD) with BTRFS and
some extra preinstalled software like VirtualBox etc just for testing ?
This way you would address your need for wider testing and have a receptive
audience to do just that on their own terms.
Also, it would be a great way to assure testers/users (and discover some
crazy behavior effects) before making BTRFS a default fs in Fedora.

Btw, we do understand that you put a lot of time and effort into it, really.
And we appreciate it, really.

But sometimes, technical people have a problem with selling the fruits of
their work to the unwashed masses who are not aware of all technical
details but are confronted with the prospect of being testers/users of still
risky technology (and their assets at risk ...).

Anyway, we wish you well and hope that you make BTRFS avaiable to us when
ready.

JB


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: BTRFS: The Good, The Bad and The Ugly

Bryn M. Reeves bmr at redhat.com writes:

 
 On 07/14/2011 05:26 PM, JB wrote:
  Now just a loud thinking ...
  Have you thought about first preparing a CD (even a live CD) with BTRFS and
  some extra preinstalled software like VirtualBox etc just for testing ?
 
 What, you mean like the live and non-live Fedora ISOs that have had btrfs
 support available as an option during install since Fedora 11 (mid 2009ish)?
 
 Regards,
 Bryn.

Good. Perhaps a weekly snapshot CD, with the latest BTRFS and related utils,
so that the testing would be more up-to-date and meaningful.
JB
 


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: BTRFS: The Good, The Bad and The Ugly

Bryn M. Reeves bmr at redhat.com writes:

 
 On 07/14/2011 05:48 PM, JB wrote:
  Good. Perhaps a weekly snapshot CD, with the latest BTRFS and related utils,
  so that the testing would be more up-to-date and meaningful.
  JB
 
 http://alt.fedoraproject.org/pub/alt/nightly-composes/
 
 Regards,
 Bryn.

OK.

Post every week on user, testers, and devel lists: 
- BTRFS testing reminder
- BTRFS info (short notes; entries; pointers to any info, info/man pages)
- test instructions
- a link where to obtain latest Fedora snapshot/nightly live composes with
  latest BTRFS software
 
Test instructions:

Prepare a text with your wishes (what aspects of OS and BTRFS do you
want to be tested in particular this week), and a test plan to guide people 
how to achieve the test goals.

If you are interested in test results or capturing a special trace or dump,
write it down with clear instructions how to do it and where to file it back
to you.

JB


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: BTRFS: The Good, The Bad and The Ugly

Michael Cronenworth mike at cchtml.com writes:

 ...
 If you're that concerned about the quality of Fedora 16 then I would 
 suggest you join the test list, become a proventester, and attend QA 
 meetings.
 
 (Ranting on this list and making demands won't make it happen.)I am not 
 ranting

I am not ranting, and I am certainly not making demands ... where do you see
that ? Do not make things up, please :-)

Btw, not everybody is interested in formalizing their relationship with Fedora
thru proventester or any other form. They can be helpful by being just there on
the lists :-)

I am just suggesting how the devs can reach their audience and communicate
with them for a mutual benefit.

JB


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: BTRFS: The Good, The Bad and The Ugly

Bernd Stramm bernd.stramm at gmail.com writes:

 ... 
 Would you help out with testing if given these specific instructions?
 If not yourself, who would actually do this? 
 ...

I am only suggesting a mini form of so called user testing (that's what it is
called and practised in a software development corporate environment).

Given specificity of various Fedora lists, a very effective way for devs to
pro-actively reaching their audience (testers/users), who are informally
present here and are willing to help testing. But it would be helpful if
the devs were more specific what they are expecting e.g. this week.

Try it and see the results. Perhaps it will work :-)

JB


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: BTRFS: The Good, The Bad and The Ugly

Bernd Stramm bernd.stramm at gmail.com writes:

 ... 
  Try it and see the results. Perhaps it will work 
 
 But that is my point - you are not willing to do any part of this
 yourself. You are only instructing others to do specific work. 
 

I am not instructing anybody. I am suggesting things.
I have emphasized that explicitly already.

Good night everybody :-)
JB


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: BTRFS: The Good, The Bad and The Ugly