Why did Linux Succeed while Hurd Failed?

[Jason Evans]

I'm doing some more research on Usenet lore and while reading Linus
Torvald's original announcement for Linux, he makes reference to GNU
(Hurd). I'm wondering why is it that Hurd, which was started a year before
Linux, floundered and never really went anywhere while Linux exploded.

Was it system requirements or technical limitations? Community? Stallman?

[Ahem A Rivet's Shot]

On Wed, 20 Apr 2022 08:08:26 -0000 (UTC)
Jason Evans <jse...@mailfence.com> wrote:

> I'm doing some more research on Usenet lore and while reading Linus
> Torvald's original announcement for Linux, he makes reference to GNU
> (Hurd). I'm wondering why is it that Hurd, which was started a year
> before Linux, floundered and never really went anywhere while Linux
> exploded.

The GNU project had pretty much finished reproducing all the tools
in the normal unix userland and were thrashing around looking for a kernel
(an attempt at writing one had stalled - kernels are *hard* that's why
there aren't many of them) with Mach in the frame but licensing was an
issue, when Linus Torvalds and friends finished stretching his clever task
switcher into a full blown unix kernel clone and some people had blended it
with the GNU and MIT offerings to make the first complete Linux (based
unix) systems.

> Was it system requirements or technical limitations? Community? Stallman?

Timing more than anything I think, by the time the Hurd project
sorted out their kernel difficulties Linux was well established and distros
were popping up like weeds so developer "mindshare" was getting strongly
Linux flavoured.

In the same time frame the port of CSRGs BSD to the PC was
happening and splitting into three projects, but they got tarnished with
uncertainty when AT&T launched their lawsuit. Again by the time the dust
settled Linux was established and the BSDs were playing catchup in many
ways.

None of these projects have gone away, and indeed as far as I can
tell most of them are larger (more developers) and better funded (more
equipment anyway) than they were before Linux appeared to become the unix
world. The thing is that while their slice of the pie has become small the
pie has become *much much* bigger.

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/

[Vasco Costa]

I believe the reason was Linux going for a monolithic kernel whereas GNU
Hurd opted for a microkernel, which despite being conceptually superior,
met a lot of practical hurdles. It's just easier to develop a monolithic
kernel, without having to solve problems like message passing between
servers, server reincarnation, etc.

Microkernels were a hot topic in the 80s and I suppose that's why Minix
also chose this architecture and eventually also lost to Linux. While
good in theory, it requires better developers. Linux on the other hand
just kept gaining more traction as almost "anyone" could contribute.

Then there's also a performance advantage from monolithic kernels. This
is the reason I remember myself hearing about during the 90s when I
started using Linux. By the early 2000s there was no turning back, Linux
had won the "popularity war" and everyone with a bit more technical
knowledge was using it. GNU Hurd was looked upon as a bit of an
academical project, not a real life one. During this time however, BSDs
were extremely popular as servers. There were already many Linux
servers, but the serious people used either FreeBSD or OpenBSD.

--
Vasco Costa

AKA gluon. Enthusiastic about computers, motorsports, science,
technology, travelling and TV series. Yes I'm a bit of a geek.

Gemini: gemini://gluonspace.com/

[maus]

There was minix too, which never really got anywhere except as a
concept. Linux worked (I think it was x86 only, while the others wanted
to be independent) and worked with little effort. I want to berlin on
business, and discovered that Germany really closes for Christmas, so
had free time, and went down to where the Chaos conference that year,
joined the end of a long line.

A man came out and looked at the people and saw me, exclaimed,
something like "Professor Tanenbaum!.. We were waiting for you. Come
straight in.". I had to enlighten him to the sad truth. It was peculiar
because I do not resemble Prof. Tanenbaum in any way.


--
grey...@mail.com
He said, I am the voice of one crying in the wilderness, Make straight the way of the Lord.

[J. Clarke]

Linus Torvalds produced a minimum viable product and let it be known
that it was available and development progressed from there. We are
still waiting for hurd to produce a minimum viable product. Or if
they have done so we are waiting to be informed of the fact.

[J. Clarke]

On 20 Apr 2022 10:58:53 GMT, maus <ma...@dmaus.org> wrote:

>On 2022-04-20, Ahem A Rivet's Shot <ste...@eircom.net> wrote:
>> On Wed, 20 Apr 2022 08:08:26 -0000 (UTC)
>> Jason Evans <jse...@mailfence.com> wrote:
>>
>>
>> None of these projects have gone away, and indeed as far as I can
>> tell most of them are larger (more developers) and better funded (more
>> equipment anyway) than they were before Linux appeared to become the unix
>> world. The thing is that while their slice of the pie has become small the
>> pie has become *much much* bigger.
>>
>
>There was minix too, which never really got anywhere except as a
>concept.

Well, actually it went very far. If I understand correctly Linux
started out as a rewrite of the minix kernel, so it could be viewed as
an outgrowth of minix.

[songbird]

for me the simplest reason for not doing much with it
or even trying to run it to see how it went was the lack
of the support for devices.


songbird

[Ahem A Rivet's Shot]

On Wed, 20 Apr 2022 07:49:09 -0400
J. Clarke <jclarke...@gmail.com> wrote:

> Well, actually it went very far. If I understand correctly Linux
> started out as a rewrite of the minix kernel, so it could be viewed as
> an outgrowth of minix.

Not really. Minix was an educational system that Linus used as a
bootstrapping environment to develop his kernel - there's no code
connection.

[Scott Lurndal]

Linux didn't have the restrictions on use that (would have come)
with Hurd. Particularly around proprietary device drivers. Which
make GNU Hurd a non-starter.

[Joe Pfeiffer]

maus <ma...@dmaus.org> writes:

> On 2022-04-20, Ahem A Rivet's Shot <ste...@eircom.net> wrote:
>> On Wed, 20 Apr 2022 08:08:26 -0000 (UTC)
>> Jason Evans <jse...@mailfence.com> wrote:
>>
>>
>> None of these projects have gone away, and indeed as far as I can
>> tell most of them are larger (more developers) and better funded (more
>> equipment anyway) than they were before Linux appeared to become the unix
>> world. The thing is that while their slice of the pie has become small the
>> pie has become *much much* bigger.
>>
>
> There was minix too, which never really got anywhere except as a
> concept. Linux worked (I think it was x86 only, while the others wanted
> to be independent) and worked with little effort. I want to berlin on
> business, and discovered that Germany really closes for Christmas, so
> had free time, and went down to where the Chaos conference that year,
> joined the end of a long line.

Minix was a proof of concept for microkernels, and a teaching tool. It
did quite well in those roles, especially as a teaching tool. Having
senior undergrads make modifications to a kernel made for great class
projects before the internet basically put all the reasonable projects'
code available...

Also, of course Intel's Management Engine runs it.

[Anne & Lynn Wheeler]

Ahem A Rivet's Shot <ste...@eircom.net> writes:
> The GNU project had pretty much finished reproducing all the tools
> in the normal unix userland and were thrashing around looking for a kernel
> (an attempt at writing one had stalled - kernels are *hard* that's why
> there aren't many of them) with Mach in the frame but licensing was an
> issue, when Linus Torvalds and friends finished stretching his clever task
> switcher into a full blown unix kernel clone and some people had blended it
> with the GNU and MIT offerings to make the first complete Linux (based
> unix) systems.
>

> Timing more than anything I think, by the time the Hurd project
> sorted out their kernel difficulties Linux was well established and distros
> were popping up like weeds so developer "mindshare" was getting strongly
> Linux flavoured.
>
> In the same time frame the port of CSRGs BSD to the PC was
> happening and splitting into three projects, but they got tarnished with
> uncertainty when AT&T launched their lawsuit. Again by the time the dust
> settled Linux was established and the BSDs were playing catchup in many
> ways.
>
> None of these projects have gone away, and indeed as far as I can
> tell most of them are larger (more developers) and better funded (more
> equipment anyway) than they were before Linux appeared to become the unix
> world. The thing is that while their slice of the pie has become small the
> pie has become *much much* bigger.

... also cheap massive clusters were starting to explode for
"supercomputers" and what becomes cloud megadatacenters ... and needed
full unencumbered source for adapting to their computing paradigm.

Google was multiplying their backend servers and rewritting code in
their internet facing routers to track backend server loads and do
dynamic transaction load balancing routing to backend servers.

--
virtualization experience starting Jan1968, online at home since Mar1970

[Roger Blake]

On 2022-04-20, maus <ma...@dmaus.org> wrote:
> There was minix too, which never really got anywhere except as a
> concept.

It has been reported that the Intel Management Engine is based on Minix.

https://itsfoss.com/fact-intel-minix-case/

https://www.zdnet.com/article/minix-intels-hidden-in-chip-operating-system/

--
------------------------------------------------------------------------------
18 Reasons I won't be vaccinated -- https://tinyurl.com/ebty2dx3
Covid vaccines: experimental biology -- https://tinyurl.com/57mncfm5
The fraud of "Climate Change" -- https://RealClimateScience.com
There is no "climate crisis" -- https://climatedepot.com
Don't talk to cops! -- https://DontTalkToCops.com
------------------------------------------------------------------------------

[anti...@math.uni.wroc.pl]

maus <ma...@dmaus.org> wrote:
> On 2022-04-20, Ahem A Rivet's Shot <ste...@eircom.net> wrote:
> > On Wed, 20 Apr 2022 08:08:26 -0000 (UTC)
> > Jason Evans <jse...@mailfence.com> wrote:
> >
> >
> > None of these projects have gone away, and indeed as far as I can
> > tell most of them are larger (more developers) and better funded (more
> > equipment anyway) than they were before Linux appeared to become the unix
> > world. The thing is that while their slice of the pie has become small the
> > pie has become *much much* bigger.
> >
>
> There was minix too, which never really got anywhere except as a
> concept.

Minix was were its author intended. Due to licence/copyright
people who tried to improve minix were forbidden from
sharing improvements and author did not accept improvements.
Licence changed later, but only when Linux (and BSD) were
well-developed alternatives.

> Linux worked (I think it was x86 only, while the others wanted
> to be independent) and worked with little effort.

When Linux was first released Minix was working, not stellar
but you got ready-to-go package. Linux was just one piece
(kernel) requiring effort to get working system. But Linux
could be improved and very quickly it was improved. In
particular other folks prepared ready to go bundle (distributions).

--
Waldek Hebisch

[anti...@math.uni.wroc.pl]

As Steve O'Hara-Smith wrote timing was very significant. Other IMHO
significant factors:
- Hurd was much more complicated, so much harder to write.
- Right place: Linux was initally announced on Minix mailing list.
There were several members of the list who did significant
modifications to Minix, but were not allowed to distribute
them due to Minix licence. Those people quickly went to Linux,
which from the very start gave Linux pool of qualified
contributors.
- Apparently Hurd was developed in rather closed fashion. Linux
after 6 months of Linus work was quite open.
- Extra speculation: apparently GNU folks were mostly working on
Unix workstations. Linux from the start was PC-oriented which
gave access to much larger pool of potential contributors.

--
Waldek Hebisch

[Peter Flass]

ISTR that I learned unix by using Minix. Minix on an original IBM PC was
quite painful.

--
Pete

[Ahem A Rivet's Shot]

On Thu, 21 Apr 2022 11:41:06 -0700
Peter Flass <peter...@yahoo.com> wrote:

> ISTR that I learned unix by using Minix. Minix on an original IBM PC was
> quite painful.

XENIX for the 8086 was painful on a PC - on an Altos with a couple
of Z80Bs to help the 8086 by offloading the IO it was quite usable.

[meff]

On 2022-04-20, Anne & Lynn Wheeler <ly...@garlic.com> wrote:
> ... also cheap massive clusters were starting to explode for
> "supercomputers" and what becomes cloud megadatacenters ... and needed
> full unencumbered source for adapting to their computing paradigm.

Ah yeah like Beowulf clusters. It's been a hot minute huh.

[Ahem A Rivet's Shot]

On Sun, 24 Apr 2022 12:02:45 -0400
Bud Frede <fr...@mouse-potato.com> wrote:

> HURD was perhaps a bit more of a centrally-planned project. FreeBSD,
> NetBSD, and OpenBSD were definitely centrally-planned.
>
> Linux distros were a bit like Capitalism, while the others were more
> command economies. Unfettered distros, like unfettered Capitalism,
> produced some problems. RPM-based distros vs. Debian-based ones, and
> then Arch and Gentoo, oh my! :-) Everybody has an opinion and can
> express it, and then people can pick what they want to align with.

Nice observation. It goes some way to explaining why the BSDs are
still pretty much unchanged unix systems apart from hardware support while
the Linux distros move steadily further away from being unix.

[John Levine]

According to Ahem A Rivet's Shot <ste...@eircom.net>:

> Nice observation. It goes some way to explaining why the BSDs are
>still pretty much unchanged unix systems apart from hardware support while
>the Linux distros move steadily further away from being unix.

I dunno. FreeBSD has jails, Capsicum, and native ZFS support in the
base system. Those are each pretty significant extensions beyond what
was in Unix.

--
Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

[Bob Eager]

On Sun, 24 Apr 2022 18:52:10 +0000, John Levine wrote:

> According to Ahem A Rivet's Shot <ste...@eircom.net>:
>> Nice observation. It goes some way to explaining why the BSDs are
>>still pretty much unchanged unix systems apart from hardware support
>>while the Linux distros move steadily further away from being unix.
>
> I dunno. FreeBSD has jails, Capsicum, and native ZFS support in the base
> system. Those are each pretty significant extensions beyond what was in
> Unix.

I wonder if the comment was more about moving away from the original UNIX
philosophy. It can be argued that Linux is doing that faster (I was
thinking of systemd, for example).



--
Using UNIX since v6 (1975)...

Use the BIG mirror service in the UK:
http://www.mirrorservice.org

[Ahem A Rivet's Shot]

On Sun, 24 Apr 2022 18:52:10 -0000 (UTC)
John Levine <jo...@taugh.com> wrote:

> According to Ahem A Rivet's Shot <ste...@eircom.net>:
> > Nice observation. It goes some way to explaining why the BSDs are
> >still pretty much unchanged unix systems apart from hardware support
> >while the Linux distros move steadily further away from being unix.
>
> I dunno. FreeBSD has jails, Capsicum, and native ZFS support in the
> base system. Those are each pretty significant extensions beyond what
> was in Unix.

It does indeed - but what it has been very reluctant to do is
replace things that work with something new in the hope that they will one
day work better - notable exceptions pkg-ng (OK that worked better from day
one), newpcm (now just pcm) which caused howls of protest over the loss of
midi that almost nobody used and a few cases where they've taken a small
functionality hit to replace GNU licensed tools with BSD licensed ones.

If you went to sleep in 1993 with a FreeBSD 1.1 system and woke
up today with a modern FreeBSD 13.0 system it would feel like it had grown
rather than transformed, everything still does what it used to it's just
faster[1] and there's more it can do too.

[1] OK much faster and you might be having trouble believing the numbers top
shows you.

[Quadibloc]

On Wednesday, April 20, 2022 at 4:58:55 AM UTC-6, maus wrote:

> There was minix too, which never really got anywhere except as a
> concept.

Minix was proprietary, but I thought it was there and working and
the inspiration for Linux.

John Savard

[John Levine]

According to Ahem A Rivet's Shot <ste...@eircom.net>:

> [FreeBSD] does indeed - but what it has been very reluctant to do is

>replace things that work with something new in the hope that they will one
>day work better - notable exceptions pkg-ng (OK that worked better from day
>one), newpcm (now just pcm) which caused howls of protest over the loss of
>midi that almost nobody used and a few cases where they've taken a small
>functionality hit to replace GNU licensed tools with BSD licensed ones.

I'd say that's due to the way it's distributed. With Linux, the core
part is just the kernel and each distro throws in whatever it feels
like throwing in. With FreeBSD, the core part is enough to run as a
network server and recompile itself, with everything else added from
ports and packages. While there are FBSD based packaged systems like
TrueNAS and pfSense, it is my impression that people who use FreeBSD
generally install a recent FBSD version and then add packages to make
it do what they want. I will agree that the ports of X11 and the
various desktop environments are not great, but FBSD never seriously
targeted the desktop.

[Bob Eager]

On Sun, 24 Apr 2022 20:51:09 +0100, Ahem A Rivet's Shot wrote:

> If you went to sleep in 1993 with a FreeBSD 1.1 system and woke
> up today with a modern FreeBSD 13.0 system it would feel like it had
> grown rather than transformed, everything still does what it used to
> it's just faster[1] and there's more it can do too.

Indeed. I started with FreeBSD 1.0 and I now use 13.0, and it's been
comfortable. I was worried about pkg-ng, but it is so much better.

[Ahem A Rivet's Shot]

On 24 Apr 2022 19:44:18 GMT

Bob Eager <news...@eager.cx> wrote:

> On Sun, 24 Apr 2022 18:52:10 +0000, John Levine wrote:
>
> > According to Ahem A Rivet's Shot <ste...@eircom.net>:
> >> Nice observation. It goes some way to explaining why the BSDs
> >> are
> >>still pretty much unchanged unix systems apart from hardware support
> >>while the Linux distros move steadily further away from being unix.
> >
> > I dunno. FreeBSD has jails, Capsicum, and native ZFS support in the base
> > system. Those are each pretty significant extensions beyond what was in
> > Unix.
>
> I wonder if the comment was more about moving away from the original UNIX
> philosophy. It can be argued that Linux is doing that faster (I was
> thinking of systemd, for example).

Not just the philosophy and not just systemd but that is a bit of
a poster child. I see it as part of a trend, replacing man with info,
ifconfig with ip (which I hear is deprecated now), moving config around,
emphasising the GUI, Wayland ...

[Ahem A Rivet's Shot]

On Sun, 24 Apr 2022 20:31:56 -0000 (UTC)
John Levine <jo...@taugh.com> wrote:

> According to Ahem A Rivet's Shot <ste...@eircom.net>:
> > [FreeBSD] does indeed - but what it has been very reluctant to do is
> >replace things that work with something new in the hope that they will
> >one day work better - notable exceptions pkg-ng (OK that worked better
> >from day one), newpcm (now just pcm) which caused howls of protest over
> >the loss of midi that almost nobody used and a few cases where they've
> >taken a small functionality hit to replace GNU licensed tools with BSD
> >licensed ones.
>
> I'd say that's due to the way it's distributed. With Linux, the core
> part is just the kernel and each distro throws in whatever it feels
> like throwing in. With FreeBSD, the core part is enough to run as a
> network server and recompile itself, with everything else added from

Certainly that has a lot to do with it, the BSDs were complete
systems from the start and self hosting was a goal they inherited from CSRG.

> ports and packages. While there are FBSD based packaged systems like
> TrueNAS and pfSense, it is my impression that people who use FreeBSD
> generally install a recent FBSD version and then add packages to make
> it do what they want.

That's what I've always done. I looked at both TrueNAS and pfSense
and rolled my own, they had too many bits I didn't want. Oh and generally
if I want a service running for some reason it goes in a jail on the NAS
box, the base install stays pretty well clean.

> I will agree that the ports of X11 and the

X11 is fine IME - occasional trouble with the DRI/DRM layer but
other than that it's fine and has been since X11R5.

> various desktop environments are not great, but FBSD never seriously
> targeted the desktop.

Indeed, yet for those of us who prefer a simple WM based
environment and eschew monstrosities like KDE and Gnome it works just fine
as a desktop.

[Mike Spencer]

Wot 'e said. My first Linux was a CD in a Great Fat Book. Caldera,
and it booted by default into KDE. I hastened to switch to Slackware,
set up twm and it's been my desktop on numerous computers for over 20
years.

--
Mike Spencer Nova Scotia, Canada

[maus]

I am a slackware fan, but found Debian easier to install on the last
laptop I converted to Linux.. I have an older laptop that I have
Slackware installed on, and when I upgrade that machine, the update is
not very smooth.

[Ahem A Rivet's Shot]

On 25 Apr 2022 08:44:17 GMT

maus <ma...@dmaus.org> wrote:

> I am a slackware fan, but found Debian easier to install on the last
> laptop I converted to Linux.. I have an older laptop that I have
> Slackware installed on, and when I upgrade that machine, the update is
> not very smooth.

This is one of the great features of FreeBSD - smooth painless
upgrades are the norm but you should see the howls in the mailing list any
time someone drops the ball on that, it takes months for the protests to
die down.

The workstation setup I'm using now was originally a 9.1 install,
since then it's been upgraded several times and transplanted into a new
chassis with only minor config changes for the different ethernet device.

[Ted Nolan <tednolan>]

In article <20220425064335.5645...@eircom.net>,

Indeed. I have used FreeBSD as a desktop since the early 90s. Enlightenment
is all the WM I need.
--
columbiaclosings.com
What's not in Columbia anymore..

[Mike Spencer]

In all those years, I never did an upgrade until most recently, always
did a from-scratch install, on a new (2nd hand) computer or on a new
HD. New installs have always been smooth modulo implementing my
personal idiosyncrasies/tweaks.

Most recently, I upgraded from 14.1 to 14.2. It went adequately but
not smoothly and I've some problems yet to resolve with another
upgrade to 15.0 looming. I'm still completely in 32-bit land.
Upgrade to 64 bits will mean at least one new computer and a lot of
bother -- endless bother too tedious to detail here.

[Peter Flass]

Smart. I went from 32 to 64 bits and am sorry I did. Naturally 64-bit apps
require lots more memory to do the same thing, so my machine, perfectly
useable before, now has inadequate memory and is running slower.

--
Pete

[Ahem A Rivet's Shot]

On Mon, 25 Apr 2022 13:59:52 -0700
Peter Flass <peter...@yahoo.com> wrote:

> Smart. I went from 32 to 64 bits and am sorry I did. Naturally 64-bit apps
> require lots more memory to do the same thing, so my machine, perfectly
> useable before, now has inadequate memory and is running slower.

The only real reason to go to 64 bit is to have loadsa memory.
unless it's ARM in which case the 64 bit code is often smaller than the 32
bit.

[Peter Flass]

Ahem A Rivet's Shot <ste...@eircom.net> wrote:
> On Mon, 25 Apr 2022 13:59:52 -0700
> Peter Flass <peter...@yahoo.com> wrote:
>
>> Smart. I went from 32 to 64 bits and am sorry I did. Naturally 64-bit apps
>> require lots more memory to do the same thing, so my machine, perfectly
>> useable before, now has inadequate memory and is running slower.
>
> The only real reason to go to 64 bit is to have loadsa memory.
> unless it's ARM in which case the 64 bit code is often smaller than the 32
> bit.
>

I thought it would improve the performance of gimp with large numbers of
files and/or large files, but it made things worse.

--
Pete

[maus]

I loaned a laptop to a descendent whose chrome book had barfed, and I
am now trying to get it back as she is moving to a smartphone (blaagh)
If I get it back, I will try to install Slackware on it.

[maus]

Gimp is wonderful, when you take time to learn it, but to me seems a
real memory hog.

[Dan Espen]

64 bit isn't going to help but adding lots of memory does.
My desktop is at 32G now, runs well.

--
Dan Espen

[Charlie Gibbs]

On 2022-04-25, Mike Spencer <m...@bogus.nodomain.nowhere> wrote:

Sounds like my story, except that my Great Fat Book (which I chose
because I liked it better than the other Great Fat Books in the store)
contained a Slackware CD (3.5 IIRC). I stayed with Slackware for some
time, but I found myself in dependency hell often enough that I went
on the search for a system with better package management. Ubuntu
tempted me for a while with its ease of setup and use, but version
11 brought in Unity, which I Did Not Like. CrunchBang, Mint... I
finally settled on Debian. As for desktop environments, I had already
ruled out Gnome, and KDE was not only way too heavyweight, but it kept
spitting out status messages on my main xterm window from processes
that (IMHO) had no business running at all. I tried blackbox and
fluxbox, but they were a bit too minimalistic; I settled on xfce.

--
/~\ Charlie Gibbs | Microsoft is a dictatorship.
\ / <cgi...@kltpzyxm.invalid> | Apple is a cult.
X I'm really at ac.dekanfrus | Linux is anarchy.
/ \ if you read it the right way. | Pick your poison.

[Peter Flass]

How does it compare to Photoshop in memory usage? For what I do it seems as
good or better as PS in features.

--
Pete

[Scott Lurndal]

I've been exclusively 64-bit (linux) since 2006; I've personally not found
any significant performance degradation due to the wider data type,
which isn't surprising considering that 32-bit data are still supported
by the 64-bit processors and sizeof(int) == 4. Sure, pointers are larger, but that's
generally in the noise (and compensated for by the much larger L1/L2 and
Last-Level Cache structures on modern 64-bit CPUs).

My home desktop (vintage 2014) has 16GB, 8 cores and an SSD root disk
(added in 2016). My work desktop (vintage 2012) is similarly configured.

[Kerr-Mudd, John]

On Tue, 26 Apr 2022 10:57:53 -0700

Peter Flass <peter...@yahoo.com> wrote:

> maus <ma...@dmaus.org> wrote:
> > On 2022-04-26, Peter Flass <peter...@yahoo.com> wrote:
> >> Ahem A Rivet's Shot <ste...@eircom.net> wrote:
> >>> On Mon, 25 Apr 2022 13:59:52 -0700
> >>> Peter Flass <peter...@yahoo.com> wrote:
> >>>
> >>>> Smart. I went from 32 to 64 bits and am sorry I did. Naturally 64-bit apps
> >>>> require lots more memory to do the same thing, so my machine, perfectly
> >>>> useable before, now has inadequate memory and is running slower.
> >>>
> >>> The only real reason to go to 64 bit is to have loadsa memory.
> >>> unless it's ARM in which case the 64 bit code is often smaller than the 32
> >>> bit.
> >>>
> >>
> >> I thought it would improve the performance of gimp with large numbers of
> >> files and/or large files, but it made things worse.
> >>
> >
> > Gimp is wonderful, when you take time to learn it, but to me seems a
> > real memory hog.
> >
>
> How does it compare to Photoshop in memory usage? For what I do it seems as
> good or better as PS in features.
>

I'm not a Painter, but I've heard PaintShopPro does most of what's wanted.
(I merely use IrfanView to resize pics, so what do I know?)



--
Bah, and indeed Humbug.

[Ahem A Rivet's Shot]

On 25 Apr 2022 04:20:36 -0300

Mike Spencer <m...@bogus.nodomain.nowhere> wrote:

>
> Ahem A Rivet's Shot <ste...@eircom.net> writes:
>
> > On Sun, 24 Apr 2022 20:31:56 -0000 (UTC)
> > John Levine <jo...@taugh.com> wrote:
> >
> >> various desktop environments are not great, but FBSD never seriously
> >> targeted the desktop.
> >
> > Indeed, yet for those of us who prefer a simple WM based environment
> > and eschew monstrosities like KDE and Gnome it works just fine as a
> > desktop.
>
> Wot 'e said. My first Linux was a CD in a Great Fat Book. Caldera,

My first Linux was on about seventy floppy discs, I recall thinking
that the asking price was fair value for blank floppies so it didn't matter
if the claims were garbage (£50 for a complete unix with compiler *and*
text processing *and* X11 *and* sources - crazy!). SLS was a bit rough round
the edges, sources didn't match binaries that sort of thing, but it did
have everything claimed.

> and it booted by default into KDE. I hastened to switch to Slackware,

Mine booted into a text console, my FreeBSD 13.0 systems still do.

[Joe Pfeiffer]

I started with slackware back in the 1.2 kernel series, migrated to
RedHat some time around Y2K, started using Mandrake packages with it for
reasons that I'm sure seemed good at the time, found myself in a
non-upgradeable dependency hell, started over and have been running
Debian since some time in the early 'oughts. It has worked very well
for me.

[maus]

On 2022-04-26, Charlie Gibbs <cgi...@kltpzyxm.invalid> wrote:
> On 2022-04-25, Mike Spencer <m...@bogus.nodomain.nowhere> wrote:
>
>> Ahem A Rivet's Shot <ste...@eircom.net> writes:
>>
> Sounds like my story, except that my Great Fat Book (which I chose
> because I liked it better than the other Great Fat Books in the store)
> contained a Slackware CD (3.5 IIRC). I stayed with Slackware for some
> time, but I found myself in dependency hell often enough that I went
> on the search for a system with better package management. Ubuntu
> tempted me for a while with its ease of setup and use, but version
> 11 brought in Unity, which I Did Not Like. CrunchBang, Mint... I
> finally settled on Debian. As for desktop environments, I had already
> ruled out Gnome, and KDE was not only way too heavyweight, but it kept
> spitting out status messages on my main xterm window from processes
> that (IMHO) had no business running at all. I tried blackbox and
> fluxbox, but they were a bit too minimalistic; I settled on xfce.
>

Thoroughly agreed. What I liked about Slackware is that the installation
iso included everything one would need, vim, graphics viewer, rather
than downloading a lot of needed stuff later (Tex live). Debian is the
next best OS and does me.

[maus]

I have never used photoshop.

[Bob Eager]

On Mon, 25 Apr 2022 06:43:35 +0100, Ahem A Rivet's Shot wrote:

>> ports and packages. While there are FBSD based packaged systems like
>> TrueNAS and pfSense, it is my impression that people who use FreeBSD
>> generally install a recent FBSD version and then add packages to make
>> it do what they want.
>
> That's what I've always done. I looked at both TrueNAS and pfSense
> and rolled my own, they had too many bits I didn't want. Oh and
> generally if I want a service running for some reason it goes in a jail
> on the NAS box, the base install stays pretty well clean.

That's exactly the same for me. I build most of my own packages, custom.

>> I will agree that the ports of X11 and the
>
> X11 is fine IME - occasional trouble with the DRI/DRM layer but
> other than that it's fine and has been since X11R5.

100% this. I do stick to well supported video - usually nVidia. I have no
need for high graphics performance so usually go for the passively cooled
ones.

>> various desktop environments are not great, but FBSD never seriously
>> targeted the desktop.
>
> Indeed, yet for those of us who prefer a simple WM based
> environment and eschew monstrosities like KDE and Gnome it works just
> fine as a desktop.

Absolutely. I started off with KDE and became tired of the sheer bloat,
and having *their* applications installed when I used different ones.

I use LXDE for a while, but the poor documentation and fiddly
configuration irritated me. I have been a very satisfied XFCE user for
years now.

[Mike Spencer]

Ahem A Rivet's Shot <ste...@eircom.net> writes:

> On Mon, 25 Apr 2022 13:59:52 -0700
> Peter Flass <peter...@yahoo.com> wrote:
>
>> Smart. I went from 32 to 64 bits and am sorry I did. Naturally 64-bit apps
>> require lots more memory to do the same thing, so my machine, perfectly
>> useable before, now has inadequate memory and is running slower.

My level of "smart" is of the "wait and see how New Kewl Shiny"
plays out. NKS evangelism doesn't light my fire.

> The only real reason to go to 64 bit is to have loadsa memory.
> unless it's ARM in which case the 64 bit code is often smaller than
> the 32 bit.

Huh. I wasn't aware of that. I mean, "64 bits" sounds so cool. But
in another post someone opined that Gimp was *worse* under 64 bit.

Clinging to the trailing edge of Kewl tech, I've found that server
admins are moving to the latest, crypto industry approved cipher
suites even for trivial data like local library book searches or news,
meaning that I have to upgrade my browser to get access. [1] But the
more recent releases of the browser run like a 3-legged pig,
presumably because of the RAM demands of feature/code bloat.



[1] That *is* true, isn't it? Is there a way (under Linux) to
induce/compel (say) Seamonkey N.nn to add cipher suites p, q & r
to its repertoire without upgrading to Seamonkey N+x.0 (for
whatever value of x)?

--
Mike Spencer Nova Scotia, Canada

My electric toaster is 109 years old. The power cord was upgraded in 1975.

[meff]

On 2022-04-26, maus <ma...@dmaus.org> wrote:
> Gimp is wonderful, when you take time to learn it, but to me seems a
> real memory hog.

I have many thoughts about Gimp and wonderful isn't one of them. My
partner who actually makes a good bit of art refuses to use Gimp
unless she absolutely has no other choice. It's unintuitive, the
selectors barely work, the key shortcuts make no sense. It really is
what happens when software people write art software without
consulting any actual artists. That and probably decades of legacy as
Gimp is one of the oldest desktop tools on Linux.

[Leonard Blaisdell]

On 2022-04-24, John Levine <jo...@taugh.com> wrote:

> I'd say that's due to the way it's distributed. With Linux, the core
> part is just the kernel and each distro throws in whatever it feels
> like throwing in. With FreeBSD, the core part is enough to run as a
> network server and recompile itself, with everything else added from

> ports and packages. While there are FBSD based packaged systems like
> TrueNAS and pfSense, it is my impression that people who use FreeBSD
> generally install a recent FBSD version and then add packages to make

> it do what they want. I will agree that the ports of X11 and the

> various desktop environments are not great, but FBSD never seriously
> targeted the desktop.

I'll be the odd one out here, since I've been using Macs exclusively
since the mid eighties. I ran Linux on a Mac in the mid to late nineties
for fun and mostly with Midnight Commander in the terminal, IIRC.
Having said that, I quit using Linux when Apple came out with OSX. OSX
and FBSD have a storied symbiosis of code sharing, and I'd put Apple's
desktop up against any other. Thanks, FBSD!

[songbird]

Mike Spencer wrote:
> Ahem A Rivet's Shot <ste...@eircom.net> writes:
>> On Mon, 25 Apr 2022 13:59:52 -0700
>> Peter Flass <peter...@yahoo.com> wrote:
>>
>>> Smart. I went from 32 to 64 bits and am sorry I did. Naturally 64-bit apps
>>> require lots more memory to do the same thing, so my machine, perfectly
>>> useable before, now has inadequate memory and is running slower.
>
> My level of "smart" is of the "wait and see how New Kewl Shiny"
> plays out. NKS evangelism doesn't light my fire.
>
>> The only real reason to go to 64 bit is to have loadsa memory.
>> unless it's ARM in which case the 64 bit code is often smaller than
>> the 32 bit.
>
> Huh. I wasn't aware of that. I mean, "64 bits" sounds so cool. But
> in another post someone opined that Gimp was *worse* under 64 bit.

i've not found any huge problems with GIMP on 64 bits.
i only have 8G of memory on this machine and i rarely touch
swap even when editing pics.


songbird

[Chris Adams]

Once upon a time, Peter Flass <peter...@yahoo.com> said:
>Smart. I went from 32 to 64 bits and am sorry I did. Naturally 64-bit apps
>require lots more memory to do the same thing, so my machine, perfectly
>useable before, now has inadequate memory and is running slower.

Not really "lots more" - pointers get larger, but a program is mostly
not pointers.

Also, specifically on x86, going from the 32-bit ISA to the 64-bit ISA
increased the register set, so improves performance by keeping more
things in the CPU. The 32-bit x86 ISA had a relatively small set of
registers.
--
Chris Adams <cma...@cmadams.net>

[Andy Leighton]

On Tue, 26 Apr 2022 19:48:24 +0100,
Ahem A Rivet's Shot <ste...@eircom.net> wrote:
> On 25 Apr 2022 04:20:36 -0300
> Mike Spencer <m...@bogus.nodomain.nowhere> wrote:
>
>>
>> Ahem A Rivet's Shot <ste...@eircom.net> writes:
>>
>> > On Sun, 24 Apr 2022 20:31:56 -0000 (UTC)
>> > John Levine <jo...@taugh.com> wrote:
>> >
>> >> various desktop environments are not great, but FBSD never seriously
>> >> targeted the desktop.
>> >
>> > Indeed, yet for those of us who prefer a simple WM based environment
>> > and eschew monstrosities like KDE and Gnome it works just fine as a
>> > desktop.
>>
>> Wot 'e said. My first Linux was a CD in a Great Fat Book. Caldera,
>
> My first Linux was on about seventy floppy discs, I recall thinking
> that the asking price was fair value for blank floppies so it didn't matter
> if the claims were garbage (£50 for a complete unix with compiler *and*
> text processing *and* X11 *and* sources - crazy!). SLS was a bit rough round
> the edges, sources didn't match binaries that sort of thing, but it did
> have everything claimed.

Yep SLS was my first Linux too. Pre 1.00 kernel, but it had enough to
keep me happy on my very underpowered machine (it kind of forced my hand
and I had to buy more RAM).

--
Andy Leighton => an...@azaal.plus.com
"We demand rigidly defined areas of doubt and uncertainty!"
- Douglas Adams

[maus]

Ta for that.

[Ahem A Rivet's Shot]

On Wed, 27 Apr 2022 03:40:15 -0500
Andy Leighton <an...@azaal.plus.com> wrote:

> Yep SLS was my first Linux too. Pre 1.00 kernel

Did you (like me) make the mistake of attempting to download 1.0
when it was announced ? My ftp client reported "1 bytes per second"
download rate when I gave up contributing to DDOSing Finland.

[Andy Leighton]

On Wed, 27 Apr 2022 12:15:21 +0100,

Ahem A Rivet's Shot <ste...@eircom.net> wrote:

> On Wed, 27 Apr 2022 03:40:15 -0500
> Andy Leighton <an...@azaal.plus.com> wrote:
>
>> Yep SLS was my first Linux too. Pre 1.00 kernel
>
> Did you (like me) make the mistake of attempting to download 1.0
> when it was announced ? My ftp client reported "1 bytes per second"
> download rate when I gave up contributing to DDOSing Finland.

No, I was sharing a house with someone else (who actually owned it), and I
didn't want to hog the phone-line even overnight.

[Vir Campestris]

On 26/04/2022 19:03, Scott Lurndal wrote:
> My home desktop (vintage 2014) has 16GB, 8 cores and an SSD root disk
> (added in 2016). My work desktop (vintage 2012) is similarly configured.

16Gb is enough for my home machine, but my work one thrashed. It was the
compilations that were the problem; even a rebuild takes 7 minutes, and
it's about 40 for a clean build.

Andy

[Scott Lurndal]

Must be a BSD issue :-). The software I work on takes almost an hour for a
clean (non-parallel) build under Linux (Centos 6.4) on a 7 year old Dell
server.

Using -j16, it finishes in about 8-10 minutes.

$ sloccount .
Totals grouped by language (dominant language first):
ansic: 6908969 (80.49%)
cpp: 917450 (10.69%)
python: 718036 (8.37%)
asm: 35176 (0.41%)
sh: 2535 (0.03%)
perl: 1198 (0.01%)


Several .cpp files take six minutes each to build (with -O3), primarily because
the auto-generated header files can be very large (> 100,000 SLOC).