Re: [DNG] Drive-by critique
Quoting Adam Borowski (kilob...@angband.pl): > Well, about that... Not so long ago I helped a relative by installing > Redmontware. It was a long, arduous process, during which I had to fetch > and copy in drivers for six pieces of hardware. Most of those couldn't be > even found on their manufacturer's website -- I had to scour some random > seedy webpages. Some of the drivers, even those shipped _with_ Redmondware, were notoriously so buggy that you could seldom make them function at all. I believe it was 1998 that I spent a week at a client site in Portland, Oregon, and among other things was putting 3Com 3C905TX PCI NICs into workstations running MS-Windows 98. ISTR that I had access to the NDIS driver both from the OS and directly from 3Com -- and the problem was that, about 19 times out of 20, Device Manager showed the driver to be non-functional after you assembled the network stack. So, you deleted the entire network stack, maybe waved a dead chicken or two, reinstalled the NIC driver and network stack again, and re-tested. Repeat until it suddenly works. Nobody knew of a better workaround, and impliedly OEMs who shipped a working configuration with 3C905TX NICs had gone through the same madness until a test box worked, and then disk-imaged that fluke success for mass replication. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Drive-by critique
On Fri, Dec 21, 2018 at 04:33:32AM +0100, Adam Borowski wrote: > > I forgot the details why, but during the process I resorted to a small > Debian partition. Every piece of hardware was supported perfectly, > including even that machine's USB wifi card. I've found a Linux partition is essential for installing WIndows. Every time Windows requests a reboot, I suborn it ny rebooting to Linux, doing a complete nackup of the Windows system, and then rebooting to resume the installation. When the installer crashes, I restore the lastest partly installed Windows from backup and resume. Worked like a charm. Of course, that was years and years ago. I don't have any idea what installing WIndows is like now. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Drive-by critique
Quoting Clarke Sideroad via Dng (dng@lists.dyne.org): > I think the purpose was to avoid tainting the initial installation > with proprietary firmware, but not have the lack of it it ruin the > party. Proprietary firmware files divide broadly into two categories: 1. Copyright owner granted sufficient permission for distros to redistribute them. 2. Copyright owner didn't. You might think it would be really incredibly stupid for say, chip manufacturer Broadcom, Inc. to just totally forget to write down 'Oh, by the way, anyone may freely redistribute this firmware file without modification provided that no right to reverse-engineer it is granted and no warranty of any kind' -- and you would be correct. Yet, that is exactly the mistake Broadcom and a number of other such manufacturers repeatedly make. I've been known to mock Broadcom, Inc. on this matter, observing that they were too busy putting profits up their nose to find first-class postage. (Web-search 'broadcom cocaine' for details.) This is why quite a number of firmware files simply cannot (lawfully) be included in Linux distributions, for lack of someone lavishing the cost of a first-class postcard on the matter. Typically, instead, someone crafts an open-source 'cutter' utility for *ix that, if installed and run, downloads the MS-Windows driver .exe or .cab files from the hardware manufacturer's Web site, extracts the firmware BLOB image, parks that with the desired filename under /lib/firmware, and discards the rest. See, for example, https://packages.debian.org/stretch/b43-fwcutter (speaking of Broadcom). Anyway, don't assume that a distro's omission of desired firmware is necessarily on grounds of ideology. It might be because of nose-injuring incompetence from firms like Broadcom, Inc. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Drive-by critique
Quoting Steve Litt (sl...@troubleshooters.com):
> Ubuntu installs as easily as Windows' first boot nonsense. Devuan isn't
> far behind, on most hardware.
Interesting point about that, which I'll get to, near the end.
> What Eric objected to, and I agreed, was lack of proper handling of
> proprietary blobs, firmware and drivers, when absolutely necessary,
> makes Devuan installation as hard or harder than Arch, Gentoo or Funtoo.
The best of my understanding is that Devuan Project has _no _policy
forbidding inclusion of proprietary firmware BLOBs (Binary Large
OBjects) with installers -- and that the desktop-live image _includes_
them (as does the minimal-live image). After bootup, at the user's
option it runs refractainstaller-gui to bulk-install Devuan w/BLOBs to a
target drive for installed use.
Eric didn't state in his rant (perhaps he did on IRC, but I've discarded
my channel log) _which_ installer he used. I suspect it was the
'installer-iso' CD or DVD images, which use the d-i installer. (I note
in passing that desktop-live has long been 'the recommended choice for
desktop users wanting to try Devuan out', to quote the ascii release
notes.)
(You distinguish 'proprietary blobs' from 'firmware', but those are
actually a single thing.)
Eric's primary beef about 'drivers' related to his wife Cathy's Intel NUC with
an unstated but apparently spanking-new Intel e1000 NIC variant unknown
to whatever-installer-he-used's kernel's PCI IDs table. Like Devuan's
sister distribution Debian, Devuan for _excellent_ reasons (stability,
lack of inclination to corrupt data) uses chosen stable-release codes
for many packages with backported fixes. My understanding is that the
Linux kernel in devuan-ascii's installer-iso images is Linux 4.9.82.
That's really pretty recent, IMO. Upstream (kernel.org) there are
currently three 'longterm' kernel codebases: 4.14.89, 4.9.146, and
4.4.168. So, by that measure, 4.9.82 is relatively unexceptional at the
end of 2018 as a long-term-supported distro kernel.
Checking the current stable releases of some of my favourite desktop
distros:
Siduction: 4.16.8 (but being stabilised Debian-Sid, is cutting-edge)
Bodhi Linux: 4.15
Artix Linux: 4.18.10 (but again a cutting-edge rolling distro)
antiX: 4.9.126
Holding my nose and checking the big names:
CentOS: 3.10 (yes, really!)
openSUSE: 4.12.14
Ubuntu: 4.18
Linux Mint: 4.15
Mageia: 4.19.6
As you'll see, 4.9.82 (even with backported fixes) is a bit more
derrière than avant garde, but not badly so.
Not coincidentally, the latest refresh of Debian-stretch (latest
Debian-stable) installs with 4.9.30, so I suspect Devuan-ascii ended up
with a 4.9.82 because of the two release's related origin.
For completeness, Eric had a minor beef about one of his Jetway hosts
('grue') requiring what he caled 'the Radeon blob' (in the paragraph you
allude to, by your reference to 'leaving his video cards with
non-proprietary software that doesn't handle resolution as well'). I'm
guessing this is a slight error on his part, that for his desired high
resolutions grue requires proprietary AMD Redeon _driver_ (currently a
driver series named 'amdgpu-pro', replacing driver series 'fglrx'),
which of course include firmware BLOBs but rather a lot more than that.
And, last I heard, AMD doesn't permit anyone but itself to distribute
that software, so _no_ Linux distro can lawfully include it.
Alternatively, it's possible Eric was talking about using the open
source AMDGPU drivers integral to X.org (xserver-xorg-video-amdgpu), but
he didn't have non-free omnibus metapackage firmware-linux (or specific
non-free package firmware-amd-graphics) available by default because he
started with an installer-iso ISO rather than a desktop-live one.
Which (then) was unfortunate, but radically overblown in his rant's retelling.
By the way, Golinux with help from one of the other regulars has a
revision to the main Devuan Web pages to very pithily guide newcomers to
sensible-for-them choice of installer. The improvement is in beta,
coming to the live site soon.
> By the way, I disagree with Eric about the degree of badness in leaving
> his video cards with non-proprietary software that doesn't handle
> resolution as well. Once you can boot your system and run it, the
> installer has done its job. If user friendliness is desired, a separate
> program can be used to select the right proprietary drivers, blobs and
> firmwares.
Yes, one might envision a Devuan wrapper package that grabs the latest
proprietary amdgpu-pro tarball off the ATI site and does a devuanised
installation. Of course, there are complications such as that the
firmware-amd-graphics package contents being _also_ present slows down
video performance greatly. Given the tendency of desktop users to just
throw everything possible at a problem and then vaguely complain that it
'didn't work', it would probably be wise for such a wrapper package to
check for that and other likely
Re: [DNG] Drive-by critique
On Thu, Dec 20, 2018 at 11:29:29AM +, Simon Hobson wrote: > In part, Linux adoption is held back by it's perceived difficulty - such > as having to go and find drivers for your hardware. Well, about that... Not so long ago I helped a relative by installing Redmontware. It was a long, arduous process, during which I had to fetch and copy in drivers for six pieces of hardware. Most of those couldn't be even found on their manufacturer's website -- I had to scour some random seedy webpages. Windows also doesn't provide any means to identify hardware (such as lsusb, lspci, etc). On Linux, even in the worst case of completely unknown hardware you are told at least hex USB ids. Especially glaring was having no means to copy files to Windows being installed. I forgot the details why, but during the process I resorted to a small Debian partition. Every piece of hardware was supported perfectly, including even that machine's USB wifi card. So that's it about the difficulty of installing and "having to go and find drivers for your hardware" between Linux vs Windows. One of these systems is egregiously behind -- and that's not us. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Ivan was a worldly man: born in St. Petersburg, raised in ⢿⡄⠘⠷⠚⠋⠀ Petrograd, lived most of his life in Leningrad, then returned ⠈⠳⣄ to the city of his birth to die. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Drive-by critique
On 2018-12-20 6:00 p.m., Steve Litt wrote: On Thu, 20 Dec 2018 14:07:11 -0800 Rick Moen wrote: Quoting Simon Hobson (li...@thehobsons.co.uk): In part, Linux adoption is held back by its perceived difficulty Just a brief comment about this in passing, as this is an antique debate point ages ago stomped into the ground on comp.os.*.advocacy and other places: An operating system one must install (not preloaded) will always be perceived as 'difficult' compared to one already furnished as a point'n'drool preload. Ubuntu installs as easily as Windows' first boot nonsense. Devuan isn't far behind, on most hardware. What Eric objected to, and I agreed, was lack of proper handling of proprietary blobs, firmware and drivers, when absolutely necessary, makes Devuan installation as hard or harder than Arch, Gentoo or Funtoo. By the way, I disagree with Eric about the degree of badness in leaving his video cards with non-proprietary software that doesn't handle resolution as well. Once you can boot your system and run it, the installer has done its job. If user friendliness is desired, a separate program can be used to select the right proprietary drivers, blobs and firmwares. The blobs can get you, but I cannot imagine the Devuan installation getting harder than Arch, Gentoo or Funtoo. With a couple of my systems I have to load proprietary firmware after the install, but it is no big deal. I can see if one was a "newbie" and ended up with no X it could be daunting. Perhaps your final paragraph may provide a key to an approach to use, in the form of text post-install/first run script that provides a list of potential firmware installs one might need and them provides a script driven install or at least instruction for the installation of the particular blob. This gets around I remember running into such a method a few times on otherwise relatively basic Linux distro installs. I think the purpose was to avoid tainting the initial installation with proprietary firmware, but not have the lack of it it ruin the party. Of course if you have to download network firmware to download network firmware you may have a problem. Clarke ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Drive-by critique
On Thu, 20 Dec 2018 14:07:11 -0800 Rick Moen wrote: > Quoting Simon Hobson (li...@thehobsons.co.uk): > > > In part, Linux adoption is held back by its perceived > > difficulty > > Just a brief comment about this in passing, as this is an antique > debate point ages ago stomped into the ground on comp.os.*.advocacy > and other places: An operating system one must install (not > preloaded) will always be perceived as 'difficult' compared to one > already furnished as a point'n'drool preload. Ubuntu installs as easily as Windows' first boot nonsense. Devuan isn't far behind, on most hardware. What Eric objected to, and I agreed, was lack of proper handling of proprietary blobs, firmware and drivers, when absolutely necessary, makes Devuan installation as hard or harder than Arch, Gentoo or Funtoo. By the way, I disagree with Eric about the degree of badness in leaving his video cards with non-proprietary software that doesn't handle resolution as well. Once you can boot your system and run it, the installer has done its job. If user friendliness is desired, a separate program can be used to select the right proprietary drivers, blobs and firmwares. SteveT Steve Litt December 2018 featured book: Rapid Learning for the 21st Century http://www.troubleshooters.com/rl21 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Drive-by critique
Rick Moen wrote: >> In part, Linux adoption is held back by its perceived difficulty > > Just a brief comment about this in passing, as this is an antique debate > point ages ago stomped into the ground on comp.os.*.advocacy and other > places: An operating system one must install (not preloaded) will always be > perceived as 'difficult' compared to one already furnished as a point'n'drool > preload. You know that, I know that, ... And for years I've been installing OSs of various types : Apple DOS, MS/PC Dos, Windows from when it wasn't much more than a few windows on top of DOS, Mac OS, Mac OS X, Xenix, OpenServer, OS/2, and various flavours of Linux. I've even done a bit of embedded system work - mine was the human inteface part, but I also worked on the disk controller module (including determining by experiments what interleave factor worked best on the floppies) and test modules (it was an automated cable testing setup). So yes, *I* know that Linux generally isn't any harder than others (drivers for OpenServer were a particular headache IIRC, not to mention RAID controllers for Windows) - but it still has this (invalid) perception based on reading about having to download drivers etc. I have to think hard for occasions when I've had to download drivers for Linux - the only ones I can think of were the closed ones for an nVidia card, and the binary firmware blobs for my TV tuner cards. The last installs I had to do were Windows 10 at work, and TBH they were much more of a PITA given how MS seem to have gone out of their way to make things difficult for someone who doesn't want to be borged by their attempt to mimic Google's and FaecesBook's ability to grab and monetise user information. I'd keep a special place in hell for the people responsible for that abomination. > ... just pointing out that the entire discussion is saturated with balderdash. Agreed. >> If there were lots more Linux users, and lots less Windows users, then >> that situation would change. > > My Kansas-born mother would have said, 'If the hoptoad had wings, it wouldn't > bump its bottom on the prairie.' I know a few more sayings along those lines - some of them not suitable for polite conversation ;-) > In other words, if you start with an implausible premise, you can reach just > about any conclusion you want. In this case, the credibility challeged > premise is 'lots less Windows users', as that is obviously not likely for the > foreseeable future. The PeeCee OEM preload monopoly is a thing, and even the > rise of smartphones and tablets hasn't made a dent in it. The point being made is WHY things are as they are - which is that there's no business driver for hardware manufacturers to support Linux. I agree that we are where we are and that's not going to change quickly - if it did then that part of the catch-22 situation would be broken, but I won't be holding my breath for it ! But as you point out, any analysis of why doesn't really alter the fact that for most people computing == Windows (or for some, Mac OS X which is IMO less bad) and internet == Google + FaecesBook. Anything else is strange, different, and therefore "difficult". That's going to take some changing. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Drive-by critique
Quoting Simon Hobson (li...@thehobsons.co.uk): > In part, Linux adoption is held back by its perceived difficulty Just a brief comment about this in passing, as this is an antique debate point ages ago stomped into the ground on comp.os.*.advocacy and other places: An operating system one must install (not preloaded) will always be perceived as 'difficult' compared to one already furnished as a point'n'drool preload. For decades, I've seen Linux spokesmen get suckered by critics (but I don't mean you, just to be clear) claiming adoption was waiting for Linux to become as simple to install as the critic's MS-Windows or MacOS host. Upon examination, it turns out that said critic did not install the proprietary OS and would probably have been stunned by the (perceived) lack of a 'simple' nature to that process. So, the goalposts were set as making installation at least as simple as no installation, i.e., simpler than doing nothing (not a discussion but rather an inane card trick, but that's comp.os.*.advocacy for you). Said discussion often proceeds to setting of equally ridiculous but distinct goalpost: 'I'll be glad to use Linux on the desktop as soon as all applications are exactly like and 100% compatible with what I'm used to.' The critic might as well throw in a request for a pony -- and that critic typically makes no objection to occasional forced upgrades of proprietary code introducing gratuitous changes and incompatibilities. I'm not pointing that finger at you, Simon, but just pointing out that the entire discussion is saturated with balderdash. > If there were lots more Linux users, and lots less Windows users, then > that situation would change. My Kansas-born mother would have said, 'If the hoptoad had wings, it wouldn't bump its bottom on the prairie.' In other words, if you start with an implausible premise, you can reach just about any conclusion you want. In this case, the credibility-challeged premise is 'lots less Windows users', as that is obviously not likely for the foreseeable future. The PeeCee OEM preload monopoly is a thing, and even the rise of smartphones and tablets hasn't made a dent in it. So, talk to me _when_ (meaning _if_) there are lots fewer Windows users, and we'll see if the world now looks different. Anyway, you should free _your_ mind from proprietary-OS assumptions, too. ;-> ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Drive-by critique
Rick Moen wrote: >> I agree. The more GNU/Linux blows off prospective users by making them >> jump through hoops, the more Linux becomes a niche. The nichier Linux >> becomes, the more the hardware manufacturers ignore it. Let GNU/Linux >> get up to 25% on the desktop, and the manufacturers will provide good >> drivers for everything they make. > I can hazard a guess about why I keep hearing this 'desktop mindshare' > argument with no recognition of the vital differences that make it > pretty much inapplicable: It's a leftover, reflexive proprietary-OS way of > thinking (or, to be blunt, of not thinking). Free your mind, Steve. ;-> I think you are both right (in part) and both wrong (in part) ! Rick, you more or less support Steve's argument in your rebuttal. For Windows, device manufacturers provide the drivers because without that they don't get to play in the big pond - and without playing in the big pond, they have no business. Because Linux is a little pond (or even puddle, in their eyes), they don't have to care. So we have, to an extent, a chicken and egg situation. In part, Linux adoption is held back by it's perceived difficulty - such as having to go and find drivers for your hardware. In part, the reason for that is that device manufacturers don't provide drivers/support development of them. In part, the reason for not providing/supporting drivers is that they don't see/care about the "little pond" that is Linux users and so don't see a business driver to do it. If there were lots more Linux users, and lots less Windows users, then that situation would change. There'd be a louder voice for them to hear of "if you want us to buy your devices, you need to provide the drivers (or support their development)" - and so there'd be a business case for doing just that. There's a difference between the business case spending money to add (say) 5% to your potential market vs spending that money to add (say) 30% to the potential market. But even that is, in part, irrelevant. When you have things like a dominant player (Microsoft) actively forcing (video) device manufacturers to make their products more fragile and harder to reverse engineer. As I read the situation, if a video card manufacturer wants to play in the Microsoft world of "trusted video paths" then they have to build something that is fundamentally at odds with having good open source drivers available - they have to purposefully make things more fragile by detecting attempts to "look into" the internals and "breaking" if anything does something "not approved" such as trying different things to see what they do (as in part of reverse engineering a driver). ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Drive-by critique
Quoting Steve Litt (sl...@troubleshooters.com): > I agree. The more GNU/Linux blows off prospective users by making them > jump through hoops, the more Linux becomes a niche. The nichier Linux > becomes, the more the hardware manufacturers ignore it. Let GNU/Linux > get up to 25% on the desktop, and the manufacturers will provide good > drivers for everything they make. I hope you won't mind my differing strongly with the premise of this line of reasoning -- and also with its conclusion. First (as to the conclusion), empirically I find that Linux support for hardware is quite good, and on balance better than it was in olden days. But that's the lesser point I wanted to make: The larger is that you're ignoring a huge difference between proprietary and open-source operating systems, and also a unique advantage that Microsoft Corporation enjoys (control of the OEMs via coop marketing) for its OSes. Microsoft offers to hardware manufacturers (as does Apple and the other surviving proprietary Unix companies) the huge advantage of them furnishing (generally buggy, poorly documented, difficult or impossible to maintain) driver code with the source provided, if at all, under NDA. This is a motivator because hardware manufacturers tend to regard detailed information about their hardware, such as would be exposed by source-available drivers, as a closely held trade secret. (Moreover, it's known that some such manufacturers outsource driver authorship to other firms as one-off contract work, and end up lacking expertise -- and sometimes lacking source code.) Linux _could_ offer the same attraction -- through the tiny little ;-> change of abandoning open source. Absent that abandonment of our founding principles, a sizeable percentage of Linux hardware drivers get created using reverse-engineering with little or no manufacturer cooperation. The number of Linux desktop users has no effect on this dynamic. The unique advantage Microsoft has is its 'coop marketing' program: favoured OEMs' advertising costs are very heavily subsidised by Microsoft Corporation, forming a very significant percentage of revenues of goods sold. This perpetuate the preload monopoly, and ensures that hardware manufacturers are motivated to keep hurling driver code over the transom to stay in the game (even though the resulting code usually sucks) without Microsoft needing to do any work. And, again, desktop headcount has zero effect on this dynamic. I can hazard a guess about why I keep hearing this 'desktop mindshare' argument with no recognition of the vital differences that make it pretty much inapplicable: It's a leftover, reflexive proprietary-OS way of thinking (or, to be blunt, of not thinking). Free your mind, Steve. ;-> ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Drive-by critique
On Wed, 12 Dec 2018 14:43:38 -0800 Bruce Perens wrote: > Eric has never been the developer of a distribution, so there will be > things he doesn't understand. I am all for having as many users as > possible. I understand the problem of proprietary firmware and hope > that this is not a significant blocker for most people, especially > since most distribution installers do provide a way to download it > (and we should offer the choice even if we don't approve). This will > not help people with a network interface that requires proprietary > firmware to run. Put the proprietary blobs, drivers and firmware for common NICs on the install DVD image so this problem is usually overcome transparently (frictionlessly). If fails, mention special blob/firmware/driver image to download and burn, where to get it, and how to use it. And of course suggest using an alternate NIC (for instance, wired instead of wireless). > > But IMO the main problems with developing a large user community are > ease of use and impedance mismatch between the developers and users. > Many Debian developers would not have been the best people to > communicate with a naive user, and Devuan does further distill that > characteristic. IMO this is self-defeating for Free Software. I agree. The more GNU/Linux blows off prospective users by making them jump through hoops, the more Linux becomes a niche. The nichier Linux becomes, the more the hardware manufacturers ignore it. Let GNU/Linux get up to 25% on the desktop, and the manufacturers will provide good drivers for everything they make. SteveT Steve Litt December 2018 featured book: Rapid Learning for the 21st Century http://www.troubleshooters.com/rl21 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Drive-by critique
On Wed, 12 Dec 2018 16:22:59 +0100 KatolaZ wrote: > - netinst exist because it's the preferred way of installing minimal > systems and servers; And also because on tricky installations, life is easier if you can get the computer to boot a simple OS, and then build it up with various apt-get install commands and other tricks and troubleshooting. If running X on a computer is tricky, it's nice to have a correctly booting CLI OS and then install/config X, rather than trying to install X directly through the installer and either having to do trial and error installations or bust back in via chroot. I use network installs for that reason, and so I can a-la-carte pick what does and doesn't go on my computer. SteveT Steve Litt December 2018 featured book: Rapid Learning for the 21st Century http://www.troubleshooters.com/rl21 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Drive-by critique
On Wed, Dec 12, 2018 at 02:43:38PM -0800, Bruce Perens wrote: > Eric has never been the developer of a distribution, so there will be > things he doesn't understand. I am all for having as many users as > possible. I understand the problem of proprietary firmware and hope that > this is not a significant blocker for most people, especially since most > distribution installers do provide a way to download it (and we should > offer the choice even if we don't approve). This will not help people with > a network interface that requires proprietary firmware to run. o_O But...Devuan has actually always included (and will continue to ship) both free and non-free firmware in all the installation media, despite many Devuaners are against this choice > > But IMO the main problems with developing a large user community are ease > of use and impedance mismatch between the developers and users. Many Debian > developers would not have been the best people to communicate with a naive > user, and Devuan does further distill that characteristic. IMO this is > self-defeating for Free Software. > Devuan has never had a border between users and developers. We simply call ourselves "Devuaners", without distinction, because we all use Devuan and we are all contributing to make Devuan a better distro and a better community. If you come to the forum of a distro, yelling that the developers have not understood anything, and that they must implement as soon as possible this and that and whatnot otherwise you will leave to not be seen ever again, what do you think the most probable reaction will be? This is what esr has done, and IMHO this attitude does not help to lower any existing impedence mismatch, irrespective of your name being Eric, Bruce, Linus, Alan, Richard, Dennis, or Ken. Nevertheless, many Devuaners took the time and energy to understand his point. But what they got back was more yelling, and more "you must do this and that or I will leave". "Developers" should be more understanding, you rightfully say. But those who insist in defining themselves "users" have no right to threat as servants other fellow "users" or those they call "developers", in no circumstance, and for no reason at all. This is not the right spirit over here. There are hundreds of GNU/Linux distros around, and hundreds of development teams to yell at. HND KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Drive-by critique
Eric has never been the developer of a distribution, so there will be things he doesn't understand. I am all for having as many users as possible. I understand the problem of proprietary firmware and hope that this is not a significant blocker for most people, especially since most distribution installers do provide a way to download it (and we should offer the choice even if we don't approve). This will not help people with a network interface that requires proprietary firmware to run. But IMO the main problems with developing a large user community are ease of use and impedance mismatch between the developers and users. Many Debian developers would not have been the best people to communicate with a naive user, and Devuan does further distill that characteristic. IMO this is self-defeating for Free Software. Thanks Bruce ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Drive-by critique
On Wed, 12 Dec 2018 03:14:39 -0800 Rick Moen wrote: > If you want to have more devs, you need to attract a larger > userbase. > > I'm surprised to see Eric advance this non-sequitur. Open source > projects attract developers because their needs and objectives (or the > needs and objectives of their employers, which amounts to the same > thing) are met and served. Sure, some users will help in their own way, if only to encourage, but signal:noise increases. Hell, sometimes having more users will _drive away_ devs, because of real or perceived pressures. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Drive-by critique
On 2018-12-12 09:22, KatolaZ wrote: And please find below a more detailed explanation on the motivations behind each image: - netinst exist because it's the preferred way of installing minimal systems and servers; - the install DVD ISO exists because there are many users asking for a single medium that they can download once and install many times (e.g., due to bandwidth restrictions), and supports more than just XFCE; - the 3-cdrom set exists because we had many users asking for a smaller footprint (again, bandwidth is not cheap everywhere) set of images that they could use to install offline with a minimal XFCE desktop; - desktop-live exists because many people asked for a live Devuan version which could be easily tried and installed. This is also the preferred Devuan flavour used in reviews; - minimal-live was thought as a recovery tool and has a specific focus on accessibility (especially regarding visually-impaired and blind users), and provides a full-featured console-based setup; - so many embedded images exist because ARM vendors have not agreed on a common standard; - qcow, vagrant, and vcox images exist because many Devuan users like to have ready-to-use images for their VMs; - on top of those, there are also the usual mini.iso and netboot images, although not advertised on files.devuan.org. Quite likely, each single user would just prefer one of those images and ask themselves "oh why on Earth there are so many, indeed?". I actually use almost exclusively the mini.iso or the netboot images. The answer is that there is no single Devuan user, and no single Devuan use-case, as the statistics above confirm. What is perfect for somebody, is dumb or useless for somebody else, and vice-versa. The whole point is to make an effort to look at the bigger picture: Since Devuan is one of the few dpkg-based systemd-free distributions around, we have the *obligation* to cater for as many use cases as possible. HTH KatolaZ There is already a page on the website that covers much of this material: https://devuan.org/os/install It is already the very first link on the Download page in this section: Getting started Short install instructions for various platforms <<< Comprehensive upgrade and installation guides on dev1fanboy’s wiki Devuan ASCII release notes to help with the upgrade Perhaps a slight rewrite of that page and higher visibility - top of the page and big red letters - would suffice? golinux ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Drive-by critique
On 12/12/2018 15:22, KatolaZ wrote: [snip] > > Please find below the stats of the actual number of downloads of each > ASCII image according to https://files.devuan.org in the last 14 days > (without taking into account the other 24 ISO mirrors): > > - netinst: 149 > - DVD ISO: 135 > - CDROM ISO : 99 > - desktop live : 180 > - minimal-live : 77 > - embedded (ARM) : 283 Interesting > - virtual: 72 > -- > Total: 995 [snip] Could I have a breakdown by ARM platform please ? ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Drive-by critique
On Wed, Dec 12, 2018 at 02:40:11PM +, Roger Leigh wrote: [cut] > installation methods. Looking at > https://mirror.netzspielplatz.de/devuan/devuan_ascii_rc/installer-iso/ for > example. Do the separate CD and DVD images have much value given that they > only hold the tiniest fraction of the whole archive? Or is just one netinst > or dvd image sufficient for all needs (perhaps combined with a local mirror > or caching proxy server if you are doing multiple installations)? Could the > live images be further combined with the install images like Ubuntu does? If > you look at http://releases.ubuntu.com/18.04.1/ and > http://releases.ubuntu.com/18.04.1/ you can see that there's just one server > and desktop iso image per platform per release. It's pretty simple when > there's a single obvious choice to make, and they clearly thought how to > reduce the complexity as much as possible. (Note: none of this is a > criticism of the Devuan ascii images; the collection is quite impressive.) > Please find below the stats of the actual number of downloads of each ASCII image according to https://files.devuan.org in the last 14 days (without taking into account the other 24 ISO mirrors): - netinst: 149 - DVD ISO: 135 - CDROM ISO : 99 - desktop live : 180 - minimal-live : 77 - embedded (ARM) : 283 - virtual: 72 -- Total: 995 (yes, these are actual downloads not "file peeks", i.e., return code "200" with matching size). And please find below a more detailed explanation on the motivations behind each image: - netinst exist because it's the preferred way of installing minimal systems and servers; - the install DVD ISO exists because there are many users asking for a single medium that they can download once and install many times (e.g., due to bandwidth restrictions), and supports more than just XFCE; - the 3-cdrom set exists because we had many users asking for a smaller footprint (again, bandwidth is not cheap everywhere) set of images that they could use to install offline with a minimal XFCE desktop; - desktop-live exists because many people asked for a live Devuan version which could be easily tried and installed. This is also the preferred Devuan flavour used in reviews; - minimal-live was thought as a recovery tool and has a specific focus on accessibility (especially regarding visually-impaired and blind users), and provides a full-featured console-based setup; - so many embedded images exist because ARM vendors have not agreed on a common standard; - qcow, vagrant, and vcox images exist because many Devuan users like to have ready-to-use images for their VMs; - on top of those, there are also the usual mini.iso and netboot images, although not advertised on files.devuan.org. Quite likely, each single user would just prefer one of those images and ask themselves "oh why on Earth there are so many, indeed?". I actually use almost exclusively the mini.iso or the netboot images. The answer is that there is no single Devuan user, and no single Devuan use-case, as the statistics above confirm. What is perfect for somebody, is dumb or useless for somebody else, and vice-versa. The whole point is to make an effort to look at the bigger picture: Since Devuan is one of the few dpkg-based systemd-free distributions around, we have the *obligation* to cater for as many use cases as possible. HTH KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Drive-by critique
On 12/12/2018 11:14, Rick Moen wrote: A key part of the basis of Eric's argument is irritatingly and obviously untrue: If you want to have more devs, you need to attract a larger userbase. I'm surprised to see Eric advance this non-sequitur. I don't think it's a non sequitur, but I do think it's true as much as your points are true. I agree with both, and don't find them incompatible. Good, loyal developers are people who use your project and need more from it. Attracting more users doesn't /necessarily/ attract developers, but it's still a /prerequisite/ to attracting developers. It increases the likelihood that out of the total userbase, some fraction of that userbase will have the desire to contribute something to the project, and it also increases the /value/ of contributions if they are widely used. There are several reasons why this doesn't always hold true. Some projects are hostile to outside contributions. Others are so complex that there's a technical barrier to effective contributions. Others have cliques which don't welcome outsiders, or baroque submission processes which sap the will of any potential contributor. Or they lack the infrastructure and manpower to handle contributions effectively. So in all these cases, increasing the number of users doesn't help much. But this is a self-inflicted failure. But if a project is open to new contributors, welcomes and reviews patches in a timely manner, there's a positive reinforcement where new users are empowered and encouraged to do just this, and this both increases the number of users and developers at the same time. GNOME is an example of the former. I've had good quality, tested patches sit in its bugzilla for over a decade without review before they were summarily closed. This is a project which did not value contributions from outsiders. In the case of libgnomecanvas, they wasted the time of multiple developers writing at least six slightly different forks rather than review and apply contributed fixes to the canonical implementation to make it usable, featureful and performant. All of these forks, plus the original, are now basically dead with no users. They did not foster contributions and this led directly to a decline in both contributions and use of the libraries. It was issues like this that killed the prospects of GNOME for commercial software development in the mid 2000s, because we couldn't rely on it when issues couldn't be resolved in an effective and timely manner. CMake is an example of the latter. Turnaround time between submission and review is usually under 24 hours. It's been as little as 20 minutes. After addressing reviewer's comments and waiting for CI testing to complete, typical time between submission and merging for me has been between 24-36 hours depending upon the complexity, and for simple fixes has been as little as 60 minutes. This is a project which values code contribution from third parties, helps familiarise new developers with the project's codebase and policies, and this both encourages repeat contributions as well as grows the user base and developer base due to the utility of all this extra work going in over time. As a developer, it means I get bugfixes and new features into my users' hands immediately from git, or by the next routine point release. I and many other Debian developers got started because we needed new software packaging, or existing packages fixing or updating, and we got stuck in. For myself, I started by packaging my own upstream software releases for projects I belonged to, and went on from there to do much much more. We were users who became developers over time. While the new maintainer process is somewhat lengthy, more users means more people who find unmet needs that becoming a developer can fulfill. I started the process because other DDs were getting fed up of reviewing and uploading my work, and strongly encouraged it. I do believe the same underlying needs and motivations hold true for Devuan or any other distribution. I don't think Eric's points about ease of installation should be quite so trivially dismissed. It's not like these points haven't been raised and discussed at length by the debian-installer team for many years. Any barrier which prevents a user doing an installation and getting a working system will result in lost users who can't get over that hurdle. From difficulties finding the correct image, to making the bootable installation medium, to successfully completing the installation process. They all matter. This doesn't mean that you have to dumb things down to the lowest common denominator. But it does mean that you have to look at what is unnecessary complexity vs necessary complexity, and try to minimise the former. Reducing the number of installer images is beneficial so long as you don't sacrifice hardware support, as is having the most up to
[DNG] Drive-by critique
A very odd thing happened on #devuan, and then an incrementally odder thing on dev1galaxy, on the day before Pearl Harbour Day.Both involved a whirlwind visit by Eric Raymond -- who came and went with some quite ranty opinions. Being sleepy at the time, I good-naturedly promised Eric I'd raise his points on Devuan's mailing list. Mulling over same, though, I've had to have second thoughts -- and to my regret can't keep that promise, but will post some observations. What Eric left for us: https://dev1galaxy.org/viewtopic.php?pid=13144#p13144 The big problem is that Eric wants to hector Devuan into being things it isn't, that its careful four years of planning have not aimed towards. I doubt tat he took the trouble to properly understand Devuan's chosen mission and strategy. (I think I basically understand it, tough I'm a newcomer.) A key part of the basis of Eric's argument is irritatingly and obviously untrue: If you want to have more devs, you need to attract a larger userbase. I'm surprised to see Eric advance this non-sequitur. Open source projects attract developers because their needs and objectives (or the needs and objectives of their employers, which amounts to the same thing) are met and served. Moreover, that is a truth that has long been advanced by Open Source Initiative, which Eric co-founded, and I'm pretty sure it's also an insight in Eric's own writings. Anyway, in effect, Eric wishes a systemd-free distro existed, one he didn't realise can't be Devuan, that has only _one_ installer image (per supported CPU architecture), not several to choose among, that merges in all possible proprietary firmware BLOBs, and that consistently uses a cutting-edge installer kernel and installed kernel (hence, maximum possible new-hardware support). I don't think Eric has any clue about the developer cost of maintaining bespoke installer images, or about the weird bugs and instability that can come with bleeding-edge kernel instead of (as Devuan and Debian use) stable kernel versions with backported fixes. Also, he may not know about the developer cost of too many avoidable differences from Debian, our sister distro whose work Devuan is smart enough not to duplicate if possible, and where possible works with. Someone advocating views like Eric's might be able to make a case for them if he/she were willing to stick around and pitch in to make them happen, but in that area one finds the other problem: His advice appears to have been on a drive-by basis, near as I can tell. I'm put in mind of one of the traditional Debian answers when a visitor gets demanding and wants to know when something will be fixed or released: 'Sooner if you help.' ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
