On May 16, 2018 8:24:52 PM EDT, Howard Gibson <hgibson@eol.ca> wrote:

On Wed, 16 May 2018 19:48:31 -0400 Russell via talk <talk@gtalug.org> wrote:

...

After installing some recent F27 updates using the gnome software centre, the package kit watchdog has stopped exiting gracefully on an install routine. This happened after I chose to enable the recommended updates.

...

Russel,

I am having problems with dnf too. I have upgraded my two primary computers to Fedora_27. Overall, I am happy with it, but I find that install orders to dnf fail a lot. Usually, they work when I run them again. This is not much help when my cron job tries to do an update.

I don't generally do updates except for those security issues which I find out about, either from this list or other feeds. Once I have something that I do rely on daily for workflow, I try not to upset the applecart. This year is a bit of an exception, I do all recommended updates, as so many core utilities are affected by all the recent cache mitigations. In addition Fedora 28, has aligned itself more completely with the principles of the company's more robustly secured enterprise solutions. Now libnsl is prised out of glibc and stands on its own as libnsl2. Ostensibly this provides enhanced support for Transport Independant RPC on IPv6 networks. However my first attempt to revert back to libnsl for portmapping, as others using sane backends on Fedora have recommended trying, borked the socket completely. Clearly I missed something, which thusfar appears to be above my pay grade. Currently my reading suggests I should be looking to how memory allocation is being managed in F28 to provide for better dynamic linking. I remember a Tlug presentation from quite a number of years ago titled, "Better Living Through Dynamic Linking." Now I wish I'd kept better notes, you never know when this sort of esoteric stuff will come in handy.

-- Howard Gibson hgibson@eol.ca jhowardgibson@gmail.com http://home.eol.ca/~hgibson

-- Russell

On May 17, 2018 8:46:25 AM EDT, "D. Hugh Redelmeier via talk" <talk@gtalug.org> wrote:

I'm on Fedora 28. I'm replying somewhat carelessly: I'm not checking things.

| From: Russell via talk <talk@gtalug.org>

| On May 16, 2018 8:24:52 PM EDT, Howard Gibson <hgibson@eol.ca> wrote: | >On Wed, 16 May 2018 19:48:31 -0400 | >Russell via talk <talk@gtalug.org> wrote: | > | >> After installing some recent F27 updates using the gnome software | >centre, the package kit watchdog has stopped exiting gracefully on an | >install routine. This happened after I chose to enable the recommended | >updates.

[quoting (by Howard) got somewhat mucked up (by Russell's MUA) due to long lines. At least I think that that is what happened.]

I don't know whats happening there. It seems to be intermittent and not just with this list but personal traffic as well.

I don't knowingly use packagekit. But of course it runs on my systems. I use dnf.

I wish I'd removed packagekit a while back because a (now fixed) bug caused a lot of space to be wasted on my machines. Perhaps even double-downloading of packages (I don't know). <https://bugzilla.redhat.com/show_bug.cgi?id=1306992>

I built my own work-around: a script to prune the cache. I no longer need it.

Maybe you can remove packagekit. Or just disable it.

| >I am having problems with dnf too. I have upgraded my two primary | >computers to Fedora_27. Overall, I am happy with it, but I find that | >install orders to dnf fail a lot. Usually, they work when I run them | >again. This is not much help when my cron job tries to do an update.

I don't have unexpected dnf failures. I do get expected ones:

- (not recently) if packagekit is refreshing its cache, dnf gets delayed or even locked out.

- the filesystem with /var/cache fills up and dnf balks

Why or how does dnf fail for you?

| I don't generally do updates except for those security issues which I

| find out about, either from this list or other feeds. Once I have | something that I do rely on daily for workflow, I try not to upset the | applecart.

In this day and age, I do updates fairly regularly. And with Fedora, it is kind of like a Niagara. I guess it's a little slower when one is one version back.

I don't find applecarts are upset, but it is a worry.

With your philosophy, you should consider CentOS. Its main fault is that the packages are so far behind the times.

CentOS is on the bucket list to check out. However I do have all new midrange equipment to play around with so I'm tinkering a lot closer to the edge than my usual comfort zone in this case. I was running Debian from about 2001 onward. A few years ago I was helping a friend, he tried out Fedora, I did the grunt work on updates and comming to grips with SElinux. I got to like it, so I'm using it on my new build, at least while I'm transitioning to systemd.

Ubuntu LTS seems to be somewhere in the middle. But I don't have much experience with it. Debian gives you choices too but I don't have any first-hand experience (something I regret).

| This year is a bit of an exception, I do all recommended updates, as so | many core utilities are affected by all the recent cache mitigations.

Do you know about the dnf flag --security? I've never tried it, but it seems to be what you want. There is also --sec-severity. They look like great shortcuts for your policy.

Thanks, I have muted packagekit and dnf dragora is running. At this point I am doing complete updates as they roll in but I will definately look at those flags for stability in the future.

| In | addition Fedora 28, has aligned itself more completely with the | principles of the company's more robustly secured enterprise solutions.

I don't understand. Fedora is kind of a pathfinder for RHEL. Some initiatives are deemed failures but most others get into the next version of RHEL (up to five years later!).

RHEL is more secure partly because it is more conservative about adopting upstream updates. This takes a lot of work and backporting -- there are a lot of Red Hat employees doing this. They also do a lot of testing, including formal testing such as FIPS auditing.

| Now libnsl is prised out of glibc and stands on its own as libnsl2. | | Ostensibly this provides enhanced support for Transport Independant RPC | on IPv6 networks. However my first attempt to revert back to libnsl for | portmapping, as others using sane backends on Fedora have recommended

| trying, borked the socket completely. Clearly I missed something, which | thusfar appears to be above my pay grade.

I've not had any problems and have been blissfully ignorant of this issue. I do use SANE.

Currently on F28 my Brother multifunction scanner printer only prints, no scanner. This seems to be an issue with brscan software. Everything works on F27, however that version is using init to do the port mapping, not systemd.

I feel (but don't know for sure) that glibc is way too big and should be modularized. Changing this kind of thing is hard because it ripples down to the many many clients of glibc.

Another of my bucket list items to study are Fedora Flatpacks. This seems to be a next wave for connecting developers to the end users and vice versa. In essence I see this emerging tech as one of dynamic modularity vs static monolithity.

| Currently my reading suggests I should be looking to how memory | allocation is being managed in F28 to provide for better dynamic | linking.

Why? Is this connected to problems that you are experiencing?

My F28 systemd targets aren't working for brscan.

| I remember a Tlug presentation from quite a number of years ago | titled, "Better Living Through Dynamic Linking." | | Now I wish I'd kept better notes, you never know when this sort of | esoteric stuff will come in handy.

David Collier-Brown's talk was interesting. But the mechanism is very powerful and easy to get wrong. What problem do you have that it might solve?

Systemd contiguation of memory allocation units under IPv6 addressing. Systemd is kind of like omnibus legislation, you really have to read and get all the fine print or something you like, need or want gets steamrollered. I remember from the Dynamic Linking talk that some wags would say, all high sierra like; "your talking about dlls, thats M$ cruft. This is Linux, we don't need no stinkin dlls." It looks like I do need them, in spades now that I have adopted systemd instruction sets.

--- Talk Mailing List talk@gtalug.org https://gtalug.org/mailman/listinfo/talk

-- Russell

On 18/05/18 11:32 PM, D. Hugh Redelmeier via talk wrote:

| From: Russell via talk <talk@gtalug.org>

| On May 17, 2018 8:46:25 AM EDT, "D. Hugh Redelmeier via talk" <talk@gtalug.org> wrote:

| I remember from the Dynamic Linking talk that some wags would say, all | high sierra like; "your talking about dlls, thats M$ cruft. This is | Linux, we don't need no stinkin dlls."

UNIX has had them since before Windows. Just look at all the .so files.

What UNIX does differently is the idea of major and minor versions: $MAJOR.$MINOR. A program specifies the Major version it requires and the system provides the highest minor version available for that major version. Interfaces can change only when major versions are changed.

The Windows implementation did not have any such provision so substitutions often went wrong. Various creative failure modes ensued, but I won't bore you with the details. It's notable that Linux numbers the interface, not the library. This came from Multics, and was heavily used by Solaris and the glibc developers to avoid an NP_complete problem of "how do I have two versions of something at the same time?"  More details that you ever wanted in https://leaflessca.wordpress.com/2017/02/12/dll-hell-and-avoiding-an-np-comp...

--dave -- David Collier-Brown, | Always do right. This will gratify System Programmer and Author | some people and astonish the rest davecb@spamcop.net | -- Mark Twain

On 19/05/18 01:17 PM, D. Hugh Redelmeier via talk wrote:

| From: David Collier-Brown via talk <talk@gtalug.org>

| It's notable that Linux numbers the interface, not the library. This came from | Multics, and was heavily used by Solaris and the glibc developers to avoid an | NP_complete problem of "how do I have two versions of something at the same | time?"  More details that you ever wanted in | https://leaflessca.wordpress.com/2017/02/12/dll-hell-and-avoiding-an-np-comp...

Interesting. I haven't (yet) read references from the blog posting.

The example of memcpy with overlapped arguments is interesting.

Primarily, it's a trivial example that everyone will understand. It is also an example of a bug and people trying to code /in terms of the bug/.  Arguably not a good thing to do ...

If I remember correctly, overlapping arguments was banned in about 1980. So the chances of C code being older than that is rather low these days. Less so code that is unmaintained.

So using overapping is a bug. Do we really want to keep old libraries to support buggy code?

Some people don't have the source to their programs, so they can get stuck using an old interface, and be unable to recompile if the library changed.  We had that with linker records at Honeywell: we could add new ones, and even require people to set a particular flag to force them to be still honored, but we didn't succeed in taking the one I was involved in out.  Others removals went fine, so no-one seemed to have been wedged by them. I used the example in part to illustrate that there are tradeoffs, and also "religious" debates over whether something is a bug or a feature. There's one religious debate going on right now about closures in Go. Everyone who has been caught by the bug splits into one of two camps. One group says "fix it, it doesn't break any programs that have coded around the bug". The other group says "It's a feature. I had code around it, and everyone else should have to, too" That one's an example that argues for not supporting old interfaces, while the lost-code example argues for retaining them even when it's to enable deliberately doing a wrong thing.

I think code improves when it tracks the things it depends on. Look at C and its compilers: it has gotten much better at letting the programmer express intentions and detecting inconsistencies. Code that doesn't use those features is likely less reliable. Yes. For a language to advance, it has to be able to stop supporting old interfaces. Thus my snarky comment about coding in terms of a bug (;-))

Doing so may take a deep text-to-text transformer like "go fix", and it may take a sliding window of how old an interface can be, with occasional special case like the Honeywell GCOS linker's -allow-old-call-frames option.

I find it disgraceful that the transition from Python 2 to Python 3 is still a thing 10 years on. IMHO, they need a "python fix" program that transforms at the parse tree level, not just textually like 2to3 and 3to2 do.

--dave [There's a ton of interesting stuff in the David J Brown paper] -- David Collier-Brown, | Always do right. This will gratify System Programmer and Author | some people and astonish the rest davecb@spamcop.net | -- Mark Twain