text:
IRC, freenode, #hurd, 2013-02-26
<youpi> btw, about fakeroot-hurd
<youpi> the remaining issue I see is with argv[0] (yes, again...)
IRC, freenode, #hurd, 2013-04-03
<youpi> btw, I believe our fakeroot-hurd is close to working actually
<youpi> it's just a argv[0] issue supposed to be fixed by exec_file_name
but apparently not fixed in that case, for some reason
IRC, freenode, #hurd, 2013-08-26
< teythoon> also I looked into the fakeroot issue, aiui the problem is that
scripts are not handled correctly, right?
< teythoon> the exec server fails to locate the scripts file name, and so
it hands the file_t to the interpreter process and passes /dev/fds/3 as
script name
< teythoon> afaics that breaks e.g. python
< youpi> yes
< youpi> pinotree's exec_file_name is supposed to fix that, but for some
reason it doesn't work here
< pinotree> it was pochu's, not mine
< youpi> ah, right
< teythoon> ah I see, I was wondering about that
< pochu> it was working for a long time, wasn't it?
< pochu> and only stopped working recently
< youpi> did it completely stop?
< youpi> I have indeed seen odd issues
< youpi> I haven't actually checked whether it has completely stopped
< youpi> probably worth looking there first
< pinotree> gtk+3.0 fails, but other stuff like glib2.0 and gtester-using
stuff works
< teythoon> huh? I created tests like "#!/bin/sh\necho $0" and that says
/dev/fd..., and a python script doing the same doesn't even run, so how
can it work for a package build?
< youpi> it works for me in plain bash
< youpi> #!/bin/sh
< youpi> echo $0
< youpi> € $PWD/test.sh
< youpi> /home/samy/test.sh
< teythoon> it does !?
< youpi> yes
< youpi> not in fakeroot-hurd however, as we said
< teythoon> well, obviously it works when not being run under
fakeroot-hurd, yes
< youpi> ok, so we weren't talking about the same thing
< youpi> a mere shell script doesn't work in fakeroot-hurd indeed
< youpi> that's why we still use fakeroot-sysv
< teythoon> right
< youpi> err, -tcp
IRC, freenode, #hurd, 2013-11-18
<teythoon> I believe I figured out the argv[0] issue with fakeroot-hurd
<teythoon> but I'm not sure how to fix this
<teythoon> first of all, Emilios file_exec_file_name patch set works fine
<teythoon> but not with fakeroot
<teythoon> check_hashexec tries to locate the script file using a heuristic
<teythoon> Emilios patch improves the situation with just providing this
<teythoon> but then, the identity port of the "discovered" file is compared
with the id port of the script file
<teythoon> to verify if the heuristic found the right file
<teythoon> but when using fakeroot-hurd, /hurd/fakeroot proxies all
<teythoon> but the exec server is outside of the /hurd/fakeroot
environment, so it gets the id port from the real filesystem
<teythoon> we could skip that test if the script name is explicitly
provided though
<teythoon> that test was meant to see whether a search through $PATH turned
up the right file
<braunr> teythoon: nice
<teythoon> braunr: thanks :)
<teythoon> unfortunately, dpkg-buildpackaging hurd with it still fails for
some reason
<teythoon> but it is faster than fakeroot-tcp :)
<braunr> even chown ?
<braunr> or chmod ?
<teythoon> dunno in detail, but the whole build is faster
<braunr> if you can try it, i'm interested
<braunr> because chown/chmod is also slow on linux with fakeroot-tcp
<teythoon> i can try...
<braunr> so it's probably not a hurd bug
<teythoon> braunr: yes, it really is
<braunr> no i mean
<braunr> chown/chmod being slow with fakeroot-tcp is probably not a hurd
<braunr> but a fakeroot-tcp bug
<teythoon> chowning all files in /usr/bin takes 5.930s with fakeroot-hurd
(6.09 with startup overhead) vs 26.42s (26.59s) with fakeroot-tcp
<braunr> but try it on linux (fakeroot-tcp i mean)
<braunr> although you may want to do it on something you don't care much
about :p)
IRC, freenode, #hurd, 2013-12-03
* teythoon is gonna hunt a fakeroot bug ...
<teythoon> % fakeroot-hurd /bin/sh -c ":> /tmp/some_file"
<teythoon> /bin/sh: 1: cannot create /tmp/some_file: Is a directory
<braunr> ah fakeroot-hurd
<teythoon> prevents installing stuff with /bin/install
<teythoon> sure fakeroot-hurd, why would i work on the slow one ?
<braunr> i don't know
<braunr> because it makes chmod/chown/maybe others horrenddously slow
<braunr> ?
<teythoon> yes, fixing this involves fixing fakeroot-hurd
<braunr> are you sure ?
<braunr> i prefer repeating just in case: i saw that problem on linux as
<braunr> with fakeroot-sysv
<teythoon> so ?
<braunr> i'm almost certain it's a pure fakeroot bug, not a hurd bug
<braunr> so
<teythoon> even if this is fixed, it still has to pay the socket
communication overhead
<braunr> fixing fakeroot-hurd so that i can be used instead of fakeroot-tcp
is a very good thing to do, obviously
<braunr> it*
<braunr> but it won't solve the chown/chmod speed
<braunr> (or, probably won't)
<teythoon> huh, why not ?
<braunr> 15:53 < braunr> i'm almost certain it's a pure fakeroot bug, not a
hurd bug
<braunr> when i say it's slow, i should be more precise
<braunr> it doesn't show up in top
<teythoon> yes, but why would fakeroot-hurd suffer from the same issue ?
<braunr> the cpu is almost idle
<braunr> oh right, it's a completely different tool
<braunr> my bad
<braunr> right, right, the proper way to implement fakeroot actually :)
<teythoon> yes
<teythoon> this will bring near-native speed
IRC, freenode, #hurd, 2013-12-05
<teythoon> fakeroot-hurd just successfully built mig :)
<teythoon> hangs in dh_gencontrol when building gnumach or hurd though
<teythoon> i believe it hangs waiting for a lock
<teythoon> lock like in file lock that is
<teythoon> braunr: no more room for vm_map_find_entry in 80220a40
<teythoon> 80220a40 <- is that a task ?
<braunr> or a vm_map, not sure
<braunr> probably a vm_map
IRC, freenode, #hurd, 2013-12-06
<teythoon> well, aren't threads a source of endless entertainment ... ?
<teythoon> well, I found three more bugs in fakeroot-hurd
<teythoon> one of them requires fixing the locking used in fakeroot
<braunr> ouch
<teythoon> the current code does some lock cycling to aquire a lock out of
<braunr> cycling ?
<teythoon> in the netfs_node_norefs function
<teythoon> release and reaquire
<braunr> i see
<teythoon> which imho should be better solved with a weak reference
<teythoon> working on it, it no longer deadlocks but i broke something else
<teythoon> endless fun ;)
<braunr> such things could have been done right in the beginning
<braunr> ...
<teythoon> yes, I wonder
<teythoon> libports has weak references
<teythoon> but pflocal is the only user
<braunr> hm
<teythoon> none of the lib*fs support that
<braunr> didn't i add one in libdiskfs too ?
<braunr> anyway, irrelevant
<braunr> weak references are a nice feature
<braunr> teythoon: i don't see the cycling you mentioned
<braunr> only netfs_node_refcnt_lock being dropped temporarily
<teythoon> yep, that one
<teythoon> line 145
<teythoon> note that due to another bug this code is currently never run
<braunr> how surprising ..
<braunr> the note about some leak actually gave a hint about that
<teythoon> yeah, that leak
<teythoon> I think i'm actually very close
<teythoon> it's just so frustrating, i thought i got it last night
<braunr> good luck then
<teythoon> thanks :)
IRC, freenode, #hurd, 2013-12-09
<teythoon> sweet, i fixed fakeroot-hurd :)
<braunr> /clap
<braunr> what was the problem ?
<teythoon> lots
<braunr> i see
<teythoon> it's amazing it actually run as well as it did
<braunr> mess strikes again
<braunr> i hate messy code ..
* teythoon is building half a hurd package using this ... stay tuned ;)
<azeem> teythoon: is this going to make building faster as well?
<teythoon> most likely, yes
<teythoon> fakeroot-tcp is known to be slow, even on linux
<braunr> teythoon: are you sure about the transparent retry patch ?
<teythoon> pretty sure, why ?
<braunr> it's about a more general issue that we didn't fix yet
<braunr> our last discussions about it lead us to agree that clients should
check the identity of a server before interacting with it
<teythoon> braunr: i don't understand, what's the problem here ?
<braunr> teythoon: fakeroot does the lookup itself, doesn't it ?
<teythoon> yes
<braunr> teythoon: but was that also the case before your patch ?
<teythoon> braunr: yes
<braunr> teythoon: then ok
<braunr> teythoon: i guess fakeroot handles requests only for a specific
set of calls right ?
<braunr> and for others, requests are directly relayed
<teythoon> braunr: yes
<braunr> and that still is the case, right ?
<teythoon> yes
<braunr> ok
<braunr> looks right since it only affects lookups
<braunr> ok then
<teythoon> well, fakeroot-hurd built half a hurd package in less than 70
<teythoon> a new record for my box
<braunr> compared to how much before ?
<braunr> (and why half of it ?)
<teythoon> unfortunately it hung after signing the packages... some perl
process with a /usr/bin/tee child
<teythoon> killing tee made it succeed though
<teythoon> braunr: i don't build the udeb package
<braunr> oh ok
<teythoon> braunr: compared with ~75 with fakeroot-tcp and my demuxer
rework, ~80 before
<braunr> teythoon: nice
IRC, freenode, #hurd, 2013-12-18
<teythoon> there, i fixed the last fakeroot-hurd bug
<teythoon> *whee* :)
<teythoon> i thought so many times that i got the last fakeroot bug ...
<teythoon> last as in it's in a good enough shape to compile the hurd
package that is
<teythoon> but now it is
<braunr> :)
<braunr> this will make glibc and others so much faster to build
IRC, freenode, #hurd, 2013-12-19
<braunr> teythoon_: hum, you should make the behaviour of fakeroot-hurd on
the last client exiting optional
<teythoon_> y?
<teythoon_> fakeroot-tcp does the very same thing
<braunr> fakeroot-hurd is different
<braunr> it's part of the file system
<teythoon_> yes
<braunr> users may want it to stay around
<braunr> and reuse it without checking it's actually there
<teythoon_> but once the last client is gone, who is ever getting another
port to it ?
<teythoon_> no
<teythoon_> that cannot happen
<braunr> really ?
<teythoon_> yes
<braunr> i thought it was like remap
<braunr> since remap is based on it
<teythoon_> the same thing applies to remap
<teythoon_> only settrans has the control port
<braunr> hum
<teythoon_> and uses it once to get a protid for the working dir of the
initial process started inside the chrooted environment
<braunr> you may not want to chroot inside
<teythoon_> so ?
<teythoon_> then, you get another protid
<braunr> i'll make an example
<braunr> i create a myroot directory implemented by fakeroot
<braunr> populate it
<braunr> leave and do something else,
<braunr> i might want to return to it later
<teythoon_> ah
<teythoon_> ok, so you are not using settrans --chroot
<braunr> or maybe i'm confusing the fakeroot translator and fakeroot-hurd
<braunr> 10:48 < braunr> you may not want to chroot inside
<braunr> yes
<teythoon_> hm
<teythoon_> ok, so the patch could be changed to check whether the last
control port is gone too
<braunr> i have no idea of any practical use, but i don't see a valid
reason to make a translator go away just because it has no client
<braunr> except for resource usage
<braunr> and if it's installed as a passive translator
<braunr> although that would make fakeroot loose its state
<braunr> though remap state is on the command line so it would be fine for
<braunr> see what i mean ?
<teythoon_> yes i do
<braunr> fakeroot state could be saved in some db one day so it may apply,
if anyone feels the need
<teythoon_> so what about checking for control ports too ?
<braunr> i'm not too familiar with those
<braunr> who has the control port of a passive translator ? the parent ?
<teythoon_> that should cover the use case you described
<teythoon_> for the parent translator
<teythoon_> for fsys_getroot requests it has to keep it around
<teythoon_> and for more fsys stuff too
<braunr> and if active ? settrans ? who just looses it ?
<teythoon_> if settrans is used to start an active translator, the parent
fs still gets a right to the control port
<braunr> ok
<braunr> i don't have a clear view of what this implies for fakeroot-hurd
<braunr> we'd want fakeroot-hurd to clean all resources including the
fakeroot translator on exit
<teythoon_> for fakeroot-hurd (or any child translator) this means that a
port from the control port class will still exists
<teythoon_> so we do not exit
<teythoon_> oh, you're speaking of fakeroot.sh ? the wrapper script ?
<braunr> probably
<braunr> for me, fakeroot-hurd is the command line too, similar to
fakeroot-sysv and fakeroot-tcp
<braunr> and fakeroot is the translator
<teythoon_> yes, agreed
<teythoon_> fakeroot-hurd could use settrans --force --chroot ... to force
fakeroot to exit if the main chrooted process dies
<teythoon_> but that'd kill anything that outlives that process
<teythoon_> that might be legitimate, say a process daemonized
<teythoon_> so detecting that noone uses fakeroot is the much cleaner
<braunr> ok
<teythoon_> also, that's what fakeroot-tcp does
<braunr> which is why i suggested an option for that
<teythoon_> why add an option if we can do the right thing without
troubling the user ?
<braunr> ah, if we can, good
<teythoon_> i think we can
<teythoon_> I'll rework the patch, thanks for the hint
<braunr> so
<braunr> just to be clear
<braunr> the way you intend it to work is
<braunr> wait for all clients and the control port to drop before shutting
<braunr> the control port is dropped when dettaching the translator, right
<teythoon_> yes
<braunr> but hm
<braunr> what if clients spawn other processes ?
<braunr> they won't find the translator any more
<teythoon_> then, that client get's a port to fakeroot at least for it's
working dir
<teythoon_> so another protid is created
<braunr> ah yes, it's usually choorted for such uses
<braunr> chrooted
<teythoon_> so fakeroot will stick around
<braunr> but clients, even from fakeroot, might simply use absolute paths
<teythoon_> so ?
<braunr> in which case they won't find fakeroot
<teythoon_> it will hit fakeroots dir_lookup
<teythoon_> sure
<braunr> how so ?
<teythoon_> if the path is absolute, it will trigger a magic retry of some
<teythoon_> so the client uses it's root dir port
<braunr> i thought the lookup would be done straight from the root fs port
<teythoon_> which points to fakeroot of course
<braunr> ah, chrooted again
<teythoon_> that's the whole point
<braunr> so this implies clients are chrooted
<teythoon_> they are
<teythoon_> even if you do another chroot
<braunr> what i mean is
<teythoon_> that root port also points to a fakeroot port
<braunr> if we detach the translator, and clients outside the chroot spawn
processes, say shell scripts, they won't find the fakeroot tree
<braunr> now, i wonder if we want to actually handle that
<braunr> i'm just uncomfortable with a translator silently shutting down
because it has no client
<teythoon_> if fakeroot is detached, how are clients outside the chroot
ever supposed to get a handle to files inside the fakerooted env ?
<braunr> it makes sense for fakeroot, so the expected behaviours here aer
<braunr> they had those before fakeroot being detached
<teythoon_> then fakeroot wouldn't go away
<braunr> right
<braunr> unless there is a race but i don't think there is
<teythoon_> there isn't
<teythoon_> i call netfs_shutdown
<braunr> clients get the rights before the parent has a chance to terminate
<teythoon_> and only shutdown if it doesn't return ebusy
<braunr> makes sense
<braunr> ok go ahead :)
<teythoon_> cool, thanks for the walk-through ;)
<braunr> on the other hand ..
<braunr> that's a complicated topic left unfinished by the original authors
<teythoon_> one of many
<braunr> having translators automatically go away when there is no client
may be a good feature
<braunr> but it only makes sense for passive translators
<braunr> and this should be automated
<braunr> the lib*fs libraries should be able to handle it
<teythoon_> or, we could go for proper persistence instead
<braunr> stay around if active, leave after a while when no more clients if
<braunr> why ?
<teythoon_> clean solution
<braunr> persistence looks much more expensive to me
<teythoon_> other benefits
<braunr> i mean
<braunr> persistence looks so expensive it doesn't make sense in a general
purpose system
<teythoon_> sure, we could make our *fs libs handle this smarter at a much
lower cost
<teythoon_> don't we get a handle to the underlying file ?
<braunr> i think we do yes
<teythoon_> if that's actually a file and not a directory, we could store
data into it
<braunr> many translators are read-only
<teythoon_> so ?
<braunr> well, when we can write, we can use passive translators instead
<braunr> normally
<teythoon_> yes
<braunr> depends on the fs type actually but you're right, we could use
regular files
<braunr> or a special type of file, i don't know
<antrik> braunr: BTW, I agree that active translators should only go away
when no ports are open anymore, while passive ones can exit when control
ports are still open but no protids
<teythoon> antrik: you mean as a general rule ?
<teythoon> that leaves the question how the translator distinguishes
between having a passive translator record and not having one
<antrik> I believe I already arrived at that conclusion in some design
discussion, probaly regarding namespace-based translator selection
<antrik> teythoon: yeah, as a general rule
<teythoon> interesting
<antrik> currently there are command line arguments controling timeouts,
but they don't consider control ports IIRC
<teythoon> i thought there are problems with shutting down translators in
<antrik> (also, command line arguments seem inconvenient to distinguish the
passive vs. active case...)
<teythoon> yeah, but we disregard the timeouts in the debian flavor of hurd
<antrik> teythoon: err... no we don't. at least not last time I knew. are
you confusing this with thread timeouts?
<antrik> simple test: do ls -l on /dev, wait a few minutes, compare
<teythoon> what do you expect will happen ?
<antrik> the unused translators should go away
<teythoon> no
<antrik> that must be new then
<teythoon> might be, yes
<braunr> antrik: debian currently disables both the global and thread
timeouts in libports
<braunr> my work on thread destruction consists in part in reenabling
thread timeouts, and my binary packages do that well so far :)
<antrik> braunr: any idea why the global timeouts were disabled?
IRC, freenode, #hurd, 2013-12-20
<braunr> antrik: not sure
<braunr> but i suspect there could be races
<braunr> if a message arrives while the server is going away, i'm not sure
the client can determine this and retry transparently
<antrik> good point... not sure how that is supposed to work exactly
IRC, freenode, #hurd, 2013-12-31
<braunr> btw, we should remove the libports_stability patch and directly
change the upstream code
<braunr> if you agree, i can force the global timeout to 0 (because we're
still not sure what can go wrong when a translator goes away while a
message is being delivered to it)
<braunr> i didn't experience any slowdown with thread destruction however
<braunr> so i'm tempted to set that to an actual reasonable timeout value
of 30-300 seconds
<teythoon> braunr: if you do, please introduce a macro for the default
value so it can be changed easily
<braunr> teythoon: yes
<braunr> i don't understand why these are left as parameters tbh
<teythoon> true
<braunr> 30 seconds seems to be plenty enough
IRC, freenode, #hurd, 2014-01-17
<braunr> time to give fakeroot-hurd a shot
<braunr> http://darnassus.sceen.net/~rbraun/darnassus_fakeroot_hurd_assert
<teythoon> braunr: (wrt fakeroot-hurd) well in my book that shouldn't
<teythoon> that's why i put the assertion there ;)
<braunr> i assumed so :)
<teythoon> then again, /me does not agree with "threads" as concurrency
model >,<, and that feeling seems to be mutual :p
<braunr> ?
<teythoon> well, obviously, the threads do not agree with me wrt to that
<braunr> the threads ?
<teythoon> well, fakeroot is a multithreaded server
<braunr> teythoon: i'm not sure i get the point, are you saying you're not
comfortable with threads ?
<teythoon> that's exactly what i'm saying
<braunr> ok
<braunr> coroutines/functional i guess ?
<teythoon> csp
<teythoon> functional not so much
IRC, freenode, #hurd, 2014-01-20
libpthread, fix have kernel resources.
<braunr> teythoon: it's perfectly possible that the bug i had with
fakeroot-hurd have been caused by my own glibc thread related patches
<braunr> has*
<teythoon> ok
<teythoon> *phew* :p
<braunr> :)
<teythoon> i wonder if youpi could reproduce his issue on his machine
<braunr> what issue ?
<braunr> i must have missed something
<teythoon> some package failed
<teythoon> but he didn't gave any details
<teythoon> he wanted to try it on his vm first
<braunr> ok
IRC, freenode, #hurd, 2014-01-21
<braunr> teythoon: i still get the same assertion failure with
<braunr> will take a look at that sometimes too
<teythoon> braunr: hrm :/
<braunr> teythoon: don't worry, i'm sure it's nothing big
<braunr> in the mean time, there are updated hurd and glibc packages on my
repository with fixed tls and thread destruction
<teythoon> cool :)
IRC, freenode, #hurd, 2014-01-23
<braunr> teythoon: can you briefly explain this fake reference thing in
fakeroot when you have some time please ?
<teythoon> braunr: fakeroot creates ports to hand out to clients
<teythoon> every port represents a node and references a real node
<teythoon> fakeroot allows one to set attributes, e.g. file permissions on
any node as if the client was root
<teythoon> those faked attributes are stored in the node objects
<braunr> let's focus on fake_reference please
<teythoon> once some attribute is faked, that node has to be kept alive
<teythoon> otherwise, that faked information is lost
<teythoon> so if the last peropen object is closed and some information is
faked, a fake reference is kept
<teythoon> as indicated by a flag
<braunr> hm
<teythoon> in dir lookup, if a node is looked-up that has a fake reference,
it is recycled, i.e. the flag cleared and the referecne count is not
<teythoon> so every time fakeroot_netfs_release_protid is called b/c, the
node in question should not have the fake reference flag set
<braunr> what's the relation between the number of hard links and this fake
reference ?
<teythoon> i don'
<teythoon> i don't think fakeroot has a notion of 'hard links'
<braunr> it does
<braunr> the fake reference is added on nodes with a hard link count
greater than 0
<braunr> but i guess that just means the underlying node still exists
<teythoon> ah yes
<teythoon> right
<teythoon> currently, if the real node is deleted, the fake node is still
kept around
<braunr> let's say it's ok for now
<teythoon> that's what the comment is talking about, the one that indicates
that garbage collection could help here
<teythoon> yes
<teythoon> properly fixing this is difficult
<braunr> agreed
<braunr> it would require something like inotify anyway
<teythoon> b/c of the way file deletion works
<braunr> let's just ignore the issue, that's not what i'm hunting
<teythoon> agreed
<braunr> the assertion i have is telling us that we're dropping a fake
<braunr> are we certain this isn't possible ?
<teythoon> that function is called if a client dereferences a port
<teythoon> in order to have a port in the first place, it has to get it
from a dir_lookup
<teythoon> the dir lookup turns a fake reference into a real one
<teythoon> so i'm certain of that (barring a race condition somewhere)
<braunr> ok
<braunr> netfs_S_dir_lookup grabs idport_ihash_lock (line 354) but doesn't
release it if nn == NULL (lines 388-392)
<teythoon> hm, my file numbers are slightly different o_O
<braunr> i have printfs around
<braunr> sorry :)
<teythoon> ok
<teythoon> new node unlocks it
<teythoon> new_node
<braunr> oh
<braunr> how unintuitive ..
<teythoon> yes, don't blame me ;) that's how it was
<braunr> :)
<braunr> worse, the description says "if successful" ..
<braunr> ah no, the node lock
<braunr> ok
<teythoon> yes, badly worded description
<braunr> i strongly doubt it's a race
<teythoon> how do you trigger that assertion failure ?
<braunr> dpkg-buildpackage -rfakeroot-hurd -uc -us
<braunr> for the hurd package
<braunr> very similar to one of your test cases i think
<teythoon> umm :-/
<braunr> one thing that i find confusing is that fake_reference seems to
apply to nodes, whereas release_protid is about, well, protids
<braunr> is there a 1:1 relationship ?
<braunr> since there is a peropen in the protid, i assume not
<braunr> it may be a race actually
<braunr> np->references must be accessed with netfs_node_refcnt_lock locked
<braunr> hm no, that's not it
<teythoon> no, it's not a 1:1 relationship
<teythoon> note that the lock idport_ihash_lock serializes most operations,
despite it's name indicating that it's only for the hash table
<teythoon> the "interesting" operations being dir_lookup and release_protid
<braunr> yes
<braunr> again, that's another issue
<teythoon> why ? that's a pretty strong guarantee already
<braunr> ah yes, i was referring to scalability
<teythoon> sure
<braunr> the assertion is triggered from ports_port_deref in
<teythoon> but i found it hard to reason about fakeroot, there are multiple
locks involved, two kinds of reference counting across different libs
<braunr> yes
<teythoon> yes, that's to be expected
<braunr> teythoon: do we agree that the fake reference is reused by a
protid ?
<teythoon> braunr: yes
<braunr> why is there a ref counter for the protid as well as the peropen
then ? :/
<teythoon> funny... i thought there was no refcnt for the peropen objects,
but there is
<teythoon> but for fakeroot-hurd that shouldn't matter, right ?
<braunr> i don't know
<teythoon> here, one protid object is associated with one peropen object
<braunr> yes
<teythoon> and the other way around, i.e. it's 1:1
<teythoon> so the refcount for those should be identical
<braunr> but i get a case where protid has a refcnt of 0 while the peropen
has 2 ..
<teythoon> umm, that doesn't sound right
<braunr> teythoon: ok, it does look like a race on np->references
<braunr> node references are protected by a global lock in lib*fs libs
<teythoon> yes
<braunr> you check it without holding it
<braunr> which means another protid can be closed at the same time, setting
the flag on the underlying node
<braunr> i'll make a proper patch soon
<teythoon> they cannot both hold the hash lock
<braunr> hm
<braunr> teythoon: actually, i don't see why that's relevant
<braunr> one thread closes its protid, sets the fakeref flag
<braunr> the other does the same, chokes on the assertion
<braunr> serially
<teythoon> i'm always a little fuzzy when exactly the references get
<teythoon> but shouldn't only the second thread set the fakeref flag ?
<braunr> well, that's not what i see
<braunr> i'll check what happens to this ref counter
<teythoon> see how my release_protid function calls netfs_release_protid
just after the out label
<teythoon> *while holding the big hash lock
<teythoon> so, any refcounting should happen while the lock is being held,
no ?
<braunr> perhaps
<braunr> now, my logs show something new
<braunr> a case where the protid being released was never printed before
<braunr> i.e. not obtained from dir_lookup
<braunr> or at least, not fakeroot dir_lookup
<teythoon> huh, where did it came from then ?
<braunr> no idea
<teythoon> only dir_lookup hands out those
<braunr> check_openmodes calls dir_lookup too
<teythoon> yes, but that's not our dir_lookup
<braunr> that's what i mean
<braunr> it bypasses fakeroot's custom dir_lookup
<braunr> but i guess the reference already exists at this point
<teythoon> bypass ? i wouldn't call it that
<braunr> you're right, wrong wording
<teythoon> it accesses files on other translators
<braunr> yes
<braunr> the netnode is already present
<teythoon> yes
<braunr> could it be the root node ?
<teythoon> i do not believe so
<teythoon> the root node is always faked
<teythoon> and is handed out to the first process in the fakeroot env for
it's current directory port
<teythoon> so you could try something that chdirs away to test that
<braunr> the assertion looks triggered by a chdir
<teythoon> how do you know that ?
<braunr> dh_auto_install: error: unable to chdir to build-deb
<teythoon> ah
<teythoon> well, or that is just the operation after fakeroot died and
completely unrelated
<braunr> maybe
<teythoon> can you trigger this reliably ?
<braunr> yes
<braunr> i'm trying to write a shell script for that
<teythoon> so for you, fakeroot-hurd never succeeded in building a hurd
package ?
<braunr> no
<teythoon> on darnassus ?
<braunr> yes
<teythoon> b/c i stopped working on fakeroot-hurd when it was in a
good-enough shape to build the hurd package
<teythoon> >,<
<teythoon> maybe my system is not fast enough to hit this race (if it turns
out to be one)
<braunr> some calls seems to decrease the refcount of the root node
<braunr> call*
<teythoon> have you confirmed that it's the root node ?
<braunr> almost
<braunr> i could say yes
<braunr> teythoon: actually no, it's not ..
<braunr> could be ..
<braunr> teythoon: on what node does fakeroot-hurd install the fakeroot
translator when used to build debian packages ?
<braunr> hum
<braunr> could it simply be that the check on np->references should be
moved above the assertion ?
<teythoon> braunr: it is not bound to any node, check settrans --chroot
<braunr> oh right
<braunr> teythoon: ok i mean
<braunr> does it shadow / ?
<braunr> looks very likely, otherwise the chroot wouldn't work
<teythoon> i'm not sure what you mean by shadow
<braunr> settrans --chroot cmd -- / /hurd/fakeroot ?
<teythoon> but yes, for any process in the chroot-like env every real node
is replaced, including /
<braunr> makes sense
<braunr> teythoon: moving the assertion seems to fix the issue
<braunr> intuitively, it seems reasonable to assume the fakeref flag can
only be set when there is only one reference, namely the fake reference
<braunr> (well, the fake ref, recycled by the last open)
<teythoon> no, i don't follow
<teythoon> i'd still say, that if ...release_protid is called, then there
is no way for the fake flag to be set in the first place
<teythoon> that's why i put the assertion in ;)
<braunr> on the other hand, you check the refcnt precisely because other
threads may have reacquired the node
<teythoon> but why would moving the assertion change anything ?
<teythoon> if we would do that, we'd "lose" all threads that see
np->reference being >1
<teythoon> but for those objects the fake_reference flag should never be
set anyways
<teythoon> i cannot see why this would help
<teythoon> (does it help ?)
<teythoon> (and if it does, it points to a serious problem imho)
<braunr> i'm recreating the traces that made me think that
<braunr> to get a clearer view of what's happening
<braunr> the problem i have with the current code is this
<braunr> there can be multiple protid referring to the same node occurring
at the same time
<braunr> they are serialized by the hash table lock, ok
<braunr> but there apparently are cases where the first (of two) protids
being closed sets the fakeref flag
<braunr> and the following chokes because the flag is set
<braunr> i assume you put this refcount check because you assumed only the
last protid being closed can set the flag, right ?
<braunr> but then, why > 1 ? why not > 0 ?
<teythoon> yes, that's what i was trying to assert
<teythoon> b/c the 1 is our reference
<braunr> which one exactly ?
<teythoon> >1 is anyone *beside* us
<teythoon> ?
<braunr> hm
<braunr> you mean the reference held by the protid being destroyed
<teythoon> yes
<braunr> isn't that reference already dropped before calling the cleanup
function ?
<braunr> ah no, it's the node ref
<teythoon> yes
<braunr> released by netfs_release_protid
<teythoon> exactly
<braunr> which is called without the hash table lock held
<braunr> hm no
<braunr> it's locked
<braunr> damn my brain is slow today
<teythoon> i actually think that it's the combination of manual reference
counting and the primitive concurrency model that makes it hard to reason
about this
<braunr> well
<braunr> the model is quite simple too
<braunr> accesses to refcounters must be protected by the appropriate lock
<braunr> this isn't done here, on the assumption that all referencing
operations are protected by another global lock all the time
<teythoon> even if a model is simple, this does not mean that it is a good
model for human beings to comprehend and reason about
<braunr> i don't know
<braunr> note that netfs_drop_node is designed to be called with
netfs_node_refcnt_lock locked
<braunr> implying the refcount must remain stable between checking it and
dropping the node
<braunr> netfs_make_peropen is called without the hash table lock held in
<braunr> and this increases the refcount
<braunr> although the problem is rather that something decreases it without
the lock held
<teythoon> we should port libtsan and just ask gcc -fsanitize=thread
<braunr> what about the netfs_nput call at the end of dir_lookup ?
<braunr> the fake ref should be set by the norefs function
<teythoon> that should not decrease the count to 0 b/c the caller holds a
reference too
<braunr> yes that's ugly
<braunr> ugh
<braunr> i'm unable to think clearly right now
<teythoon> as mentioned in the commit message, you cannot do something like
this in the norefs function
<teythoon> bbl ;)
<braunr> bye teythoon
<braunr> thanks for your time
<braunr> for when you come back :
<braunr> instead of maintaining this "fake" reference, why not assumeing
the hash table holds a reference, and simply count it
<braunr> the same way a cache does
<braunr> and drop that reference when removing a node, either to reflect
the current state of the underlying node, or because the translator is
being shut down ?
<braunr> why not assume*
<braunr> bbl too
<teythoon> sure, refactoring is definitively an option
IRC, freenode, #hurd, 2014-01-24
<braunr> teythoon: ok, i'll take care of fakeroot
<teythoon> braunr: thanks. tbh i was a little fed up with that little
bugger >,<
<braunr> i can imagine
<braunr> considering the number of patches you've sent already
<braunr> teythoon: are you sure about your call to fshelp_lock_init ?
<teythoon> yes, why do you ask ?
<teythoon> (the test case is given in the commit message)
<braunr> it doesn't look right to me to call "init" while the node is
potentially locked
<braunr> i noticed libdiskfs peropen release function takes care of
releasing locks
<braunr> it looks better to me
<teythoon> it's not about releasing the lock
<teythoon> it's about faking the file being closed which implicitly
releases the lock
<braunr> the file is being close
<braunr> closed
<braunr> since it's in the cleanup function
<teythoon> yes, but we keep it b/c the file has faked attributes
<teythoon> did you look at the problem description in the commit message ?
<braunr> we keep the node
<braunr> not the peropen
<teythoon> so ?
<teythoon> the lock is in the node
<braunr> why would libdiskfs do it in the peropen release then ?
<braunr> there is an inconsistency somwhere
<braunr> actually, the lock looks to be per open
<braunr> or rather, the lock is per node, but its status is recorded per
<braunr> allowing the implementation to track if a file descriptor was used
to install a lock and release it when that file descriptor goes away
<teythoon> why would the node be locked ?
<teythoon> locked in what way, file-locking locked ?
<braunr> yes
<braunr> posix explicitely says that file locks must be implicitely removed
when closing the file descriptor used to install them, so that makes
<teythoon> isn't hat exactly what i'm doing ?
<braunr> no
<braunr> you're initializing the file lock
<braunr> init != unlock
<braunr> and it's specific to fakeroot, while it looks like libnetfs should
be doing it
<teythoon> libnetfs would do it
<teythoon> but we prevent that by keeping the node alive
<braunr> again, it's a per open thing
<braunr> and no, libnetfs doesn't release locks implicitely in the current
<teythoon> didn't we agree that for fakeroot one peropen object is
associated with one protid object ?
<braunr> yes
<braunr> and don't keep those alive
<braunr> so let them die peacefully, and fix libnetfs so it releases the
lock as it's supposed to
<braunr> and we* don't
<teythoon> we don't keep those alive
<teythoon> why would we ?
<braunr> yes that's what i wanted to say
<braunr> what i mean is
<braunr> since letting peropens die is already what is being done
<braunr> there is no need for a special handling of locks in fakeroot
<teythoon> oh
<braunr> on the other hand, libnetfs must be fixed
<teythoon> ok, that might very well be true
<teythoon> (we need to bring libnetfs and diskfs closer so that they can be
diff'ed easily)
<braunr> i just wanted to check your reason for using lock_init in the
first place
<braunr> yes ..
<braunr> teythoon: also, i think we actually do have what's necessary to
deal with garbage collection
<braunr> namely, dead-name notifications
<braunr> i'll see if i can cook something simple enough
<braunr> otherwise, merely keeping every node around is also acceptable
considering the use cases
<teythoon> dead-name notifications won't help if the real node disappears,
no ?
<braunr> teythoon: dead name notifications on the real node port :)
<braunr> teythoon: at least i can reliably build the hurd package using
fakeroot-hurd now
<braunr> let's try glibc :)
IRC, freenode, #hurd, 2014-01-25
<teythoon> braunr: awesome :)
<braunr> teythoon: hm not sure :/
<braunr> darnassus got oom
<braunr> teythoon: could be unrelated though
<braunr> teythoon: something has apprently made /home unresponsive :(
<braunr> teythoon: i suspect bots hitting apache and in particular the git
repositories to have increased memory usage
IRC, freenode, #hurd, 2014-01-26
<braunr> teythoon: btw, fakeroot interacts very very badly with other netfs
file systems
<braunr> e.g., listing /proc through it creates lots of nodes
<braunr> i'm not yet sure how to fix that
<braunr> using a dead name notification doesn't seem appropriate (at least
not directly) because fakeroot holds a true reference that prevents the
deallocation of the target node
IRC, freenode, #hurd, 2014-01-27
<braunr> teythoon: good news (more or less): fakeroot is actually leaking a
lot when crossing file systems
<braunr> which means if i fix that, there is a good chance we can use it to
build all packages with it
<braunr> -with it
<teythoon> what do you mean exactly ?
<braunr> if target nodes are from /, there is no such leak
<braunr> as soon as the target nodes are from another file system, ports
rights are leaked
<braunr> that's what fills the kernel allocator actually
<teythoon> oh, so dir_lookup leaks ports when crossing translator
boundaries ?
<braunr> seems so
<teythoon> yeah, that might very well be it
<teythoon> the dir_lookup logic in lib*fs is quite involved :/
<braunr> yes, my simple attempts were unsuccessful
<braunr> but i'm confident i can fix it soon
<teythoon> that sounds good :)
<braunr> i also remove the fake_ref flag and replace it with "accounting
the reference in the hash table" as soon as a node is faked
<teythoon> fine with me
<braunr> these will be the expected leak
<braunr> but they're far less in numbers than what i observe
<braunr> and garbage collection can be implemented later
<braunr> although i would prefer notifications a lot more
<braunr> end of the news, bbl :)
<braunr> found it :>
<teythoon> braunr: -v ;)
<braunr> err = dir_lookup (...);
<braunr> if (dir != dnp->nn->file) mach_port_deallocate (mach_task_self (),
<braunr> in other words, deallocate ports for intermediate file system root
directories .. :)
<braunr> teythoon: currently building hurd and glibc packages
<braunr> but i intend to improve some more with the addition of a default
faked state
<braunr> so that only nodes with modified faked states are retained
<teythoon> how do you mark nodes as having the default faked state ?
<braunr> i don't
<teythoon> ok, right, makes sense :)
<teythoon> this sounds awesome, thanks for following up on this
<braunr> i'm quite busy with other stuff so, with proper testing, it should
take me the week to get merged
<braunr> teythoon: well thanks for all the fixes you've done
<braunr> fakeroot was completely unusable before that
<teythoon> if you push your changes somewhere i'll integrate them into my
packages and test them
<braunr> ok
<braunr> implementing fakeroot -u could also be a good thing
<braunr> and this should work easily with that default faked state strategy
IRC, freenode, #hurd, 2014-01-28
<braunr> teythoon: i should be able to test fakeroot-hurd with the default
faked attributes strategy today on glibc
<teythoon> braunr: very nice :)
<braunr> azeem_: do you happen to know if fakeroot -u is used by debian ?
<braunr> i mean when building packages
<teythoon> braunr: how does fakeroot-hurd perform on darnassus ?
<teythoon> i mean, does it yield a noticeable improvement over fakeroot-tcp
just like on my slow box ?
<braunr> i'm not measuring that :/
<teythoon> ok, no problem
<braunr> and since nodes are removed from the hash table, performance might
decrease slightly
<braunr> but the number of rights is kept very low, as expected
<teythoon> that's good
<braunr> i keep seeing leaks though
<braunr> when switching cwd between file systems
<teythoon> humm
<braunr> so i assume something is wrong with the identity of . or ..
<braunr> it's so insignificant compared to the previous problems that i
won't waste time on that
<braunr> teythoon: the problem with measuring on darnassus is that it's a
public machine
<teythoon> right
<braunr> often scanned by ssh worms or http bots
cannot create dev null interrupted system call.
<braunr> but it makes complete sense to get better performance with
<braunr> that's actually one of the reasons i'm working on it
<braunr> if not the main one
<teythoon> :)
<teythoon> that was my motivation too
<braunr> it shows how you can get an interchangeable unix tool that
directly plugs well with the low level system
<braunr> and make it work better
<teythoon> nicely put :)
<braunr> teythoon: i still can't manage to build glibc with fakeroot-hurd
<braunr> but i'm not sure why :/
<braunr> there was no kernel memory exhaustion this time
<teythoon> :/
<braunr> cp: cannot create regular file `debian/libc-bin.dirs': Permission
<braunr> hum
<braunr> youpi: do you know if building debian packages requires fakeroot
-u option ?
<youpi> I don't know
<gg0> braunr: man dpkg-buildpackage says it just runs "fakeroot
debian/rules <target>"
<gg0> sources confirm that
<braunr> gg0: ok
IRC, freenode, #hurd, 2014-01-29
<braunr> it seems that something sets the permissions of this
debian/libc-bin.dirs file to 000 ...
<teythoon> i've seen this too
<braunr> oh
<braunr> do you think it's a fakeroot-hurd bug ?
<teythoon> have i mentioned something like this in a commit message ?
<teythoon> yes
<teythoon> it is
<braunr> ok
<braunr> i didn't see any mention of it
<braunr> but i could have missed it
<teythoon> hm, i cannot recall it either
<teythoon> but i've seen this issue with fakeroot-hurd
<braunr> ok
<braunr> it's probably the last issue to fix to get it to work for our
<braunr> teythoon: i think i have a solution for that last mode bug
<braunr> fakeroot doesn't relay chmod requests, unless they change an
executable bit
<braunr> i don't see the point, and simply removed that condition to relay
any chmod request
<teythoon> braunr: did it work ?
<braunr> no
<braunr> fakeroot still consumes too many ports
<braunr> and for each file, there are at least two ports, the faked one,
and the real one
<braunr> it should be completely reworked
<braunr> but i don't have time to do that
<braunr> i'll see if it works when building from scratch
<braunr> actually, it's not even a quantity problem but a fragmentation
<braunr> the function that fails is kmem_realloc ..
<braunr> ipc spaces are arrays in kernel space ....
<teythoon> it's more like three ports per file, you forgot the identity
<braunr> ah yes
IRC, freenode, #hurd, 2014-02-03
<braunr> teythoon: i'll commit my changes on fakeroot tonight
<braunr> they do improve the tool, but not enough to build glibc with it
<teythoon> braunr: cool :), so how do we make it fully usable ?
<braunr> teythoon: i don't know ..
<braunr> i'll try re adding detection of nodes with no hard links for one
<braunr> but imho, it needs a rework based on what the real fakeroot does
<braunr> i won't work on it though
<braunr> teythoon: also, it looks like i've tested building glibc with a
wrong test binary of my fakeroot version :/
<braunr> so consider all test results irrelevant so far
IRC, freenode, #hurd, 2014-02-04
<braunr> fakeroot-hurd might turn out to be easily usable for our debian
packages with the fixed binary :)
<braunr> teythoon: hum, can you explain
672005782e57e049c7c8f4d6d0b2a80c0df512b4 (trans: fix locking issue in
fakeroot) when you have time please ?
<braunr> it looks like it introduces a deadlock by calling new_node (which
acquires the hash table lock) while dir is locked, violating the hash
table -> node locking order
<teythoon> braunr: awesome, then there still is hope for fakeroot-hurd :)
<braunr> teythoon: i've been able to build glibc packages several times
this night
<braunr> so except for this deadlock i've seen once, it looks good
<teythoon> right
<teythoon> that deadlock
<teythoon> right, it does indeed violate the partial order of the locks :-/
<braunr> teythoon: can you explain why you moved the lock in attempt_mkfile
please ?
<braunr> teythoon: i've just tested a fakeroot binary without the patch
introducing the deadlock, and glibc built without any problem
<teythoon> braunr: well, this is very good news :)
<braunr> teythoon: but i still wonder why you made this patch in the first
place, i don't want to revert it blindly and reintroduce a potential
<teythoon> braunr: i thought i was fixing the order in which locks were
taken. if the commit message does not specify that it fixes an issue,
then i was probably just wrong and you can revert it
<braunr> oh ok
<braunr> good
<braunr> teythoon: another successful build :)
<braunr> i'll commit my changes
<teythoon> awesome :)
<braunr> there might still be concurrency issues but it's much better
<teythoon> i'm curious what you did :)
<braunr> so little :)
<braunr> i was sick all week heh
<braunr> you'll se
<braunr> see
<teythoon> well, that's good actually ;)
<braunr> yes
<braunr> teythoon: actually there was another debugging line left over, and
again, my test results are irrelevant @#!
IRC, freenode, #hurd, 2014-02-05
<braunr> teythoon: i got an assertion about nn->np->nn not being equal to
nn atfer the hash table lookup is dir_lookup
<braunr> +failure
<teythoon> that's bad
<braunr> not over yet
<teythoon> i had a couple of those too
<teythoon> i guess it's a use after free
<braunr> yes
<teythoon> i used to poison the pointers and comment out the frees to track
them down iirc
<braunr> teythoon: one of your patches stores netnodes instead of nodes in
the hash table, citing some overwriting issue
<braunr> teythoon: i don't understand why using netnodes fixes this
<teythoon> braunr: libihash has this cookie for fast deletes
<teythoon> that has to be stored somewhere
<teythoon> the node structure has no room for it
<braunr> uh
<teythoon> yes
<teythoon> it was that bad
<braunr> ...
<teythoon> hence the uglyish back pointers
<braunr> i see
<teythoon> looking back i cannot even say why it worked at all
<braunr> well, it didn't
<teythoon> i believe libihash must have destroyed a linked list in the node
<braunr> possibly
<teythoon> no, it did not >,<, but for simple tests it kind of did
<braunr> yes fakeroot sometimes corrupts memory badly ....
<braunr> and yes, turns out the assertion is triggered on nodes with 0 refs
<braunr> teythoon: it looks like even the current version makes wrong usage
of the ihash interface
<braunr> locp_offset is defined as "The offset of the location pointer from
the hash value"
<braunr> and indeed, it's an intptr_t
<braunr> teythoon: hm no, it looks ok actually, forget what i said :)
<teythoon> *phew
<teythoon> :p
<braunr> hmm, still occasional double frees in fakeroot, but it looks in
good shape for single threaded tasks like package building
<braunr> teythoon: i've just sent my fakeroot patches
<teythoon> braunr: sweet, i'll have a closer look tomorrow :)
<braunr> teythoon: i couldn't debug the double frees though :/
IRC, freenode, #hurd, 2014-02-06
<braunr> btw, i'm able to successfully use fakeroot-hurd to build glibc
packages, but is there a way to make sure the resulting archives contain
the right privileges and ownerships ?
<youpi> I don't remember whether debdiff checks permissions
<youpi> braunr: I've just got fakeroot-hurd debian/rules clean
<youpi> dh_clean
<youpi> fakeroot: ../../trans/fakeroot.c:161: netfs_node_norefs: Assertion
`np->nn->np == np' failed.
<youpi> while building eglibc
<teythoon> youpi: yes, that lockup is most annoying... :/
<braunr> youpi: with the new version ?
<youpi> yes
<braunr> hum
<braunr> i only had rare double frees, not that any more :/
<braunr> youpi: ok i got the error too
<braunr> still not good enough
<youpi> ok
IRC, freenode, #hurd, 2014-02-07
<braunr> youpi: debdiff seems to handle permissions
<braunr> i've found the cause of the assertions
<youpi> braunr: groovie :)
IRC, freenode, #hurd, 2014-02-08
<teythoon> braunr: nice :)
<braunr> http://darnassus.sceen.net/~rbraun/debdiff_report
IRC, freenode, #hurd, 2014-02-10
<braunr> and, on a completely different topic, here is a crash i can
reproduce when using fakeroot:
IRC, freenode, #hurd, 2014-02-11
<braunr> still working on fakeroot
<braunr> there are still races (not disturbing for package building but
still ..)
<braunr> there may be wrong right handling
<teythoon> i believe i have witnessed a fakeroot deadlock :/
<braunr> aw
<teythoon> not sure though, buildbot killed the build process before i
could investigate
<braunr> teythoon: was it a big package ?
<teythoon> half of the hurd package
<braunr> that's not a port right overflow then
IRC, freenode, #hurd, 2014-03-05
<teythoon> youpi: what about the exec_filename patch series? even though
fakeroot still has some issues (has it?), i consider it worthy for
<youpi> Roland was disagreeing with it
<youpi> iirc the fakeroot issue was solved
<teythoon> braunr: ^
<braunr> fakeroot goot a lot more robust than it used to be
<braunr> but i haven't checked that it actually behaves exactly like the
library for corner cases
<braunr> there are minor differences
<braunr> also, it seems to trigger concurrency bugs in ext2fs
<braunr> e.g. git reporting that files either "already exist" or "can't be
<braunr> it happens (rarely) when directly using ext2
<braunr> and more often through fakeroot
<braunr> i didn't take the time to investigate
the daily script of debian-installer uses the -s / -i options of fakeroot. How could we manage to implement them?


text:
Inside the Book:
Title: In Jesus' Arms
Author: Mary E. Keenan
Publisher: iUniverse
Genre: Religion
Format: Ebook
In In Jesus' Arms: One Woman's Trip to Heaven, author Mary E. Keenan shares here amazing journey being in the arms of Jesus Christ. Opening with the story of her life as an unworthy sinner who once rejected God's forgiveness—but who found restoration through a relationship with Christ—she reveals her experience of being held and carried by Jesus as she and Christ walked together on the earth and ascended to heaven. There, Mary receives Christ's lessons and is able to offer a glimpse into the inner workings of heaven, the mind of Christ, the preparations for the second coming, and the important messages God wants individuals and churches to heed today about the difference between faith and religious practice.
Whether you are a curious and skeptical unbeliever, a believer who avoids the church, or an active church member involved in the pastorate or other Christian organizations, In Jesus' Arms will compel you to delve deeper into the scriptures and provide you with a joyous, hopeful account of a victorious Christ—where His lessons from the past are still current, where His plans are being carried out, and where heaven is still very much involved in our lives.
Meet the Author:
Mary E. Keenan was born and raised in Lancaster County, Pennsylvania, and she has a master's degree in adult and technical education from Marshall University, West Virginia. Now retired from a career in nursing administration and education, she loves to paint and lives with her husband, Dale, in Weirton, West Virginia.
Mary is giving away a $25 Gift Card!
Terms & Conditions:
- By entering the giveaway, you are confirming you are at least 18 years old.
- One winner will be chosen via Rafflecopter to receive one $25 Gift Certificate to the e-retailer of your choice
- This giveaway begins November 14 and ends on November 25.
- Winners will be contacted via email on November 26.
- Winner has 48 hours to reply.

subset: commoncrawl


text:
View Photo Gallery
Remove ads with our VIP Service Ratings / Reviewssequences of sci-fi action violence and brief mild language View movie reviews Tron Legacy in 3D Academy Award® Nominee A 3D high-tech adventure set in a digital world that's unlike anything ever captured on the big screen. Sam Flynn (GARRETT HEDLUND), the tech-savvy 27-year-old son of Kevin Flynn (JEFF BRIDGES), looks into his father's disappearance and finds himself pulled into the same world of fierce programs and gladiatorial games where his father has been living for 25 years. Along with Kevin's loyal confidant (OLIVIA WILDE), father and son embark on a life-and-death journey across a visually-stunning cyber universe that has become far more advanced and exceedingly dangerous. Starring Jeff Bridges, Garrett Hedlund, Olivia Wilde, Bruce Boxleitner, MIchael Sheen, James Frain Directed by Joseph Kosinski Running Time - 2:07 Genre - Action/Adventure Opened in Theaters - Friday, December 17, 2010 (13 years ago) aka Tron Legacy in Disney Digital 3D ShowtimesThis movie is not currently playing in theaters. Home VideoThis movie may be available now on home video.MultimediaRelated News Articles and Web SitesOther Informationaka Tron Legacy in Disney Digital 3D Looking for More Information?Search Google for more information about this movie: |
New Movies - Box Office - Favorite Movies - All Movies
Coming Soon - Search
Home - About Us - Feedback
News Headlines - Theaters - Movies - Reader Reviews - Movie Links
Your Account - VIP Service
News Headlines - Theaters - Movies - Reader Reviews - Movie Links
Your Account - VIP Service
The BigScreen Cinema Guide is a service of SVJ Designs LLC. All graphics, layout, and structure of this service (unless otherwise specified) are Copyright © 1995-2024, SVJ Designs. The BigScreen Cinema Guide is a trademark of SVJ Designs. All rights reserved. 'ACADEMY AWARDS®' and 'OSCAR®' are the registered trademarks and service marks of the Academy of Motion Picture Arts and Sciences. |


text:
We love our volunteers! Please visit our volunteer page for more information.
Show All Answers
Your library card is your key to access materials, digital media, public computers, and so much more! The possibilities are limitless - get your card today!
Visit our Library Card page for more information on how to get your card.
The following individuals are eligible to receive a library card:
There are two types of library memberships: E-Memberships and Standard Memberships. For either type of membership, begin by registering through our Online Catalog site.
Visit our Renewal page to learn how and when you can renew your checked out items.
You can borrow material from other libraries through the Interlibrary Loan (ILL) program. All you need is a valid Newport News library card in good standing. Visit the Interlibrary Loan page for more details!
If there is a specific title, author, or series that is hard to find and you would like to see it in our library, or maybe you think we need to have more information about a specific subject, you may fill out the online Purchase Suggestion Form to submit your suggestion! All requests will be evaluated based on our library collection development policies and the availability of funds. Please include only one title, author, series or subject per request.


text:
NEW YORK (AP) — Calling the players' offer "fair for both sides," star quarterbacks Tom Brady, Peyton Manning and Drew Brees — plaintiffs in the antitrust suit against the NFL — said Wednesday "it is time" to wrap up negotiations on a deal to end the league's lockout.
Brady, Manning and Brees spoke as a group publicly for the first time with talks in a critical phase, four months into the league's first work stoppage since 1987. Players and owners were gathering Wednesday morning at a Manhattan office building for the latest round of discussions.
Deadlines are coming up next week to get training camps and the preseason started on time. Although it seems the sides have agreed on the basic elements of how to split more than $9 billion in annual revenues, among the key sticking points recently have been how to structure a new rookie salary system and what free agency will look like.
In a statement released to The Associated Press via the NFL Players Association, New England's Brady, Indianapolis' Manning and New Orleans' Brees said: "We believe the overall proposal made by the players is fair for both sides and it is time to get this deal done."
The statement continued: "This is the time of year we as players turn our attention to the game on the field. We hope the owners feel the same way."
Brady, Manning and Brees are among 10 players who are named plaintiffs in the antitrust suit that is pending in federal court in Minnesota. That class-action lawsuit was filed March 11, hours after federally mediated negotiations to arrive at a new collective bargaining agreement broke down, and the old labor contract expired. The NFLPA immediately dissolved itself, meaning players no longer were protected under labor law but instead were allowed to take their chances under antitrust law.
On March 12, the owners imposed a lockout on the players, a right management has to shut down a business when a CBA expires. During the lockout, there can be no communication between the teams and current NFL players; no players — including those drafted in April — can be signed; teams won't pay for players' health insurance.
A series of court rulings followed, including one last week from an appeals court that said the lockout could continue.
Talks resumed in May, overseen by a court-appointed mediator, U.S. Magistrate Judge Arthur Boylan, who is on vacation this week. Boylan ordered both sides to speak with him in Minneapolis next Tuesday, and the owners have a special meeting set for July 21 in Atlanta, where they could vote to ratify a new deal if one is reached.
That means there's intense pressure on NFL Commissioner Roger Goodell and NFLPA head DeMaurice Smith to keep things moving in a positive direction. Disruptions to the planned preseason schedule would decrease the overall revenue pie.
Smith was among those arriving Wednesday morning for talks, along with powerful team owners Robert Kraft of the Patriots, John Mara of the New York Giants and Jerry Jones of the Dallas Cowboys.
Copyright 2011 The Associated Press.


text:
It's up to the wingnuts. If they want to keep lying about Obama, then we'll do our best to set the record straight. If they want to bring up legitimate criticism, and there's plenty of it, then we'd likely join them, and we could all have an Obama bashing party together. But they're not that smart.
So as long as the wingnut media --- and thus, virtually the entire corporate media --- insist on using the people's airwaves to lie to the people (eg., Rush Limbaugh continues to repeat every day what a "complete failure" the economic stimulus package has been), I guess we'll just have to keep countering that phony message by posting the truth in order to try to offer some balance to the unending stream of lies from the GOP and their extremely effective mouthpieces across the near-entirety of the corporate media.
Rachel Maddow did the same last week in her lead-up piece to Obama's first State of the Union address, in which she brutally attacked the Administration's call for a partial spending freeze, even as the economy, thanks in no small part to Government investment, struggles to come out of its tailspin.
Before her critique however (which I hope you'll watch in full --- it's embedded below), she also pointed out the salient, indisputable facts of how responsible actions taken by the Obama Administration, whether you liked them or not --- and as opposed by virtually every single Republican in Congress --- have, in fact, with all of their many failings, helped shore up, and even reverse for now, what had been a near-death spiral by the time Obama finally took office.
Here are two charts from her report which highlight that point quite simply, and help to counter the loud, GOP-spun political/partisan nonsense echoed, naturally, by the gullible tea baggers...
[NOTE: Since Maddow's report last week, the GDP figures for the 4th quarter of last year have now been announced and the up trend continues. As her original chart included data only through the 3rd quarter of last year, we've augmented that original chart below to reflect the recently announced 5.7% growth in GDP for the 4th quarter of '09]:
Love him or hate him, or anything in between, recognition of the overall effect of the broad points of Obama's emergency economic policies --- quickly passed at an historic moment of looming disaster --- is due. At least along with any honest appraisal of those policies.
Maddow's entire report, both praising and critiquing Obama and those policies --- something known as "fairness and balance" --- can be watched below...


text:
BillboardIn its 114th year, Billboard remains the world's premier weekly music publication and a diverse digital, events, brand, content and data licensing platform. Billboard publishes the most trusted charts and offers unrivaled reporting about the latest music, video, gaming, media, digital and mobile entertainment issues and trends. |
Términos y frases comunes
A&M Records album Alpert American Angeles April Association Award for opera ball bowler Batman BEST Billboard Capitol cent chart Chicago cigaret classical Coin Machine Columbia Records Concerto convention Corp Decca director disk Distributing distributors equipment Evelyn Lear firm flipper GEMA Grammy Award handle Herb Alpert Hotel industry Japan jazz Johnny label LP's major manager Manufacturing March March 26 ment merchandise Mercury MGM Records Mike Miller Smash Records Miss Lear Muntz NARAS Nashville operators Orch ords Paul Francis Webster PERFORMANCE phonograph piano Pitney Polydor president promotion puck Radio RCA Victor Records recently record company record dealers release Reprise Records Rock-Ola Roger Miller Sandler score sell Sinatra single Solish SOLOIST song soundtrack SPECIAL MERIT Stars stereo Symphony tape CARtridge tion tour vending VOCAL World Wide Wurlitzer York


text:
A GoFundMe for a Surrey woman, killed by a runaway cargo van in the Sullivan Heights neighbourhood, has raised more than $50,000 in less than 24 hours.
Paramjit Masutta was killed by a runaway cargo van on Dec. 15 after it rolled down 144th Street, near 61A Avenue. It happened around 2:45 p.m. on Tuesday (Dec. 15).
READ ALSO: Pedestrian struck and killed by driverless vehicle near Surrey's Sullivan Heights Secondary, Dec. 15, 2020
Police said two vehicles were involved in the crash, adding that "early indications" were that an "unoccupied cargo truck rolled into traffic where it struck a vehicle" and then "continued travelling onto the sidewalk" and hit the woman.
Surrey RCMP said the driver of the cargo van stayed at the scene was co-operating with police.
READ ALSO: Surrey RCMP to mechanically inspect cargo van that killed Surrey mom, Dec. 16, 2020
Corporal Joanie Sidhu said the woman was walking her two children home from school when the incident happened.
"She was walking with her two kids. They were uninjured and they are physically OK," Sidhu said of the children. "They are being looked after, I just can't give you the details of who is looking after them. The kids are being looked after."
A GoFundMe was created on Friday (Dec. 18) for Masutta, who was described as a "heroic mother (who) pushed her two little children out of the way," before being hit.
"Paramjit was the most beautiful, dedicated mother to twin girls and a loving wife," reads the GoFundMe. "The family had just moved in the neighborhood and were enjoying a wholesome life before this tragedy suddenly took the road from under them all."
The fundraiser, which is organized by Masutta's husband Daljit, had raised $50,032 by Saturday morning.
The GoFundMe can be found at gofundme.com/f/community-support-for-masutta-family.
The community came together on Dec. 17 to pay tribute to Masutta.
READ ALSO: Dozens pay tribute to Surrey mom killed by runaway cargo van, Dec. 17, 2020
Dozens of people gathered at the intersection of 144th Street and 61A Avenue to lay flowers and pay tribute at the crash site. Families could be see walking down the street and coming out of their homes with flowers in hand.
Penny Barker, who organized the small gathering on Thursday, said she just wanted the community to "pause for a few minutes and be grateful."
"That way the husband knows that we're all on his side and we're thinking about him," she told the Now-Leader.
Meantime, Goldstone Park Elementary principal Laura Grills said in a Dec. 17 newsletter that the school community "suffered a tragic loss earlier this week.
"A parent at our school was the victim of an accident and we are heartbroken for the family. This is a devastating loss and we need to be respectful of the family's privacy as they process their grief," said Grills.
However, she added there have been a "number of families" who have reached out to offer support for the family.
"While your overwhelming kindness is appreciated, at this time please do not drop off items at the school," said Grills, adding that the school's parent advisory committee has volunteered to coordinate monetary donations through the hot lunch website.
To donate, visit goldstonepark.hotlunches.net.
– With files from Tracy Holmes, Tom Zytaruk
Like us on Facebook Follow us on Instagram and follow Lauren on Twitter


text:
I just got an email from Ancestry.com that 15 more states had been added to their 1940 Census collection. Included in these states is one I'm really excited about: Georgia. (Also added: Alabama, Arizona, California, Hawaii, Indiana, Kansas, Kentucky, Michigan, Montana, Nebraska, New Hampshire, Oregon, Washington or Wisconsin)
For the most part, I have already found most of my Georgia ancestors in the 1940 Census - but those are my Dad's relatives. They were farmers who sat in the same place for a few hundred years and made things easy. My mom's ancestors on the other hand... talk about mobile. It's not like they were moving all over the country; they just moved down this street and up this other one and maybe across town or to the neighboring state for just a few months. And they did this constantly.
I had multiple addresses cir 1940 in which to look for my Great-Great Grandparents, Leverett and Louise Waters. They were nowhere to be found. I did find their daughter (my great-grandmother), one of the their daughters-in-law (sans husband) and Leverett's sister-in-law (sans husband).
With today's addition of Georgia into Ancestry's 1940 Census collection, I was able to find Leverett and Louise. I learned that Leverett apparently never had any official schooling (which I had guessed based on his shakily printed signature) and Louise had only four years. At the time Leverett was working as a barber and Louise stayed at home. Their youngest boy, Jack, was still at home.
Now let's just South Carolina indexed and I'll be happy!


text:
Ferguson officer who shot Michael Brown resigns
(AP) -- The white police officer who killed Michael Brown has resigned from the Ferguson Police Department, his attorney said Saturday, nearly four months after the fatal confrontation with the black 18-year-old that fueled protests in the St. Louis suburb and across the nation.
Darren Wilson, 28, has been on administrative leave since the shooting on Aug. 9. His resignation was announced Saturday by one of his attorneys, Neil Bruntrager. The resignation is effective immediately, Bruntrager said. He declined further immediate comment but said he would release more details Saturday night.
The attorney for the Brown family, Benjamin Crump, did not immediately return phone and email messages seeking comment.
A grand jury spent more than three months reviewing evidence in the case before declining in November to issue any charges against Wilson. He told jurors that he feared for his life when Brown hit him and reached for his gun.
The U.S. Justice Department is still conducting a civil rights investigation into the shooting and a separate probe of police department practices.
The shooting struck up a national debate about race and police power.
After the shooting, Wilson spent months in hiding and made no public statements. He broke his silence after the grand jury decision, telling ABC News that he could not have done anything differently in the encounter with Brown.
Wilson said he has a clean conscience because "I know I did my job right." Brown's shooting was the first time he fired his gun on the job, he said.
Asked whether the encounter would have unfolded the same way if Brown had been white, Wilson said yes.
Wilson began his career in nearby Jennings before moving to the Ferguson job a few years ago. He had no previous complaints against him and a good career record, according to Police Chief Thomas Jackson, who called Wilson "an excellent police officer."
A few months before the shooting, Wilson had received a commendation for detaining a suspect in a drug case.


text:
Michael Jackson's Alleged Son -- DNA Test Results Bogus ... Ripped from 'Terminator' Movie
MJ's Alleged Son DNA Test Results Are Bogus Ripped from 'Terminator'
Here's a shocker -- the DNA test results that allegedly prove 31-year-old Brandon Howard is Michael Jackson's son are BOGUS ... in fact, so bogus ... the logo from the so-called DNA testing lab was ripped from "Terminator Salvation."
As we reported, FilmOn.com's Alki David put on a spectacle Thursday -- claiming he had DNA results proving singer B Howard was the biological son of the King of Pop. He then produced the results showing a "99.99999%" probability that MJ was Brandon's dad.
TMZ obtained a photo of the DNA doc -- allegedly from a testing facility in Ireland called "DNA Lab." We searched high and low but could find no such generic DNA lab in Ireland.
Skeptical, we investigated -- a simple Google image search of "DNA results" turns up a bunch of sample docs with the same exact easily-stealable format as the one we got.
But the coup de grace -- we then Google image searched "DNA logo" and the first result ... literally ... was the same DNA pic used in the "DNA Lab" logo.
And that's not even the best part -- a reverse image search of the logo shows a bunch of results for "Terminator Salvation." A little more digging revealed the logo was used on PROMOTIONAL T-SHIRTS for the movie.
Can't say we're all that shocked.


text:
What to Know
- Rapper Juelz Santana ran from Newark Liberty International Airport on Friday after TSA agents found a gun in his bag, sources tell News 4
- The rapper may have gotten into a cab and is currently being sought by Port Authority police, according to the sources
- NBC 4 New York has reached out to Santana's representatives seeking comment
Rapper and actor Juelz Santana allegedly ran away from a security screening at Newark Liberty International Airport Friday evening after law enforcement sources said Transportation Security Administration agents found a gun on him.
Santana, whose real name is LaRon Louis James, was going through the screening at Terminal C about 6 p.m. when sources said agents discovered the firearm.
Sources said that once the "Love and Hip-Hop: New York" star was detected by authorities, he took off running and may have gotten in a taxi.
Port Authority Police Department detectives are currently looking for the Harlem-born performer, according to sources.
The TSA didn't reveal the name of the rapper, citing privacy laws, but said that a passenger going through screening around that time had a gun in his bag. When the passenger realized the gun had been found, the TSA said the man left the airport, leaving his luggage and gun behind.
According to TSA regulations, bringing a weapon to an airport security checkpoint is punishable by a fine and in some cases could lead to an arrest. Fines for loaded guns can top $9,800.
Representatives for Santana did not return NBC 4 New York's calls seeking comment.


text: Watch Darna February 8 2024 Today HD Episode Online. If You are interested in watching Pinoy Tv Replay Dramas online then follow and enjoy PinoyFlix. You can enjoy Darna February 8 2024 only on Pinoy Tambayan which is official website of Pinoy Tv Shows. Enjoy Pinoy Teleserye in High Quality and Medium Quality Depending Upon Your Choice BookMark our website.


text:
Diving Into Seals History
Credit for this clip goes to "werqa123" as he posted the clip on YouTube. Greg Musselman, who was an anchor and Sports Director for ITV Edmonton from 1981-96, filed the following report, and some of the images and facts contained within his story are pretty incredible.
There was no mention of why the Seals were changed to green-and-gold, but everyone assumes that it was due to Finley owning the Oakland Athletics. The Seals officially wore "kelly green, California gold and 'polar bear' white" if you asked Finley. Finley, of course, changed MLB's Athletics to a green-and-gold team with white shoes. For a long time, Finley has stated that the color combination of green and gold was his favorite. However, the June 30, 1970 edition of the Vancouver Sun quoted Finley as saying, "My two daughters are redheads and my wife has dressed them in green and gold since they were born. It'll be the same in hockey."
So if that's the case, he dressed his teams in the same colors as his daughters. The white skates, which look like figure skates in this image, are now more easily explainable when you consider that Finley was modeling his team's look after his wife's and daughters' fashion choices.
For the longest time, it was thought that the players on the Seals had their skates painted white, but Musselman reports that owner Charlie Finley actually bought the team white skates! Of course, there was a backlash from the other owners and, in particular, NHL president Clarence Campbell who is quoted in the Vancouver Sun article as saying, "White skates are for girl fancy skaters."
Marshall Johnston fondly recalls the ridicule the Seals took in their white skates to Evan Weiner of NHL.com. "Back then, I wasn't a physical player anyway, but I remember in Boston one night and some guy hollers over, 'Hey Johnston where's your purse?" he said with a laugh. "But that part of it. It was kind of fun."
Terry Murray wore the white skates in 1972-73, and he elaborates on the painting of the skates in an interview with Evan Weiner.
"Well, the white skates, they got heavier every week, too," Murray told Weiner. "It was just shoe polish and the trainers had to make sure they were white every game and they just got the old white polish out with the applicator and kept piling it out. So it was an extra five pounds by the middle of the season.Pretty interesting, right? We have two teams in the "Big Four" pro leagues dressed as his daughters were dressed, and the white skates were covered in coats and coats of shoe polish. While it wasn't truly paint per se, Terry Murray made it pretty clear that the skates got heavier and heavier as the season progressed. The legend of the Seals' white skates, as well as why they were changed to green and gold, now have a little more weight to them thanks to Mr. Musselman's excellent piece and a little research.
"I don't think we felt good about (wearing the skates), I think we always felt like a little bit of a pansy; maybe the only thing that helped out was that the Oakland A's were playing World Series ball and championship ball at that time and they had the white cleats on. Maybe it helped in our minds a little bit seeing them out there."
Isn't hockey history great? It's even better when you learn that Terry Murray kept his white skates!
Until next time, keep your sticks on the ice!


text:
Demi Lovato Shares New No-Makeup Selfie
Demi Lovato isn't shy about sharing makeup-free selfies. She does it semi-frequently, but every time she does, we're totally compelled to stare and marvel at her physical gifts. Demetria is quite a beauty.
The singer, who just headed out of the country for tour dates, with her new, blondish hair, posted a photo of her lovely face, completely devoid of product, Lovato looks like she just woke up, but her natural beauty asserts itself, even if her eyes show a bit of tiredness.
Lovato, who has cultivated a rocker chick chic through the last several years, is blessed with great features, from her cheekbones to her almond-like eyeshape to her pouty lips, and this photo is evidence of her general loveliness. She doesn't need a lot of product to enhance what she has.
It's also brave of her to post a photo such as this. So many celeb selfies, taken in bed or without makeup, feel posed or anything but spontaneous. In fact, we wouldn't be shocked if said celebs take a minute before posing to throw on a little cover up or even a lip balm. Lovato never shies away from sharing her life with her Lovatics, and this type of photo is just another way she lets us in.
See Demi in all her au naturel glory below.


text:
There are high quality HVAC companies across this nation that can truly be called comfort contractors, and they like being in the minority. Their jobs are sold as complete systems, where sizing, charge, and air flow are fully commissioned and delivered to delighted customers. They have stepped up from simply "swapping boxes," and are taking the time to educate customers on the complete value of high performance installations.
Unfortunately, the majority of contractors are unable to break free of old habits and continue to do business as usual. It is faster and easier to just sell boxes, and to the homeowner, an installation is an installation. Yet, true comfort contractors know there are many sales opportunities and installation steps for a system to operate correctly. All of which are needed to deliver the performance the homeowner is paying for and expecting.
There can be little doubt that the industry has heard this message and the informational tipping point of quality installations are certainly well established. If you don't know what I'm talking about — you may be an "old school Bubba."
You can't be a leader in this industry without knowing that the key to delivering comfort and performance is in the installation. This is even more important with the new higher-efficiency equipment. Higher-efficiency equipment is even more demanding of high-performance installation, this has become increasingly obvious and costly with the 13 SEER mandate.
No one likes callbacks — not the homeowner, not the contracting company, not the technician, and not the manufacturer. Installing to high-performance-standards is your best warranty against these lost margin callbacks.
Energy Star is shifting its focus to include not only labeling high efficiency heating and cooling equipment, but also to promoting high-quality installation practices. Our message is increasing the focus on getting systems properly sized and selected, making needed corrections to the distribution system (before sizing), and confirming that both the air flow and charge meet manufacturer specifications. This is an order of magnitude more difficult than just selling Energy Star qualified equipment — both for the homeowner to understand, and for the contractor to deliver.
Difficult, But Well Worth It
High performance installations are widely discussed in the industry, and there are many opportunities for contractors to learn about advanced installations. Moving away from low-margin box swapping to high-margin, high-performance installation is a challenging business change, made all the more difficult by uninformed homeowners and low-balling "Bubbas."
Energy Star is doing its part in tilting the tipping point toward high performance system installation. But it's time for you to educate your customers. Then your discussion (and price) on delivering quality Energy Star qualified equipment, that is installed correctly, will be better received.
I can understand that some contractors are reluctant to listen to business advice from the government. That's fine, I was in your business once, and I know you're an independent lot. But, you don't have to listen to the government, just listen to your industry.
I'm sure you're aware that Air Conditioning Contractors of America (ACCA) is leading an industry wake up call on quality contractors and quality installations. These specifications have been industry-developed and publicly vetted, and now are under review for ANSI approval. This will serve as the new "raised bar" of quality installations, and if I were still a contractor, I'd want my company to be on the high side of these standards, well distanced from the "Bubbas."
Differentiate Yourself with Home Performance
If you want complete differentiation from "Bubba," and even some quality HVAC contractors, you will need to move toward home performance contracting. It really is the next big area for service delivery, and HVAC contractors are best positioned to take on this challenge — you're in the comfort business, right? But why stop at the HVAC equipment when there's money on the table for a host of efficiency, comfort, and indoor air quality improvements that need to be addressed?
You've done a Manual J, right? You've seen all the attic bypasses, poor ductwork, inadequate insulation, bathroom fan exhausts that dump into attics, leaky can lights, wet crawl spaces, moldlike substances, and old windows. You've heard the homeowner's complaints that the upstairs is always hot in the summer, how high utility bills are, and how the kids have bad allergies. Or, are you only just swapping boxes and maybe adding an ultra-violet light?
It's time to take the bull by the horns and sell a total home performance packaged solution — one that makes money and truly delivers whole house comfort to your customer.
Just Getting Started
Home performance contracting is really just getting started in this country. But the timing to get involved couldn't be better. There's a perfect storm developing that home performance contractors will be in the best position to capitalize on:
- homeowners are feeling greater pain with the increased utility rates
- indoor air quality issues are big business
- interest in all things "green and clean" is no longer just boutique
- the public is seeing first hand the effects of global climate change
- the inventory of homes that "don't work" is huge, and educated homeowners will pay for whole house solutions.
HVAC is clearly the most technical and intensive of all the home performance endeavors. It's much easier for an HVAC company to move toward home performance (air sealing, duct repair, adding insulation, etc.) for an insulation company to deliver HVAC. On top of that, only the HVAC industry maintains a relationship with customers. When was the last time you heard from the guy that sold you windows?
Home performance contracting is off to the races, most noticeably in New York, Wisconsin, California, and Texas. Within these states, and a dozen more, there are program sponsors running home performance with Energy Star programs. These sponsors partner with Energy Star to oversee a network of quality contractors, provide a quality assurance program for those contractors, and ensure the proper use of the Energy Star logo and report activity.
Over a short period of time, more than 20,000 homes have been served the "whole house way." Indeed, there are HVAC contractors providing home performance contracting outside of these Energy Star programs — without any support or incentives — and they believe that it's clearly the way to do business.
Today, there are knowledgeable contractors who can properly diagnose a sick house, then deliver comprehensive solutions that will make the house comfortable, safe, durable, and efficient. And, yes, homeowners are willing to pay for this service that ensures better indoor air and the piece of mind of reduced utility consumption of electricity, oil, propane, and water.
Home performance contractors are meeting comfort needs by using building science to provide solutions that are too often glossed over or not understood. Take your HVAC business to new heights and rise above the "Bubbas."
Now, how close are you to the tipping point?
This article is based on the presentation, Get Green with Residential LEED and Energy Star, which Chandler vonSchrader gave at HVAC Comfortech 2005, held in Nashville, TN, Sept. 14-17, 2005. For more information about HVAC Comfortech 2006, which will be held September 13-16 in Baltimore, MD, call 216/931-9550. Learn from the leaders: In 2005, HVAC Comfortech presented more than 30 speakers providing educational seminars. All the sessions were recorded, and are available for purchase. For pricing and ordering information, visit the show website: www.hvaccomfortech.com |


text:
Lilies are one of those plants that offer a big return on your investment. Just a little effort in planting the bulbs will reap years of fragrant, colorful blooms. Lilium is a large family of plants and some are easier to grow than others. Three common types are Asiatic, Oriental and Trumpet.
Asiatic Hybrids — One of the most carefree summer bulbs that I grow in my garden are Asiatic lilies. They are perfect for cutting gardens and containers. I like to add five to 10 bulbs to my raised vegetable garden so I will have plenty on hand to use as cut flowers later in the summer. Asiatics are early to bloom and easy to grow. They don't have much fragrance but they make up for it in color.
Oriental Hybrids — Like a Southern grand dame dressed in her Sunday best, Oriental lilies are bright, flamboyant and heavily perfumed! I can't imagine my garden without these royal beauties. They will perform well in partial shade.
Trumpet and Aurelian Hybrids — The lilies in this group tend to bear striking trumpet-shaped blooms on tall stalks. Many are quite fragrant too. The flowers are so large the plant may require staking.
Planting Lily Bulbs
Lilies are planted as bulbs in fall or early spring. If you plant in fall be sure to mark the area so you'll know to look out for emerging growth. I've unknowingly stepped on the tender shoots more than once and it's completely devastating.
When you pick out bulbs at the garden center look for ones that are fresh and firm with plenty of white roots. Lily bulbs never go completely dormant like daffodil and tulip bulbs so you should handle them with more care.
Select a spot that receives the right amount of sunlight for the type of lily you are planting. For instance, an Asiatic lily appreciates full sun while an Oriental lily can take partial shade.
All lilies need good drainage. Wet, soggy soils are the kiss of death. To ensure good drainage I pour a little sand in the bottom of the planting hole. You can also get around heavy soil by planting lilies in containers or raised beds.
Dig a hole big enough to accommodate the bulb and roots. Plant small bulbs 3 to 4 inches deep, and larger bulbs 4 to 6 inches deep. Gently place the bulb in the hole, cover with soil and water in. That's it!
After your lilies bloom, just cut off the top of the stalk. Also when you cut blooms for using in arrangements, take no more than one third of the stem. The idea is to leave enough foliage so the plant can build up energy in the bulb for next year's blooms.
For more information on growing lilies, check out the video below!


text:
The Poles of Io
Io is a large moon of Jupiter. Jupiter has four large moons. Io is the closest of the four to Jupiter. Io has hundreds of volcanoes. It has more active volcanoes than any place else in our Solar System. Some of those volcanoes are near Io's poles.
A volcano named Tvashtar is near Io's North Pole. Two different spacecraft have "seen" Tvashtar erupting. The Galileo spacecraft spotted a huge lava lake in the volcano's crater. It also took pictures of an eruption of a huge lava "curtain" that was 25 km (16 miles) long and at least a kilometer (three thousand feet) high! The New Horizons spacecraft took pictures of an eruption from Tvashtar in 2007.
Another volcano, named Dazhbog, is also fairly close to Io's North Pole. The Voyager spacecraft and the Hubble Space Telescope have taken pictures of Dazhbog. Dazhbog is named after a god from Slavic mythology. Tvashtar is named after the Hindu god of blacksmiths.
Io has a very thin atmosphere. It is mostly sulfur dioxide gas from the volcanoes. Jupiter has a huge magnetic field with lots of radiation trapped in it. Some of that radiation hits Io's atmosphere. It makes gases in the atmosphere glow. That glow is called the aurora, like our Northern Lights or Southern Lights on Earth. The aurora on Io is strange. It is at Io's equator, NOT at its poles!