Install of pkg fuse-ntfs fails because of undefined symbol in pkg!?!
scratch65535 at att.net
scratch65535 at att.net
Sun Feb 12 13:55:02 UTC 2017
[Default] On Sat, 11 Feb 2017 15:11:06 +0100, Kurt Jaeger
<lists at opsec.eu> wrote:
>> >> But it's the velocity that's the problem, Kurt.
>> >While I very much sympathize with "The world rotates too fast,
>> >I want to get off", for me it looks like as a project we do
>> >not have alternatives.
>> Why not? What would happen to fBSD that's not already happening?
>Maybe if other folks do not share your analysis that the fbsd world
>is loosing market/mindshare etc, they come to different conclusions
>on what they want from the system.
I'm sure you're right. But I'd like to see the basis for their
As I said in response to your other post, I look at most of the
same things I looked at back in the day: market penetration,
applications, favorable press. The one thing I don't look at now
are the professional analyses for which companies must splash out
hundreds or thousands of dollars.
So I wonder what they're looking at that would lead them to such
a different conclusion.
>> Why aren't people asking what's going on and how to turn it
>> around? Could it be because they're too busy being busy?
>My impression is they are busy innovating, and that is good
>and I thank them for it
But by all the usual metrics (penetration, apps, press) it's not
working. If we're doing the wrong thing, even doing it Really
Well won't save us.
>> >Is it defense, if we see many projects (open source etc)
>> >shorten their cycle time (e.g. php7), because they see the need to
>> >add features or patch security issues (and breaks APIs/ABIs doing either) ?
>> It seems more like an excuse than a defence, to me. Is it
>> pushing Linux back? If not, what *would* push Linux back?
>As I asked on the other mail: How do you measure this ?
Penetration, applications, press. The links that Grzegorz posted
are extremely on-point. We are in trouble!
>[Pathologising others] is not very friendly.
I'm not pathologising anyone. Fear of change is an ordinary
human response --it's mentioned in scripture, in Shakespeare, and
even in the US Declaration of Independence! "[A]ll experience
hath shewn, that mankind are more disposed to suffer, while evils
are sufferable, than to right themselves by abolishing the forms
to which they are accustomed". Shakespeare: "[D]read ...
puzzles the will / And makes us rather bear those ills we have /
Than fly to others that we know not of."
But that it's ordinary doesn't mean it's adaptive!
>> But change is possible, even for adults.
>So, we're changing a lot and now we hear you complain about those
For some reason, I'm not seeing the "changing a lot". To me it
looks like the same old Same Old, just madly faster.
>Can you try to describe some changes that would help
>both groups (those that need innovation and those that need
If I were playing program manager, I'd first map releases to
hardware lifespan: a major release every five years, and patches
for class A and B bugs or sudden new hardware or package
components (e.g. php 7, mariadb 10) issued ab-necessario. As
Michelle notes, server hardware can be presumed to be exhausted
after 5 years, so if you've to bring up new boxes anyway, you
might as well upgrade to new bits, too. But you should not have
to replace your software more often than you replace your
If there were enough resources, do a minor release every year.
My second emphasis would be on *predictable* quality, to lure
back businesses (they provided most of our funding and support
back in the day as you know).
Public deliverables would be 3 fully-packaged and
switch-configurable products, 2 of them plug-and-play for people
who just want a reliable tool to use for doing other work, and
the third a high-class kit for people who *don't* just want a
tool to use.
The tools would be
- a desktop (as Grzegorz points out, people go with what they
know, and what they know is their desktop. And right now that
desktop runs Linux), and
- a server.
If we couldn't at first manage to package all three, then
priority should be desktop and server before kit.
Cutting back the release frequency and focusing on 3 high-quality
turnkey products should take at least some of the load off the
developers, allowing them to avoid firefighting mode and increase
their free-brain time.
To support quality, I'd mandate, if I were program manager, that
the bits be pulled from their far-flung sources once per cycle
and stored centrally, such that version skew, fnf, and other
errors would be automatically avoided.
I'd also mandate that ports be divided into production-quality
bits for the server and desktop packages, and hobby-quality bits.
Between fetching and storing the bits for the build, and focusing
on making sure the bits are indeed production quality for the
packages, there should be many fewer cases of complaints from or
about the software.
(My install of X complains constantly, even though it appears to
work well enough. But the complaints are slightly worrying
anyway, and I have to hope that they're not breaking anything
such as my install of MariaDB 10, which stopped working after I
merely moved the discs and motherboard to a new physical box, and
added an LSI 9211. Not the level of quality we should be
I would download and install another MariaDB package on the
presumption that if it quit working because it dislikes the 9211
a fresh install will make them friends again, but, oops, I can't
do that because the pkgs were purged. So I have to decide
whether to try building the port, which often doesn't work
because of having to fetch bits that may have been changed, lost,
or moved meanwhile, or just mutter t'hellwithit and upgrade to
10.3 which in the past has meant scraping everything down to the
metal and reinstalling from scratch.
And I'd mandate that, at a minimum, all package bits be kept
available for the life of the major release.
Just like commercial software --- if you buy a copy of v2.0, you
have a copy of v2.0 and it never changes out from under you. If
the vendor has a good media-replacement policy you can download
another copy of v2.0 and it will be identical to the first copy.
No ad-hoc changes, just stable predictability.
Of course, it would be nice if we had the resources to actually
fix major bugs in older minor releases, but until we get
competitive with Linux again, I wouldn't be worried about that:
if the bits were good enough to ship, they're at least arguably
good enough still even if bugs later revealed themselves.
Developing the original packaging scheme would take some
I'd want to put people on it who not only have that level of
skill, but who *also* can put themselves in the place of those
who will use the products. Not every engineer can do that, which
is why Bricklin and Frankston lost ownership of the spreadsheet
space to Kapor. Kapor could do it, but B&F couldn't even see
the difference between what they were doing and what Kapor did.
But their customer base could see the difference! Sic transit
>> But that doesn't mean we're currently doing the right things to
>> regain share from Linux and save FreeBSD.
>Is this really a us-vrs-them thing ? I don't see it that way.
Okay. But it really is that way, unless it's okay for linux to
survive while fbsd goes under, which is what's happening right
now. If you don't believe me, check the links Grzegorz provided.
>There is innovation all across the board and to be able to co-innovation,
>certain things need to be done. In the base system and in the
But what's being done is not noticeably helping.
I worked for a major computer hardware company that innovated
constantly. Multi-million-dollar annual R&D budget. There were
many groups of engineers doing excellent, cutting-edge work, but
it was the wrong work because it had no connection to human needs
or what was going on elsewhere. That company had reigned supreme
in their space for so many years that corporate management
thought they could still enforce brand loyalty and set world
So they went under because corporate management were wrong. But
nobody could convince them of that because they had big offices
and were paid lots of money to run whole divisions with thousands
of people and multi-million-dollar budgets, which obviously made
them smarter than those of us who had small offices and ran
little departments with a few dozen people and small budgets. But
they weren't smarter, they were deluded. And it cost everyone
dearly. Except them, because they had golden parachutes.
More information about the freebsd-ports