Date: Sun, 12 Feb 2017 08:51:39 -0500 From: <scratch65535@att.net> To: freebsd-ports <ports@freebsd.org> Cc: Kurt Jaeger <lists@opsec.eu> Subject: Re: Install of pkg fuse-ntfs fails because of undefined symbol in pkg!?! Message-ID: <uve0ac5jh5grqmeklr5dglfrg3pkph6skv@4ax.com> In-Reply-To: <20170211141106.GS13006@home.opsec.eu> References: <1c6cccac-b151-d13c-c763-b336c4680118@freebsd.org> <ndjm9cl4samqgioi25ro8p2q6liimvr1h4@4ax.com> <35a953e3-918b-fc32-d990-51f7da16c884@FreeBSD.org> <AE0D514C-D235-462D-B31D-66FC619D9F4D@lastsummer.de> <20170209161249.GL2092@kib.kiev.ua> <20170209162600.GP13006@home.opsec.eu> <lnbr9cdn91jr8vtkecdv6enkafanjh8adg@4ax.com> <20170210164615.GQ13006@home.opsec.eu> <gs0u9c9j989cog6v112klk2tppplqj9pku@4ax.com> <20170211141106.GS13006@home.opsec.eu>
next in thread | previous in thread | raw e-mail | index | archive | help
[Default] On Sat, 11 Feb 2017 15:11:06 +0100, Kurt Jaeger <lists@opsec.eu> wrote: >Hi! Moin! > >> >> 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 different analysis. 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 >changes. 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 >stability) ? 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 hardware. 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 shipping. 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 top-notch engineering. 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 Visicalc. > >> 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 >ports tree. 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 standards. 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?uve0ac5jh5grqmeklr5dglfrg3pkph6skv>