The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
* [TUHS] Favorite unix design principles?
@ 2021-01-25 11:10 Tyler Adams
  2021-01-25 12:32 ` Steve Nickolas
  0 siblings, 1 reply; 70+ messages in thread
From: Tyler Adams @ 2021-01-25 11:10 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 540 bytes --]

I'm writing about my 5 favorite unix design principles on my blog this
week, and it got me wondering what others' favorite unix design principles
are? For reference, mine are:

- Rule of Separation (from TAOUP <http://catb.org/~esr/writings/taoup/html/>
)
- Let the Machine Do the Dirty Work (from Elements of Programming Style)
- Rule of Silence (from TAOUP <http://catb.org/~esr/writings/taoup/html/>)
- Data Dominates (Rob Pike #5)
- The SPOT (Single Point of Truth) Rule (from TAOUP
<http://catb.org/~esr/writings/taoup/html/>)

 Tyler

[-- Attachment #2: Type: text/html, Size: 815 bytes --]

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [TUHS] Favorite unix design principles?
  2021-01-25 11:10 [TUHS] Favorite unix design principles? Tyler Adams
@ 2021-01-25 12:32 ` Steve Nickolas
  2021-01-26  2:06   ` M Douglas McIlroy
  0 siblings, 1 reply; 70+ messages in thread
From: Steve Nickolas @ 2021-01-25 12:32 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

On Mon, 25 Jan 2021, Tyler Adams wrote:

> I'm writing about my 5 favorite unix design principles on my blog this
> week, and it got me wondering what others' favorite unix design principles
> are? For reference, mine are:
>
> - Rule of Separation (from TAOUP <http://catb.org/~esr/writings/taoup/html/>
> )
> - Let the Machine Do the Dirty Work (from Elements of Programming Style)
> - Rule of Silence (from TAOUP <http://catb.org/~esr/writings/taoup/html/>)
> - Data Dominates (Rob Pike #5)
> - The SPOT (Single Point of Truth) Rule (from TAOUP
> <http://catb.org/~esr/writings/taoup/html/>)
>
> Tyler
>

1. Pipes
2. Text as the preferred format for input and output
3. 'Most everything as a file
4. The idea of simple tools that are optimized for a single task
5. A powerful scripting language built into the system that, combined with 
1-4, makes writing new tools heaps easier.

-uso.

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [TUHS] Favorite unix design principles?
  2021-01-25 12:32 ` Steve Nickolas
@ 2021-01-26  2:06   ` M Douglas McIlroy
  2021-01-26  2:53     ` Steve Nickolas
  2021-01-26 10:22     ` Tyler Adams
  0 siblings, 2 replies; 70+ messages in thread
From: M Douglas McIlroy @ 2021-01-26  2:06 UTC (permalink / raw)
  To: Steve Nickolas; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 1288 bytes --]

It might be interesting to compare your final list with the two lists in
the 1978 special issue of the BSTJ--one in the Foreword, the other in the
revised version of the Ritchi/Thompson article from the CACM. How have
perceptions or values changed over time?

Doug


On Mon, Jan 25, 2021 at 7:32 AM Steve Nickolas <usotsuki@buric.co> wrote:

> On Mon, 25 Jan 2021, Tyler Adams wrote:
>
> > I'm writing about my 5 favorite unix design principles on my blog this
> > week, and it got me wondering what others' favorite unix design
> principles
> > are? For reference, mine are:
> >
> > - Rule of Separation (from TAOUP <
> http://catb.org/~esr/writings/taoup/html/>
> > )
> > - Let the Machine Do the Dirty Work (from Elements of Programming Style)
> > - Rule of Silence (from TAOUP <http://catb.org/~esr/writings/taoup/html/
> >)
> > - Data Dominates (Rob Pike #5)
> > - The SPOT (Single Point of Truth) Rule (from TAOUP
> > <http://catb.org/~esr/writings/taoup/html/>)
> >
> > Tyler
> >
>
> 1. Pipes
> 2. Text as the preferred format for input and output
> 3. 'Most everything as a file
> 4. The idea of simple tools that are optimized for a single task
> 5. A powerful scripting language built into the system that, combined with
> 1-4, makes writing new tools heaps easier.
>
> -uso.
>

[-- Attachment #2: Type: text/html, Size: 2115 bytes --]

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [TUHS] Favorite unix design principles?
  2021-01-26  2:06   ` M Douglas McIlroy
@ 2021-01-26  2:53     ` Steve Nickolas
  2021-01-26 10:22     ` Tyler Adams
  1 sibling, 0 replies; 70+ messages in thread
From: Steve Nickolas @ 2021-01-26  2:53 UTC (permalink / raw)
  To: M Douglas McIlroy; +Cc: The Eunuchs Hysterical Society

On Mon, 25 Jan 2021, M Douglas McIlroy wrote:

> It might be interesting to compare your final list with the two lists in
> the 1978 special issue of the BSTJ--one in the Foreword, the other in the
> revised version of the Ritchi/Thompson article from the CACM. How have
> perceptions or values changed over time?
>
> Doug

Funny thing is I came into *x (Solaris, and then Linux) relatively late - 
ca. 1997, after I had been using MS-DOS and ProDOS for years, which were 
the operating systems I compared it to.

It was because MS-DOS had adopted ideas from Xenix that *x was easier to 
acclimate to than other OSes I'd used.

-uso.

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [TUHS] Favorite unix design principles?
  2021-01-26  2:06   ` M Douglas McIlroy
  2021-01-26  2:53     ` Steve Nickolas
@ 2021-01-26 10:22     ` Tyler Adams
  2021-01-26 12:26       ` John P. Linderman
                         ` (2 more replies)
  1 sibling, 3 replies; 70+ messages in thread
From: Tyler Adams @ 2021-01-26 10:22 UTC (permalink / raw)
  To: M Douglas McIlroy; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 1778 bytes --]

Looking at the 1978 list, the last one really stands out:

"Use tools in preference to unskilled help to lighten a programming task"
-- The concept of unskilled help for a programming task...doesn't really
exist in 2020. The only special case is doing unskilled labor yourself.
What unskilled tasks did people used to do back in the day?

Tyler


On Tue, Jan 26, 2021 at 4:07 AM M Douglas McIlroy <
m.douglas.mcilroy@dartmouth.edu> wrote:

> It might be interesting to compare your final list with the two lists in
> the 1978 special issue of the BSTJ--one in the Foreword, the other in the
> revised version of the Ritchi/Thompson article from the CACM. How have
> perceptions or values changed over time?
>
> Doug
>
>
> On Mon, Jan 25, 2021 at 7:32 AM Steve Nickolas <usotsuki@buric.co> wrote:
>
>> On Mon, 25 Jan 2021, Tyler Adams wrote:
>>
>> > I'm writing about my 5 favorite unix design principles on my blog this
>> > week, and it got me wondering what others' favorite unix design
>> principles
>> > are? For reference, mine are:
>> >
>> > - Rule of Separation (from TAOUP <
>> http://catb.org/~esr/writings/taoup/html/>
>> > )
>> > - Let the Machine Do the Dirty Work (from Elements of Programming Style)
>> > - Rule of Silence (from TAOUP <
>> http://catb.org/~esr/writings/taoup/html/>)
>> > - Data Dominates (Rob Pike #5)
>> > - The SPOT (Single Point of Truth) Rule (from TAOUP
>> > <http://catb.org/~esr/writings/taoup/html/>)
>> >
>> > Tyler
>> >
>>
>> 1. Pipes
>> 2. Text as the preferred format for input and output
>> 3. 'Most everything as a file
>> 4. The idea of simple tools that are optimized for a single task
>> 5. A powerful scripting language built into the system that, combined
>> with
>> 1-4, makes writing new tools heaps easier.
>>
>> -uso.
>>
>

[-- Attachment #2: Type: text/html, Size: 3056 bytes --]

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [TUHS] Favorite unix design principles?
  2021-01-26 10:22     ` Tyler Adams
@ 2021-01-26 12:26       ` John P. Linderman
  2021-01-26 15:23       ` Clem Cole
       [not found]       ` <CAKH6PiXKjksEpQOMMMQTbcsMvX2thz3WzqjoRWJAsXnZ4Eq_iQ@mail.gmail.com>
  2 siblings, 0 replies; 70+ messages in thread
From: John P. Linderman @ 2021-01-26 12:26 UTC (permalink / raw)
  To: Tyler Adams; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 1543 bytes --]

On Tue, Jan 26, 2021 at 5:24 AM Tyler Adams <coppero1237@gmail.com> wrote:

> Looking at the 1978 list, the last one really stands out:
>
> "Use tools in preference to unskilled help to lighten a programming task"
> -- The concept of unskilled help for a programming task...doesn't really
> exist in 2020. The only special case is doing unskilled labor yourself.
> What unskilled tasks did people used to do back in the day?
>
> Tyler
>
>>
>>>
Drifting far off topic, but when I was programming part time for the MIT
administration in the late 60's, we wrote a small language for generating
reports from tape input. It did things like reading a record ahead, so it
could detect the last and first records having some (presumably sorted)
value, making it easy to do headers and summaries. Many report requests
from assorted administrative offices could be handled by our operators, who
had no formal programming experience. Occasionally they'd get bitten by a
request like "Give me a count of freshman and sophomores in course 18" and
they'd do the equivalent of "class == freshmen && class == sophomore",
paralleling the spoken request, and then wonder why nothing got selected.
All in all, though, it took a huge load off the skilled programmers, and
reduced the time to respond to simple requests. When I joined the Labs in
1973, we had no operators, no administrative report requests, and most
co-workers were proficient programmers. But the administrative work
environment at MIT was more representative of "the real world" than the
Labs.

[-- Attachment #2: Type: text/html, Size: 2440 bytes --]

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [TUHS] Favorite unix design principles?
  2021-01-26 10:22     ` Tyler Adams
  2021-01-26 12:26       ` John P. Linderman
@ 2021-01-26 15:23       ` Clem Cole
  2021-01-26 16:00         ` Niklas Karlsson
       [not found]       ` <CAKH6PiXKjksEpQOMMMQTbcsMvX2thz3WzqjoRWJAsXnZ4Eq_iQ@mail.gmail.com>
  2 siblings, 1 reply; 70+ messages in thread
From: Clem Cole @ 2021-01-26 15:23 UTC (permalink / raw)
  To: Tyler Adams; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 618 bytes --]

On Tue, Jan 26, 2021 at 5:23 AM Tyler Adams <coppero1237@gmail.com> wrote:

> Looking at the 1978 list, the last one really stands out:
>
> "Use tools in preference to unskilled help to lighten a programming task"
> -- The concept of unskilled help for a programming task...doesn't really
> exist in 2020. The only special case is doing unskilled labor yourself.
> What unskilled tasks did people used to do back in the day?
>
> Tyler
>
I've often wondered if this is the source of the infamous putdown: When you
operate in such or such manner,* "you could/should be replaced with a shell
script."*
ᐧ

[-- Attachment #2: Type: text/html, Size: 1568 bytes --]

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [TUHS] Favorite unix design principles?
  2021-01-26 15:23       ` Clem Cole
@ 2021-01-26 16:00         ` Niklas Karlsson
  2021-01-26 16:13           ` Adam Thornton
  0 siblings, 1 reply; 70+ messages in thread
From: Niklas Karlsson @ 2021-01-26 16:00 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 795 bytes --]

Den tis 26 jan. 2021 kl 16:24 skrev Clem Cole <clemc@ccc.com>:

>
>
> On Tue, Jan 26, 2021 at 5:23 AM Tyler Adams <coppero1237@gmail.com> wrote:
>
>> Looking at the 1978 list, the last one really stands out:
>>
>> "Use tools in preference to unskilled help to lighten a programming task"
>> -- The concept of unskilled help for a programming task...doesn't really
>> exist in 2020. The only special case is doing unskilled labor yourself.
>> What unskilled tasks did people used to do back in the day?
>>
>> Tyler
>>
> I've often wondered if this is the source of the infamous putdown: When
> you operate in such or such manner,* "you could/should be replaced with a
> shell script."*
>

The version I've heard is even "... a very small shell script".

Niklas

> ᐧ
>

[-- Attachment #2: Type: text/html, Size: 2205 bytes --]

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [TUHS] Favorite unix design principles?
  2021-01-26 16:00         ` Niklas Karlsson
@ 2021-01-26 16:13           ` Adam Thornton
  0 siblings, 0 replies; 70+ messages in thread
From: Adam Thornton @ 2021-01-26 16:13 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 1161 bytes --]

To be fair I've made a decent career spanning five calendar decades so far
out of replacing the thing I started out doing with a shell script (in
recent decades, more often Perl, then Python), so it's not the _worst_ job
advice....

On Tue, Jan 26, 2021 at 9:01 AM Niklas Karlsson <nikke.karlsson@gmail.com>
wrote:

>
>
> Den tis 26 jan. 2021 kl 16:24 skrev Clem Cole <clemc@ccc.com>:
>
>>
>>
>> On Tue, Jan 26, 2021 at 5:23 AM Tyler Adams <coppero1237@gmail.com>
>> wrote:
>>
>>> Looking at the 1978 list, the last one really stands out:
>>>
>>> "Use tools in preference to unskilled help to lighten a programming
>>> task" -- The concept of unskilled help for a programming task...doesn't
>>> really exist in 2020. The only special case is doing unskilled labor
>>> yourself. What unskilled tasks did people used to do back in the day?
>>>
>>> Tyler
>>>
>> I've often wondered if this is the source of the infamous putdown: When
>> you operate in such or such manner,* "you could/should be replaced with
>> a shell script."*
>>
>
> The version I've heard is even "... a very small shell script".
>
> Niklas
>
>> ᐧ
>>
>

[-- Attachment #2: Type: text/html, Size: 2833 bytes --]

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [TUHS] Favorite unix design principles?
       [not found]       ` <CAKH6PiXKjksEpQOMMMQTbcsMvX2thz3WzqjoRWJAsXnZ4Eq_iQ@mail.gmail.com>
@ 2021-01-30 19:01         ` Tyler Adams
  2021-01-30 19:50           ` Jon Steinhart
  0 siblings, 1 reply; 70+ messages in thread
From: Tyler Adams @ 2021-01-30 19:01 UTC (permalink / raw)
  To: M Douglas McIlroy, The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 3115 bytes --]

For sure, I've seen at least two interesting changes:
- market forces have pushed fast iteration and fast prototyping into the
mainstream in the form of Silicon valley "fail fast" culture and the
"agile" culture. This, over the disastrous "waterfall" style, has led to a
momentous improvement in overall productivity improvements.
- As coders get pulled away from the machine and performance is less and
less in coders hands, engineers aren't sucked into (premature) optimization
as much.

 Tyler


On Sat, Jan 30, 2021 at 6:10 AM M Douglas McIlroy <
m.douglas.mcilroy@dartmouth.edu> wrote:

> Have you spotted an evolutionary trend toward better, more productive
> programmers? Or has programmer productivity risen across the board due to
> better tools?  Arguably what's happened is that principle has been
> self-obsoleting, for we have cut back on the demand for unskilled (i.e.
> less capable) programmers. A broad moral principle  may be in play:
> programmers should work to put themselves out of business, i.e. it is wrong
> to be doing the same kind of work (or working in the same way) tomorrowas
> yesterday.
>
> Doug
>
>
> On Tue, Jan 26, 2021 at 5:23 AM Tyler Adams <coppero1237@gmail.com> wrote:
>
>> Looking at the 1978 list, the last one really stands out:
>>
>> "Use tools in preference to unskilled help to lighten a programming task"
>> -- The concept of unskilled help for a programming task...doesn't really
>> exist in 2020. The only special case is doing unskilled labor yourself.
>> What unskilled tasks did people used to do back in the day?
>>
>> Tyler
>>
>>
>> On Tue, Jan 26, 2021 at 4:07 AM M Douglas McIlroy <
>> m.douglas.mcilroy@dartmouth.edu> wrote:
>>
>>> It might be interesting to compare your final list with the two lists in
>>> the 1978 special issue of the BSTJ--one in the Foreword, the other in the
>>> revised version of the Ritchi/Thompson article from the CACM. How have
>>> perceptions or values changed over time?
>>>
>>> Doug
>>>
>>>
>>> On Mon, Jan 25, 2021 at 7:32 AM Steve Nickolas <usotsuki@buric.co>
>>> wrote:
>>>
>>>> On Mon, 25 Jan 2021, Tyler Adams wrote:
>>>>
>>>> > I'm writing about my 5 favorite unix design principles on my blog this
>>>> > week, and it got me wondering what others' favorite unix design
>>>> principles
>>>> > are? For reference, mine are:
>>>> >
>>>> > - Rule of Separation (from TAOUP <
>>>> http://catb.org/~esr/writings/taoup/html/>
>>>> > )
>>>> > - Let the Machine Do the Dirty Work (from Elements of Programming
>>>> Style)
>>>> > - Rule of Silence (from TAOUP <
>>>> http://catb.org/~esr/writings/taoup/html/>)
>>>> > - Data Dominates (Rob Pike #5)
>>>> > - The SPOT (Single Point of Truth) Rule (from TAOUP
>>>> > <http://catb.org/~esr/writings/taoup/html/>)
>>>> >
>>>> > Tyler
>>>> >
>>>>
>>>> 1. Pipes
>>>> 2. Text as the preferred format for input and output
>>>> 3. 'Most everything as a file
>>>> 4. The idea of simple tools that are optimized for a single task
>>>> 5. A powerful scripting language built into the system that, combined
>>>> with
>>>> 1-4, makes writing new tools heaps easier.
>>>>
>>>> -uso.
>>>>
>>>

[-- Attachment #2: Type: text/html, Size: 5101 bytes --]

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [TUHS] Favorite unix design principles?
  2021-01-30 19:01         ` Tyler Adams
@ 2021-01-30 19:50           ` Jon Steinhart
  2021-01-30 20:06             ` Tyler Adams
  0 siblings, 1 reply; 70+ messages in thread
From: Jon Steinhart @ 2021-01-30 19:50 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

Tyler Adams writes:
>
> For sure, I've seen at least two interesting changes:
> - market forces have pushed fast iteration and fast prototyping into the
> mainstream in the form of Silicon valley "fail fast" culture and the
> "agile" culture. This, over the disastrous "waterfall" style, has led to a
> momentous improvement in overall productivity improvements.
> - As coders get pulled away from the machine and performance is less and
> less in coders hands, engineers aren't sucked into (premature) optimization
> as much.

It's interesting in more than one way.

The "fail fast" culture seems to result in a lot more failure than I find
acceptable.

As performance is less in coders hands, performance is getting worse.  I
haven't seen less premature optimization, I've just seen more premature
optimization that didn't optimize anything.

My take is that the above changes have resulted in less reliable products
with poor performance being delivered more quickly.  I'm just kind of weird
in that I'd prefer better products delivered more slowly.  Especially since
much of what counts as a product these days is just churn to keep people
buying, not to provide things that are actually useful.

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [TUHS] Favorite unix design principles?
  2021-01-30 19:50           ` Jon Steinhart
@ 2021-01-30 20:06             ` Tyler Adams
  2021-01-30 21:28               ` Clem Cole
  0 siblings, 1 reply; 70+ messages in thread
From: Tyler Adams @ 2021-01-30 20:06 UTC (permalink / raw)
  To: Jon Steinhart; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 1479 bytes --]

Really? Except for one particularly incompetent team, I cannot recall
working with nor reviewing code that sacrificed clarity for performance.

 Tyler


On Sat, Jan 30, 2021 at 9:51 PM Jon Steinhart <jon@fourwinds.com> wrote:

> Tyler Adams writes:
> >
> > For sure, I've seen at least two interesting changes:
> > - market forces have pushed fast iteration and fast prototyping into the
> > mainstream in the form of Silicon valley "fail fast" culture and the
> > "agile" culture. This, over the disastrous "waterfall" style, has led to
> a
> > momentous improvement in overall productivity improvements.
> > - As coders get pulled away from the machine and performance is less and
> > less in coders hands, engineers aren't sucked into (premature)
> optimization
> > as much.
>
> It's interesting in more than one way.
>
> The "fail fast" culture seems to result in a lot more failure than I find
> acceptable.
>
> As performance is less in coders hands, performance is getting worse.  I
> haven't seen less premature optimization, I've just seen more premature
> optimization that didn't optimize anything.
>
> My take is that the above changes have resulted in less reliable products
> with poor performance being delivered more quickly.  I'm just kind of weird
> in that I'd prefer better products delivered more slowly.  Especially since
> much of what counts as a product these days is just churn to keep people
> buying, not to provide things that are actually useful.
>

[-- Attachment #2: Type: text/html, Size: 2065 bytes --]

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [TUHS] Favorite unix design principles?
  2021-01-30 20:06             ` Tyler Adams
@ 2021-01-30 21:28               ` Clem Cole
  2021-01-30 21:42                 ` Dave Horsfall
                                   ` (3 more replies)
  0 siblings, 4 replies; 70+ messages in thread
From: Clem Cole @ 2021-01-30 21:28 UTC (permalink / raw)
  To: Tyler Adams; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 3378 bytes --]

Tyler - I'm with Jon on this.  I'll pick on Apple here.  It used to be a
huge difference between MSFT SW and MacOS was that the systems folks at
Apple really tested the system and the result was that Mac OS with way
really stable.   My system never panic'ed except when I ran Windows under
parallels.   After 3-4 years ago, that stopped being true.  Crashes occur,
just like Windows BSD.   It's not unusual for my Mac to panic just letting
it run overnight - which is just backups and the like.  Yes, I have a
multiple monitors, a zillion windows open etc..


I come downstairs and the screen is blank (it should be, I have it turn off
after no activity), but I move the mouse or try to type something  --
nothing wakes the system up again.  I've chased it to Mac OS running out of
memory and not gracefully handling the lowe memory situation.  Sad, I have
16G of RAM a 1T SSD and many TB of memory on Thunderbolt 3 connectivity.

Look I grew up with a 256K byte RAM Unix V6 system on an 11/34, 3 RK05s and
an RK07 for storage.  We swapped.  Yeah, I never ran a window manager, but
he had a number of 9600K terminals on DH11's and we were happy.  You could
see it swapping like mad, but that system never crashed.  It just ran and
ran and ran.

IMO, this is what I think Jon is referring.   Those systems were stable
because we tested them and found and fixed the issue.   These days, Apple
no longer cares about Mac OS because iOS is where they now put their
effort, although I'm not super impressed there either, but I also don't
push it like I do Mac OS.  Sad really.   If I could get the day-2-day
applications that I need to work on FreeBSD, I suspect I would be there in
a heartbeat.

Clem
ᐧ

On Sat, Jan 30, 2021 at 3:07 PM Tyler Adams <coppero1237@gmail.com> wrote:

> Really? Except for one particularly incompetent team, I cannot recall
> working with nor reviewing code that sacrificed clarity for performance.
>
>  Tyler
>
>
> On Sat, Jan 30, 2021 at 9:51 PM Jon Steinhart <jon@fourwinds.com> wrote:
>
>> Tyler Adams writes:
>> >
>> > For sure, I've seen at least two interesting changes:
>> > - market forces have pushed fast iteration and fast prototyping into the
>> > mainstream in the form of Silicon valley "fail fast" culture and the
>> > "agile" culture. This, over the disastrous "waterfall" style, has led
>> to a
>> > momentous improvement in overall productivity improvements.
>> > - As coders get pulled away from the machine and performance is less and
>> > less in coders hands, engineers aren't sucked into (premature)
>> optimization
>> > as much.
>>
>> It's interesting in more than one way.
>>
>> The "fail fast" culture seems to result in a lot more failure than I find
>> acceptable.
>>
>> As performance is less in coders hands, performance is getting worse.  I
>> haven't seen less premature optimization, I've just seen more premature
>> optimization that didn't optimize anything.
>>
>> My take is that the above changes have resulted in less reliable products
>> with poor performance being delivered more quickly.  I'm just kind of
>> weird
>> in that I'd prefer better products delivered more slowly.  Especially
>> since
>> much of what counts as a product these days is just churn to keep people
>> buying, not to provide things that are actually useful.
>>
>

[-- Attachment #2: Type: text/html, Size: 5257 bytes --]

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [TUHS] Favorite unix design principles?
  2021-01-30 21:28               ` Clem Cole
@ 2021-01-30 21:42                 ` Dave Horsfall
  2021-01-30 21:45                 ` Tyler Adams
                                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 70+ messages in thread
From: Dave Horsfall @ 2021-01-30 21:42 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 681 bytes --]

On Sat, 30 Jan 2021, Clem Cole wrote:

> Look I grew up with a 256K byte RAM Unix V6 system on an 11/34, 3 RK05s 
> and an RK07 for storage.  We swapped.  Yeah, I never ran a window 
> manager, but he had a number of 9600K terminals on DH11's and we were 
> happy.  You could see it swapping like mad, but that system never 
> crashed.  It just ran and ran and ran.

You had *three* RK05s, an RK07, *and* a DH11?  We had just two, and a 
crappy DJ-11 on our /40s.  Pretty much stable; any bugs were fixed on the 
spot because we had the source code after all.

(They were configured that way to run RSX-11D, then that issue of the BSTJ 
appeared; the rest is history.)

-- Dave

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [TUHS] Favorite unix design principles?
  2021-01-30 21:28               ` Clem Cole
  2021-01-30 21:42                 ` Dave Horsfall
@ 2021-01-30 21:45                 ` Tyler Adams
  2021-01-30 22:31                   ` Larry McVoy
  2021-01-30 22:28                 ` Larry McVoy
  2021-01-30 23:09                 ` [TUHS] Favorite unix design principles? John Cowan
  3 siblings, 1 reply; 70+ messages in thread
From: Tyler Adams @ 2021-01-30 21:45 UTC (permalink / raw)
  To: Clem Cole; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 4079 bytes --]

Fair points about macOS, I hated using my mac in 2018 (thankfully I've
lived in linux bliss since), but I wouldn't say macOS is representative of
the software industry as a whole. Especially as you said iOS is Apple's
real cash cow and apple's been focusing on better *mac hardware *and from
what I hear that M1 delivers*.*

The modern software industry is mostly over the browser (or an app), and
honestly almost every site I use these days is pretty fast and stable.
Unless it has too many ads.

 Tyler


On Sat, Jan 30, 2021 at 11:28 PM Clem Cole <clemc@ccc.com> wrote:

> Tyler - I'm with Jon on this.  I'll pick on Apple here.  It used to be a
> huge difference between MSFT SW and MacOS was that the systems folks at
> Apple really tested the system and the result was that Mac OS with way
> really stable.   My system never panic'ed except when I ran Windows under
> parallels.   After 3-4 years ago, that stopped being true.  Crashes occur,
> just like Windows BSD.   It's not unusual for my Mac to panic just letting
> it run overnight - which is just backups and the like.  Yes, I have a
> multiple monitors, a zillion windows open etc..
>
>
> I come downstairs and the screen is blank (it should be, I have it turn
> off after no activity), but I move the mouse or try to type something  --
> nothing wakes the system up again.  I've chased it to Mac OS running out of
> memory and not gracefully handling the lowe memory situation.  Sad, I have
> 16G of RAM a 1T SSD and many TB of memory on Thunderbolt 3 connectivity.
>
> Look I grew up with a 256K byte RAM Unix V6 system on an 11/34, 3 RK05s
> and an RK07 for storage.  We swapped.  Yeah, I never ran a window manager,
> but he had a number of 9600K terminals on DH11's and we were happy.  You
> could see it swapping like mad, but that system never crashed.  It just ran
> and ran and ran.
>
> IMO, this is what I think Jon is referring.   Those systems were stable
> because we tested them and found and fixed the issue.   These days, Apple
> no longer cares about Mac OS because iOS is where they now put their
> effort, although I'm not super impressed there either, but I also don't
> push it like I do Mac OS.  Sad really.   If I could get the day-2-day
> applications that I need to work on FreeBSD, I suspect I would be there in
> a heartbeat.
>
> Clem
> ᐧ
>
> On Sat, Jan 30, 2021 at 3:07 PM Tyler Adams <coppero1237@gmail.com> wrote:
>
>> Really? Except for one particularly incompetent team, I cannot recall
>> working with nor reviewing code that sacrificed clarity for performance.
>>
>>  Tyler
>>
>>
>> On Sat, Jan 30, 2021 at 9:51 PM Jon Steinhart <jon@fourwinds.com> wrote:
>>
>>> Tyler Adams writes:
>>> >
>>> > For sure, I've seen at least two interesting changes:
>>> > - market forces have pushed fast iteration and fast prototyping into
>>> the
>>> > mainstream in the form of Silicon valley "fail fast" culture and the
>>> > "agile" culture. This, over the disastrous "waterfall" style, has led
>>> to a
>>> > momentous improvement in overall productivity improvements.
>>> > - As coders get pulled away from the machine and performance is less
>>> and
>>> > less in coders hands, engineers aren't sucked into (premature)
>>> optimization
>>> > as much.
>>>
>>> It's interesting in more than one way.
>>>
>>> The "fail fast" culture seems to result in a lot more failure than I find
>>> acceptable.
>>>
>>> As performance is less in coders hands, performance is getting worse.  I
>>> haven't seen less premature optimization, I've just seen more premature
>>> optimization that didn't optimize anything.
>>>
>>> My take is that the above changes have resulted in less reliable products
>>> with poor performance being delivered more quickly.  I'm just kind of
>>> weird
>>> in that I'd prefer better products delivered more slowly.  Especially
>>> since
>>> much of what counts as a product these days is just churn to keep people
>>> buying, not to provide things that are actually useful.
>>>
>>

[-- Attachment #2: Type: text/html, Size: 6295 bytes --]

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [TUHS] Favorite unix design principles?
  2021-01-30 21:28               ` Clem Cole
  2021-01-30 21:42                 ` Dave Horsfall
  2021-01-30 21:45                 ` Tyler Adams
@ 2021-01-30 22:28                 ` Larry McVoy
  2021-01-30 23:11                   ` [TUHS] FreeBSD behind the times? (was: Favorite unix design principles?) Greg 'groggy' Lehey
  2021-01-30 23:09                 ` [TUHS] Favorite unix design principles? John Cowan
  3 siblings, 1 reply; 70+ messages in thread
From: Larry McVoy @ 2021-01-30 22:28 UTC (permalink / raw)
  To: Clem Cole; +Cc: The Eunuchs Hysterical Society

On Sat, Jan 30, 2021 at 04:28:26PM -0500, Clem Cole wrote:
> If I could get the day-2-day
> applications that I need to work on FreeBSD, I suspect I would be there in
> a heartbeat.

I dunno about that.  I tried out FreeBSD a couple of years ago when
Netflix was flirting with me.  The installer hasn't seen any loving in
30 years it would seem.  The disk setup tool sucks just as bad as it
did back in 1988.

I remember when Linux was this bad in the .90ish releases.  A long time
ago.  Now their install is painless, it's every bit as good as Windows
and maybe better.  And it got that way fast, I remember doing an install
on some machine around 1998 or 1999, I didn't have a mouse plugged in,
no worries, you could just move around with the keyboard.   X11 came up
as part of the install, the entire install was graphical and seamless.

FreeBSD is stuck in the 1990's in terms of user interface.  They've done
some good stuff in the kernel but it's not an end user system, I'd argue
that the install is much worse than any of the Sun installers and I
started with BSD.

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [TUHS] Favorite unix design principles?
  2021-01-30 21:45                 ` Tyler Adams
@ 2021-01-30 22:31                   ` Larry McVoy
  0 siblings, 0 replies; 70+ messages in thread
From: Larry McVoy @ 2021-01-30 22:31 UTC (permalink / raw)
  To: Tyler Adams; +Cc: The Eunuchs Hysterical Society

On Sat, Jan 30, 2021 at 11:45:38PM +0200, Tyler Adams wrote:
> Fair points about macOS, I hated using my mac in 2018 (thankfully I've
> lived in linux bliss since), but I wouldn't say macOS is representative of
> the software industry as a whole. Especially as you said iOS is Apple's
> real cash cow and apple's been focusing on better *mac hardware *and from
> what I hear that M1 delivers*.*

M1 is a stunning pile of systems work.  Warms my heart.  Seems to be
faster, uses less power, and cheaper than Intel's best.  Kudos to Apple
for that.

> The modern software industry is mostly over the browser (or an app), and
> honestly almost every site I use these days is pretty fast and stable.
> Unless it has too many ads.

Ad blocker to the rescue, I use ublock origin and it works great.

--lm

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [TUHS] Favorite unix design principles?
  2021-01-30 21:28               ` Clem Cole
                                   ` (2 preceding siblings ...)
  2021-01-30 22:28                 ` Larry McVoy
@ 2021-01-30 23:09                 ` John Cowan
  2021-01-30 23:22                   ` Jon Steinhart
  3 siblings, 1 reply; 70+ messages in thread
From: John Cowan @ 2021-01-30 23:09 UTC (permalink / raw)
  To: Clem Cole; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 1994 bytes --]

On Sat, Jan 30, 2021 at 4:29 PM Clem Cole <clemc@ccc.com> wrote:


> These days, Apple no longer cares about Mac OS because iOS is where they
> now put their effort, although I'm not super impressed there either, but I
> also don't push it like I do Mac OS.  Sad really.   If I could get the
> day-2-day applications that I need to work on FreeBSD, I suspect I would be
> there in a heartbeat.
>

Decades ago I worked out the lifecycle of tech companies:

1) Engineering-driven: the goal is to make and sell high-quality products.
DEC and HP were like this for a long time.

2) Sales-driven: the goal is to sell products, high-quality or not.  Too
many examples to specify.

3) Finance-driven: the goal is to make money, whether you sell products or
not.  The classic case here is Carnegie Steel.  When Carnegie told his
direct reports they were going into the railroad business and they
protested that the company knew nothing about it, he said "Carnegie Steel
isn't about making steel, it's about making money, and anyone who forgets
that is fired."

4) Survival-driven: the goal is to keep the company going whether you make
money or not.  Auto companies just after bailouts are in this step.  In
particular, Chrysler was bailed out in 1979 and again in 2009: see Tom
Paxton's song "I'm Changing My Name To Chrysler" (covered by Arlo and Pete
on _Precious Friends_).

On Sat, Jan 30, 2021 at 4:43 PM Dave Horsfall <dave@horsfall.org> wrote:

You had *three* RK05s, an RK07, *and* a DH11?  We had just two, and a
> crappy DJ-11 on our /40s.  Pretty much stable; any bugs were fixed on the
> spot because we had the source code after all.
>

I cut my teeth on a PDP-8 with a single TU58 DECtape and a TD8/E controller
(no interrupts, no data break cycles; I/O was more or less analogous to
terminal I/O).  Uphill both ways in the snow.



John Cowan          http://vrici.lojban.org/~cowan        cowan@ccil.org
So they play that [tune] on their fascist banjos, eh?
        --Great-Souled Sam

[-- Attachment #2: Type: text/html, Size: 4342 bytes --]

^ permalink raw reply	[flat|nested] 70+ messages in thread

* [TUHS] FreeBSD behind the times? (was: Favorite unix design principles?)
  2021-01-30 22:28                 ` Larry McVoy
@ 2021-01-30 23:11                   ` Greg 'groggy' Lehey
  2021-01-30 23:17                     ` Larry McVoy
                                       ` (2 more replies)
  0 siblings, 3 replies; 70+ messages in thread
From: Greg 'groggy' Lehey @ 2021-01-30 23:11 UTC (permalink / raw)
  To: Larry McVoy; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 2443 bytes --]

On Saturday, 30 January 2021 at 14:28:54 -0800, Larry McVoy wrote:
> On Sat, Jan 30, 2021 at 04:28:26PM -0500, Clem Cole wrote:
>> If I could get the day-2-day
>> applications that I need to work on FreeBSD, I suspect I would be there in
>> a heartbeat.
>
> I dunno about that.  I tried out FreeBSD a couple of years ago when
> Netflix was flirting with me.  The installer hasn't seen any loving in
> 30 years it would seem.  The disk setup tool sucks just as bad as it
> did back in 1988.

You could be right there, for some value of 1988 (FreeBSD came into
being in 1992).  The tools work without being good.  But how often do
you use them?  I've been using FreeBSD since the beginning, and I
can't recall when I last used the disk partitioning tool, though I'm
sure that when I did I overrode a lot of (all?) the suggestions.

> I remember when Linux was this bad in the .90ish releases.  A long
> time ago.  Now their install is painless, it's every bit as good as
> Windows and maybe better.

FWIW, I find Microsoft "Windows" installation terminally confusing
(that's what you were talking about, right?).  And I've run into
serious problems with various Linux installations too.  That doesn't
make the FreeBSD tools better, but maybe it relativizes it.

> And it got that way fast, I remember doing an install on some
> machine around 1998 or 1999, I didn't have a mouse plugged in, no
> worries, you could just move around with the keyboard.  X11 came up
> as part of the install, the entire install was graphical and
> seamless.

The FreeBSD installer *does* install X if you select it.

> FreeBSD is stuck in the 1990's in terms of user interface.

You're still talking about the installer, aren't you?  The normal user
interface is via the shell, which hasn't changed, and for a good
reason.

> They've done some good stuff in the kernel but it's not an end user
> system,

There I have to agree with you.  A little TLC would go a long way.
But I hope that you're not advocating the "change your GUI with your
underwear" attitude that Microsoft, Apple and many Linux distros
have.  One of the reasons I don't use Linux is because every time I
try, the interface has changed.

Greg
--
Sent from my desktop computer.
Finger grog@lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [TUHS] FreeBSD behind the times? (was: Favorite unix design principles?)
  2021-01-30 23:11                   ` [TUHS] FreeBSD behind the times? (was: Favorite unix design principles?) Greg 'groggy' Lehey
@ 2021-01-30 23:17                     ` Larry McVoy
  2021-01-30 23:22                       ` Warner Losh
  2021-01-31  0:39                     ` Steve Nickolas
  2021-01-31  1:47                     ` Will Senn
  2 siblings, 1 reply; 70+ messages in thread
From: Larry McVoy @ 2021-01-30 23:17 UTC (permalink / raw)
  To: Greg 'groggy' Lehey; +Cc: The Eunuchs Hysterical Society

On Sun, Jan 31, 2021 at 10:11:19AM +1100, Greg 'groggy' Lehey wrote:
> > I remember when Linux was this bad in the .90ish releases.  A long
> > time ago.  Now their install is painless, it's every bit as good as
> > Windows and maybe better.
> 
> FWIW, I find Microsoft "Windows" installation terminally confusing
> (that's what you were talking about, right?).  And I've run into
> serious problems with various Linux installations too.  That doesn't
> make the FreeBSD tools better, but maybe it relativizes it.

Um, my mother could install any Linux system today and 10-20 years ago.
There is not the slightest chance that she could install FreeBSD.

> The FreeBSD installer *does* install X if you select it.

Linux installers start in X.  No "select it" required.

> > FreeBSD is stuck in the 1990's in terms of user interface.
> 
> You're still talking about the installer, aren't you?  

Yup.  If FreeBSD wants anyone to use it, fix that installer.  99.99%
of people would give up after seeing that, you'd never get them to 
userland.

> > They've done some good stuff in the kernel but it's not an end user
> > system,
> 
> There I have to agree with you.  A little TLC would go a long way.
> But I hope that you're not advocating the "change your GUI with your
> underwear" attitude that Microsoft, Apple and many Linux distros
> have.  One of the reasons I don't use Linux is because every time I
> try, the interface has changed.

Try xubuntu, that's what I use.  Pretty light weight UI but all the
parts are there and it doesn't change much.

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [TUHS] FreeBSD behind the times? (was: Favorite unix design principles?)
  2021-01-30 23:17                     ` Larry McVoy
@ 2021-01-30 23:22                       ` Warner Losh
  2021-01-30 23:31                         ` [TUHS] [SPAM] " Larry McVoy
  2021-02-09  2:15                         ` [TUHS] " Will Senn
  0 siblings, 2 replies; 70+ messages in thread
From: Warner Losh @ 2021-01-30 23:22 UTC (permalink / raw)
  To: Larry McVoy; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 2143 bytes --]

On Sat, Jan 30, 2021 at 4:19 PM Larry McVoy <lm@mcvoy.com> wrote:

> On Sun, Jan 31, 2021 at 10:11:19AM +1100, Greg 'groggy' Lehey wrote:
> > > I remember when Linux was this bad in the .90ish releases.  A long
> > > time ago.  Now their install is painless, it's every bit as good as
> > > Windows and maybe better.
> >
> > FWIW, I find Microsoft "Windows" installation terminally confusing
> > (that's what you were talking about, right?).  And I've run into
> > serious problems with various Linux installations too.  That doesn't
> > make the FreeBSD tools better, but maybe it relativizes it.
>
> Um, my mother could install any Linux system today and 10-20 years ago.
> There is not the slightest chance that she could install FreeBSD.
>

I find that hard to believe. The defaults just work on the vast majority of
systems, even if the interface is text-based and not a fancy GUI...


> > The FreeBSD installer *does* install X if you select it.
>
> Linux installers start in X.  No "select it" required.
>

Yea. Once upon a  time, this was super dangerous. These days it's kinda
required.


> > > FreeBSD is stuck in the 1990's in terms of user interface.
> >
> > You're still talking about the installer, aren't you?
>
> Yup.  If FreeBSD wants anyone to use it, fix that installer.  99.99%
> of people would give up after seeing that, you'd never get them to
> userland.
>

No argument there...  Part of the problem is that, up until relatively
lately, the whole X experience sucked really badly on FreeBSD. Now that it
doesn't suck, it's time for a re-evaluation...


> > > They've done some good stuff in the kernel but it's not an end user
> > > system,
> >
> > There I have to agree with you.  A little TLC would go a long way.
> > But I hope that you're not advocating the "change your GUI with your
> > underwear" attitude that Microsoft, Apple and many Linux distros
> > have.  One of the reasons I don't use Linux is because every time I
> > try, the interface has changed.
>
> Try xubuntu, that's what I use.  Pretty light weight UI but all the
> parts are there and it doesn't change much.
>

But yet it's not stuck?

Warner

[-- Attachment #2: Type: text/html, Size: 3299 bytes --]

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [TUHS] Favorite unix design principles?
  2021-01-30 23:09                 ` [TUHS] Favorite unix design principles? John Cowan
@ 2021-01-30 23:22                   ` Jon Steinhart
  0 siblings, 0 replies; 70+ messages in thread
From: Jon Steinhart @ 2021-01-30 23:22 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

John Cowan writes:
>
> Decades ago I worked out the lifecycle of tech companies:
>
> 1) Engineering-driven: the goal is to make and sell high-quality products.
> DEC and HP were like this for a long time.
>
> 2) Sales-driven: the goal is to sell products, high-quality or not.  Too
> many examples to specify.
>
> 3) Finance-driven: the goal is to make money, whether you sell products or
> not.  The classic case here is Carnegie Steel.  When Carnegie told his
> direct reports they were going into the railroad business and they
> protested that the company knew nothing about it, he said "Carnegie Steel
> isn't about making steel, it's about making money, and anyone who forgets
> that is fired."
>
> 4) Survival-driven: the goal is to keep the company going whether you make
> money or not.  Auto companies just after bailouts are in this step.  In
> particular, Chrysler was bailed out in 1979 and again in 2009: see Tom
> Paxton's song "I'm Changing My Name To Chrysler" (covered by Arlo and Pete
> on _Precious Friends_).

Don't want to get too off topic here, but I consider myself fortunate
to have spent the prime of my career working on #1.  I always believed
that if one made high quality-products that met a customer's need that
the rest would take care of itself.  Yeah, I'm naive.  I see 2-4 as
indicative of Silicon Valley today where I don't think that I could work.
It's no longer about making great things, it's about making money, if if
absolutely necessary, making something to support that goal.  If you took
the trouble to read the Microsoft antitrust trial depositions, you'd see
that this was exactly Bill Gate's MO.  He would try to tank competition
through any means necessary except making a better product; that only
happened when everything else failed.

I've probably ranted about this before, but to me this is emblematic of
how America has lost its way.  My big evil villians are Jack Welch and
Bill Gates.  When I was growing up and kids were asked "What do you want
to be when you grow up?", the answer was always astronaut first, then
doctor, lawyer, engineer, and so on.  Post Microsoft, the answer was "I
want to be as rich as Bill Gates."  People just want the outcome without
having to do any of the work, and just want the results without the joy
of actual accomplishment.  I find it sad.

Jon

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [TUHS] [SPAM] Re: FreeBSD behind the times? (was: Favorite unix design principles?)
  2021-01-30 23:22                       ` Warner Losh
@ 2021-01-30 23:31                         ` Larry McVoy
  2021-01-30 23:37                           ` Jon Steinhart
  2021-02-09  2:15                         ` [TUHS] " Will Senn
  1 sibling, 1 reply; 70+ messages in thread
From: Larry McVoy @ 2021-01-30 23:31 UTC (permalink / raw)
  To: Warner Losh; +Cc: The Eunuchs Hysterical Society

On Sat, Jan 30, 2021 at 04:22:49PM -0700, Warner Losh wrote:
> On Sat, Jan 30, 2021 at 4:19 PM Larry McVoy <lm@mcvoy.com> wrote:
> 
> > On Sun, Jan 31, 2021 at 10:11:19AM +1100, Greg 'groggy' Lehey wrote:
> > > > I remember when Linux was this bad in the .90ish releases.  A long
> > > > time ago.  Now their install is painless, it's every bit as good as
> > > > Windows and maybe better.
> > >
> > > FWIW, I find Microsoft "Windows" installation terminally confusing
> > > (that's what you were talking about, right?).  And I've run into
> > > serious problems with various Linux installations too.  That doesn't
> > > make the FreeBSD tools better, but maybe it relativizes it.
> >
> > Um, my mother could install any Linux system today and 10-20 years ago.
> > There is not the slightest chance that she could install FreeBSD.
> 
> I find that hard to believe. The defaults just work on the vast majority of
> systems, even if the interface is text-based and not a fancy GUI...

I speak from experience of trying to install FreeBSD on a netflix server
a couple of years back.  It wasn't pleasant and it seems pretty identical
to the installer I used decades ago.

> > > > FreeBSD is stuck in the 1990's in terms of user interface.
> > >
> > > You're still talking about the installer, aren't you?
> >
> > Yup.  If FreeBSD wants anyone to use it, fix that installer.  99.99%
> > of people would give up after seeing that, you'd never get them to
> > userland.
> 
> No argument there...  Part of the problem is that, up until relatively
> lately, the whole X experience sucked really badly on FreeBSD. Now that it
> doesn't suck, it's time for a re-evaluation...

It's 20 years past the time for that re-evaluation.  Seriously, Linux
distros have been installing in X for at least 20 years, I think maybe
more.  If they can do it....

> > > > They've done some good stuff in the kernel but it's not an end user
> > > > system,
> > >
> > > There I have to agree with you.  A little TLC would go a long way.
> > > But I hope that you're not advocating the "change your GUI with your
> > > underwear" attitude that Microsoft, Apple and many Linux distros
> > > have.  One of the reasons I don't use Linux is because every time I
> > > try, the interface has changed.
> >
> > Try xubuntu, that's what I use.  Pretty light weight UI but all the
> > parts are there and it doesn't change much.
> 
> But yet it's not stuck?

Nope, it's not remotely stuck.  I get it, you like FreeBSD.  That's fine
but be honest about where it is.  How many of the developers with a commit
bit actually run FreeBSD on their desktop and laptops?  As their daily
platform?

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [TUHS] [SPAM] Re: FreeBSD behind the times? (was: Favorite unix design principles?)
  2021-01-30 23:31                         ` [TUHS] [SPAM] " Larry McVoy
@ 2021-01-30 23:37                           ` Jon Steinhart
  2021-01-30 23:54                             ` Larry McVoy
  2021-01-31  0:00                             ` [TUHS] [SPAM] Re: FreeBSD behind the times? (was: Favorite unix design principles?) Bakul Shah
  0 siblings, 2 replies; 70+ messages in thread
From: Jon Steinhart @ 2021-01-30 23:37 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

Larry McVoy writes:
> It's 20 years past the time for that re-evaluation.  Seriously, Linux
> distros have been installing in X for at least 20 years, I think maybe
> more.  If they can do it....

That doesn't mean that it's great.  It's only easy to use once one learns
the quirks, like it appearing to hang with no feedback when you hit buttons,
and the way one has to click "done" when you're not actually done.  The
number of options is so small that I think that it would be better to just
have the whole configuration on a single screen so that newbies wouldn't
have to wonder where things were done and whether or not they'd be able to
"go back" without trying it.

> Nope, it's not remotely stuck.  I get it, you like FreeBSD.  That's fine
> but be honest about where it is.  How many of the developers with a commit
> bit actually run FreeBSD on their desktop and laptops?  As their daily
> platform?

Huh, I thought that most of the linux developers these days ran on Macs.

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [TUHS] [SPAM] Re: FreeBSD behind the times? (was: Favorite unix design principles?)
  2021-01-30 23:37                           ` Jon Steinhart
@ 2021-01-30 23:54                             ` Larry McVoy
  2021-01-31 12:23                               ` [TUHS] [SPAM] Re: FreeBSD behind the times? Dermot Tynan
  2021-01-31  0:00                             ` [TUHS] [SPAM] Re: FreeBSD behind the times? (was: Favorite unix design principles?) Bakul Shah
  1 sibling, 1 reply; 70+ messages in thread
From: Larry McVoy @ 2021-01-30 23:54 UTC (permalink / raw)
  To: Jon Steinhart; +Cc: The Eunuchs Hysterical Society

On Sat, Jan 30, 2021 at 03:37:29PM -0800, Jon Steinhart wrote:
> Larry McVoy writes:
> > It's 20 years past the time for that re-evaluation.  Seriously, Linux
> > distros have been installing in X for at least 20 years, I think maybe
> > more.  If they can do it....
> 
> That doesn't mean that it's great.  

It's on the same level as Windows and has been for a long time.  In fact,
it has been better than Windows for at least 10 years and probably longer.
It takes me way longer to install Windows and then go get this driver, 
and then go get that one, whoops, that's the wrong one, they wanted 
32 bit emulation mode blah blah blah, go get that one. 

Linux, other than closed source drivers and even that is pretty pleasant
these days, just works.

> Huh, I thought that most of the linux developers these days ran on Macs.

I can imagine that, Macs have nice screens.  But they run Linux on their
Macs.

Look, this is turning into a Linux vs BSD pissing contest.  You do
realize that I started in the best BSD ever, SunOS, right?  I was a BSD
guy long before I was a Linux guy, UW-Madison was all BSD on the vaxen
and I loved it.  But I didn't have to install it.  So it wasn't until
later I got to see the hell that is the FreeBSD installer.

You like FreeBSD, cool, it's fine.  Nobody will ever know because nobody
is going to put up with a 1990's era installer.  Nobody.  It's 2020, shit
is just supposed to work, it's supposed do so in a graphical environment
let works with or without a mouse.  Anyone who doesn't see that isn't
going to get any market share.

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [TUHS] [SPAM] Re: FreeBSD behind the times? (was: Favorite unix design principles?)
  2021-01-30 23:37                           ` Jon Steinhart
  2021-01-30 23:54                             ` Larry McVoy
@ 2021-01-31  0:00                             ` Bakul Shah
  1 sibling, 0 replies; 70+ messages in thread
From: Bakul Shah @ 2021-01-31  0:00 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

On Jan 30, 2021, at 3:37 PM, Jon Steinhart <jon@fourwinds.com> wrote:
> 
> Larry McVoy writes:
>> It's 20 years past the time for that re-evaluation.  Seriously, Linux
>> distros have been installing in X for at least 20 years, I think maybe
>> more.  If they can do it....
> 
> That doesn't mean that it's great.  It's only easy to use once one learns
> the quirks, like it appearing to hang with no feedback when you hit buttons,
> and the way one has to click "done" when you're not actually done.  The
> number of options is so small that I think that it would be better to just
> have the whole configuration on a single screen so that newbies wouldn't
> have to wonder where things were done and whether or not they'd be able to
> "go back" without trying it.

I vastly prefer FreeBSD over Linux but Larry has a point. Presenting *any*
configuration choice to a newbie can be confusing as they often lack the
knowledge to make an "informed choice". I do think your idea of a single
screen config is great, but with defaults chosen! The installer should
proceed after a time if the user doesn't change anything. Perhaps this can
be a useful GSOC project?

But we should bring this back to design principles! Ease of use should
certainly be one of them.

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [TUHS] FreeBSD behind the times? (was: Favorite unix design principles?)
  2021-01-30 23:11                   ` [TUHS] FreeBSD behind the times? (was: Favorite unix design principles?) Greg 'groggy' Lehey
  2021-01-30 23:17                     ` Larry McVoy
@ 2021-01-31  0:39                     ` Steve Nickolas
  2021-01-31  1:47                     ` Will Senn
  2 siblings, 0 replies; 70+ messages in thread
From: Steve Nickolas @ 2021-01-31  0:39 UTC (permalink / raw)
  To: Greg 'groggy' Lehey; +Cc: The Eunuchs Hysterical Society

On Sun, 31 Jan 2021, Greg 'groggy' Lehey wrote:

> But I hope that you're not advocating the "change your GUI with your
> underwear" attitude that Microsoft, Apple and many Linux distros
> have.  One of the reasons I don't use Linux is because every time I
> try, the interface has changed.

I'm still using the same GUI I've used for the last decade, although its 
name changed.

Personally, I think a lot of Linux people who haven't come from a Unix 
background don't understand Linux, because they don't understand Unix. And 
because they don't understand Linux, they're trying to mutilate it into 
being something other than what it was meant to be.

I thought of creating a system built on top of Linux that represented the 
system as I visualized it.  And I've come a fair way, but I don't yet have 
the important parts (the ability to self-host, including a working kernel, 
C compiler and libc) up and running, but there's pretty much your basic 
stuff in /bin, /usr/bin etc., and there's a curses library, and there's ed 
and vi (more or less)...so once those are available there'll be enough to 
get the rest of it functional.  Of course, as I visualized it will seem 
remarkably antiquated to most people!

-uso.

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [TUHS] FreeBSD behind the times? (was: Favorite unix design principles?)
  2021-01-30 23:11                   ` [TUHS] FreeBSD behind the times? (was: Favorite unix design principles?) Greg 'groggy' Lehey
  2021-01-30 23:17                     ` Larry McVoy
  2021-01-31  0:39                     ` Steve Nickolas
@ 2021-01-31  1:47                     ` Will Senn
  2021-01-31  2:25                       ` Larry McVoy
  2 siblings, 1 reply; 70+ messages in thread
From: Will Senn @ 2021-01-31  1:47 UTC (permalink / raw)
  To: Greg 'groggy' Lehey; +Cc: The Eunuchs Hysterical Society

Oh brother. I use FreeBSD all the time. I prefer it for its stability and ZFS which has NEVER let me down and I’ve done my share of stupid user error. Now that Linux has ZFS, it doesn’t seem as stuck in the dark ages, but uptime on my fbsd instance is 10x any of my Linux instances. We are soooo off topic, I think :). But, I’m always up for talking up FBSD. I use it in my classes, too and the system is much more coherent for my systems programming classes than linux.

Will

Sent from my iPhone

> On Jan 30, 2021, at 5:11 PM, Greg 'groggy' Lehey <grog@lemis.com> wrote:
> 
>> On Saturday, 30 January 2021 at 14:28:54 -0800, Larry McVoy wrote:
>>> On Sat, Jan 30, 2021 at 04:28:26PM -0500, Clem Cole wrote:
>>> If I could get the day-2-day
>>> applications that I need to work on FreeBSD, I suspect I would be there in
>>> a heartbeat.
>> 
>> I dunno about that.  I tried out FreeBSD a couple of years ago when
>> Netflix was flirting with me.  The installer hasn't seen any loving in
>> 30 years it would seem.  The disk setup tool sucks just as bad as it
>> did back in 1988.
> 
> You could be right there, for some value of 1988 (FreeBSD came into
> being in 1992).  The tools work without being good.  But how often do
> you use them?  I've been using FreeBSD since the beginning, and I
> can't recall when I last used the disk partitioning tool, though I'm
> sure that when I did I overrode a lot of (all?) the suggestions.
> 
>> I remember when Linux was this bad in the .90ish releases.  A long
>> time ago.  Now their install is painless, it's every bit as good as
>> Windows and maybe better.
> 
> FWIW, I find Microsoft "Windows" installation terminally confusing
> (that's what you were talking about, right?).  And I've run into
> serious problems with various Linux installations too.  That doesn't
> make the FreeBSD tools better, but maybe it relativizes it.
> 
>> And it got that way fast, I remember doing an install on some
>> machine around 1998 or 1999, I didn't have a mouse plugged in, no
>> worries, you could just move around with the keyboard.  X11 came up
>> as part of the install, the entire install was graphical and
>> seamless.
> 
> The FreeBSD installer *does* install X if you select it.
> 
>> FreeBSD is stuck in the 1990's in terms of user interface.
> 
> You're still talking about the installer, aren't you?  The normal user
> interface is via the shell, which hasn't changed, and for a good
> reason.
> 
>> They've done some good stuff in the kernel but it's not an end user
>> system,
> 
> There I have to agree with you.  A little TLC would go a long way.
> But I hope that you're not advocating the "change your GUI with your
> underwear" attitude that Microsoft, Apple and many Linux distros
> have.  One of the reasons I don't use Linux is because every time I
> try, the interface has changed.
> 
> Greg
> --
> Sent from my desktop computer.
> Finger grog@lemis.com for PGP public key.
> See complete headers for address and phone numbers.
> This message is digitally signed.  If your Microsoft mail program
> reports problems, please read http://lemis.com/broken-MUA

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [TUHS] FreeBSD behind the times? (was: Favorite unix design principles?)
  2021-01-31  1:47                     ` Will Senn
@ 2021-01-31  2:25                       ` Larry McVoy
  2021-01-31  2:52                         ` Will Senn
                                           ` (3 more replies)
  0 siblings, 4 replies; 70+ messages in thread
From: Larry McVoy @ 2021-01-31  2:25 UTC (permalink / raw)
  To: Will Senn; +Cc: The Eunuchs Hysterical Society

If you like ZFS you don't understand operating systems design.  I do.
Jeff Bonwick was a stats student at Stanford when he took my OS class,
I convinced him to come to Sun.  Bill Moore worked for me.  That's the two
main ZFS guys and I thought I had taught them well but they let me down.

ZFS doesn't use the page cache, they said it was too hard because ZFS
is compressed.  A typical file system just has block numbers, a compressed
one needs another int per block, it's the int that says these many bytes
are a block uncompressed.  It's not that hard, it is 2 ints instead of 1.

In case I'm not being clear, the page cache is what everyone else uses
but ZFS has its own cache.  So if you want to mmap() a ZFS file, ZFS
has to bcopy() the data into the page cache and then spend a shit ton
of code to make sure that the page cache data is in sync with the ZFS
cache data.

SunOS came from BSD but SunOS added mmap.  Which had the same problem,
the BSD buffer cache was exactly the same as the ZFS cache, Sun spent 
years of effort to get rid of the buffer cache, everything is in the 
page cache.  So ZFS was a HUGE step backwards in systems design.  Might
be the best file system ever (it is not) but it was not a good player
in the OS world.

Those guys said that it was too hard to make a compressed file fit in
the page cache.  BitKeeper has that code and proves that it can be done.
Be happy to walk anyone who cares through that code, I didn't write that,
Wayne Scott did, but it's some of the best written code I've ever seen.
Up there with Mojo's work on the SunOS VM system.  (I'll bet that noone
takes me up on this offer, people love to argue but most don't want to
learn.  Prove me wrong, please).

So good on you that you like ZFS and FreeBSD.  I don't and I don't for
really good reasons.

Let's try it this way.  Get back to me when you can show me 40 people 
who have installed FreeBSD on their own, with no help.  In the same 
time, I can show you 40,000 people who have installed Linux on their
own, with no help.  Probably 400,000.

Technology is great, ease of use is what gets you users.  ZFS is
great but doesn't play nice with the OS.

That's my oh brother.

On Sat, Jan 30, 2021 at 07:47:41PM -0600, Will Senn wrote:
> Oh brother. I use FreeBSD all the time. I prefer it for its stability and ZFS which has NEVER let me down and I???ve done my share of stupid user error. Now that Linux has ZFS, it doesn???t seem as stuck in the dark ages, but uptime on my fbsd instance is 10x any of my Linux instances. We are soooo off topic, I think :). But, I???m always up for talking up FBSD. I use it in my classes, too and the system is much more coherent for my systems programming classes than linux.
> 
> Will
> 
> Sent from my iPhone
> 
> > On Jan 30, 2021, at 5:11 PM, Greg 'groggy' Lehey <grog@lemis.com> wrote:
> > 
> >> On Saturday, 30 January 2021 at 14:28:54 -0800, Larry McVoy wrote:
> >>> On Sat, Jan 30, 2021 at 04:28:26PM -0500, Clem Cole wrote:
> >>> If I could get the day-2-day
> >>> applications that I need to work on FreeBSD, I suspect I would be there in
> >>> a heartbeat.
> >> 
> >> I dunno about that.  I tried out FreeBSD a couple of years ago when
> >> Netflix was flirting with me.  The installer hasn't seen any loving in
> >> 30 years it would seem.  The disk setup tool sucks just as bad as it
> >> did back in 1988.
> > 
> > You could be right there, for some value of 1988 (FreeBSD came into
> > being in 1992).  The tools work without being good.  But how often do
> > you use them?  I've been using FreeBSD since the beginning, and I
> > can't recall when I last used the disk partitioning tool, though I'm
> > sure that when I did I overrode a lot of (all?) the suggestions.
> > 
> >> I remember when Linux was this bad in the .90ish releases.  A long
> >> time ago.  Now their install is painless, it's every bit as good as
> >> Windows and maybe better.
> > 
> > FWIW, I find Microsoft "Windows" installation terminally confusing
> > (that's what you were talking about, right?).  And I've run into
> > serious problems with various Linux installations too.  That doesn't
> > make the FreeBSD tools better, but maybe it relativizes it.
> > 
> >> And it got that way fast, I remember doing an install on some
> >> machine around 1998 or 1999, I didn't have a mouse plugged in, no
> >> worries, you could just move around with the keyboard.  X11 came up
> >> as part of the install, the entire install was graphical and
> >> seamless.
> > 
> > The FreeBSD installer *does* install X if you select it.
> > 
> >> FreeBSD is stuck in the 1990's in terms of user interface.
> > 
> > You're still talking about the installer, aren't you?  The normal user
> > interface is via the shell, which hasn't changed, and for a good
> > reason.
> > 
> >> They've done some good stuff in the kernel but it's not an end user
> >> system,
> > 
> > There I have to agree with you.  A little TLC would go a long way.
> > But I hope that you're not advocating the "change your GUI with your
> > underwear" attitude that Microsoft, Apple and many Linux distros
> > have.  One of the reasons I don't use Linux is because every time I
> > try, the interface has changed.
> > 
> > Greg
> > --
> > Sent from my desktop computer.
> > Finger grog@lemis.com for PGP public key.
> > See complete headers for address and phone numbers.
> > This message is digitally signed.  If your Microsoft mail program
> > reports problems, please read http://lemis.com/broken-MUA

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [TUHS] FreeBSD behind the times? (was: Favorite unix design principles?)
  2021-01-31  2:25                       ` Larry McVoy
@ 2021-01-31  2:52                         ` Will Senn
  2021-01-31  3:00                           ` Larry McVoy
  2021-02-04  5:43                         ` Dave Horsfall
                                           ` (2 subsequent siblings)
  3 siblings, 1 reply; 70+ messages in thread
From: Will Senn @ 2021-01-31  2:52 UTC (permalink / raw)
  To: Larry McVoy; +Cc: The Eunuchs Hysterical Society

Ha. Zfs may not be the be all and end all, but like I said, it’s never failed me. Whereas extX and btrfs, and, and, and have many times. Please don’t denigrate my knowledge, as so far as I know, we’ve never met, and nothing I said warrants such. The installer reminds me of Redhat’s old anaconda installer, I’ll grant you it’s dated. However, I typically install a new linux distro every week and there are many, many installers that are far more confusing - Open Suse and Fedora are two that come to mind, Debian as well. I would hazard to guess your favorite Linux is based on a distro that lacks a decent installer (Ubuntu and Mint are Debian based). 

Will

Sent from my iPhone

> On Jan 30, 2021, at 8:25 PM, Larry McVoy <lm@mcvoy.com> wrote:
> 
> If you like ZFS you don't understand operating systems design.  I do.
> Jeff Bonwick was a stats student at Stanford when he took my OS class,
> I convinced him to come to Sun.  Bill Moore worked for me.  That's the two
> main ZFS guys and I thought I had taught them well but they let me down.
> 
> ZFS doesn't use the page cache, they said it was too hard because ZFS
> is compressed.  A typical file system just has block numbers, a compressed
> one needs another int per block, it's the int that says these many bytes
> are a block uncompressed.  It's not that hard, it is 2 ints instead of 1.
> 
> In case I'm not being clear, the page cache is what everyone else uses
> but ZFS has its own cache.  So if you want to mmap() a ZFS file, ZFS
> has to bcopy() the data into the page cache and then spend a shit ton
> of code to make sure that the page cache data is in sync with the ZFS
> cache data.
> 
> SunOS came from BSD but SunOS added mmap.  Which had the same problem,
> the BSD buffer cache was exactly the same as the ZFS cache, Sun spent 
> years of effort to get rid of the buffer cache, everything is in the 
> page cache.  So ZFS was a HUGE step backwards in systems design.  Might
> be the best file system ever (it is not) but it was not a good player
> in the OS world.
> 
> Those guys said that it was too hard to make a compressed file fit in
> the page cache.  BitKeeper has that code and proves that it can be done.
> Be happy to walk anyone who cares through that code, I didn't write that,
> Wayne Scott did, but it's some of the best written code I've ever seen.
> Up there with Mojo's work on the SunOS VM system.  (I'll bet that noone
> takes me up on this offer, people love to argue but most don't want to
> learn.  Prove me wrong, please).
> 
> So good on you that you like ZFS and FreeBSD.  I don't and I don't for
> really good reasons.
> 
> Let's try it this way.  Get back to me when you can show me 40 people 
> who have installed FreeBSD on their own, with no help.  In the same 
> time, I can show you 40,000 people who have installed Linux on their
> own, with no help.  Probably 400,000.
> 
> Technology is great, ease of use is what gets you users.  ZFS is
> great but doesn't play nice with the OS.
> 
> That's my oh brother.
> 
>> On Sat, Jan 30, 2021 at 07:47:41PM -0600, Will Senn wrote:
>> Oh brother. I use FreeBSD all the time. I prefer it for its stability and ZFS which has NEVER let me down and I???ve done my share of stupid user error. Now that Linux has ZFS, it doesn???t seem as stuck in the dark ages, but uptime on my fbsd instance is 10x any of my Linux instances. We are soooo off topic, I think :). But, I???m always up for talking up FBSD. I use it in my classes, too and the system is much more coherent for my systems programming classes than linux.
>> 
>> Will
>> 
>> Sent from my iPhone
>> 
>>>> On Jan 30, 2021, at 5:11 PM, Greg 'groggy' Lehey <grog@lemis.com> wrote:
>>>> 
>>>>> On Saturday, 30 January 2021 at 14:28:54 -0800, Larry McVoy wrote:
>>>>> On Sat, Jan 30, 2021 at 04:28:26PM -0500, Clem Cole wrote:
>>>>> If I could get the day-2-day
>>>>> applications that I need to work on FreeBSD, I suspect I would be there in
>>>>> a heartbeat.
>>>> 
>>>> I dunno about that.  I tried out FreeBSD a couple of years ago when
>>>> Netflix was flirting with me.  The installer hasn't seen any loving in
>>>> 30 years it would seem.  The disk setup tool sucks just as bad as it
>>>> did back in 1988.
>>> 
>>> You could be right there, for some value of 1988 (FreeBSD came into
>>> being in 1992).  The tools work without being good.  But how often do
>>> you use them?  I've been using FreeBSD since the beginning, and I
>>> can't recall when I last used the disk partitioning tool, though I'm
>>> sure that when I did I overrode a lot of (all?) the suggestions.
>>> 
>>>> I remember when Linux was this bad in the .90ish releases.  A long
>>>> time ago.  Now their install is painless, it's every bit as good as
>>>> Windows and maybe better.
>>> 
>>> FWIW, I find Microsoft "Windows" installation terminally confusing
>>> (that's what you were talking about, right?).  And I've run into
>>> serious problems with various Linux installations too.  That doesn't
>>> make the FreeBSD tools better, but maybe it relativizes it.
>>> 
>>>> And it got that way fast, I remember doing an install on some
>>>> machine around 1998 or 1999, I didn't have a mouse plugged in, no
>>>> worries, you could just move around with the keyboard.  X11 came up
>>>> as part of the install, the entire install was graphical and
>>>> seamless.
>>> 
>>> The FreeBSD installer *does* install X if you select it.
>>> 
>>>> FreeBSD is stuck in the 1990's in terms of user interface.
>>> 
>>> You're still talking about the installer, aren't you?  The normal user
>>> interface is via the shell, which hasn't changed, and for a good
>>> reason.
>>> 
>>>> They've done some good stuff in the kernel but it's not an end user
>>>> system,
>>> 
>>> There I have to agree with you.  A little TLC would go a long way.
>>> But I hope that you're not advocating the "change your GUI with your
>>> underwear" attitude that Microsoft, Apple and many Linux distros
>>> have.  One of the reasons I don't use Linux is because every time I
>>> try, the interface has changed.
>>> 
>>> Greg
>>> --
>>> Sent from my desktop computer.
>>> Finger grog@lemis.com for PGP public key.
>>> See complete headers for address and phone numbers.
>>> This message is digitally signed.  If your Microsoft mail program
>>> reports problems, please read http://lemis.com/broken-MUA
> 
> -- 
> ---
> Larry McVoy                     lm at mcvoy.com             http://www.mcvoy.com/lm 

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [TUHS] FreeBSD behind the times? (was: Favorite unix design principles?)
  2021-01-31  2:52                         ` Will Senn
@ 2021-01-31  3:00                           ` Larry McVoy
  2021-01-31  3:06                             ` Will Senn
  0 siblings, 1 reply; 70+ messages in thread
From: Larry McVoy @ 2021-01-31  3:00 UTC (permalink / raw)
  To: Will Senn; +Cc: The Eunuchs Hysterical Society

I think this has gone on along enough.  Don't want it to be personal, not
my intent.

Like I said it seems like a Linux vs FreeBSD thing.  Don't want that.
You can search the archives about Ted talking about how ext was not
all that (I'm a fan).

On Sat, Jan 30, 2021 at 08:52:09PM -0600, Will Senn wrote:
> Ha. Zfs may not be the be all and end all, but like I said, it???s never failed me. Whereas extX and btrfs, and, and, and have many times. Please don???t denigrate my knowledge, as so far as I know, we???ve never met, and nothing I said warrants such. The installer reminds me of Redhat???s old anaconda installer, I???ll grant you it???s dated. However, I typically install a new linux distro every week and there are many, many installers that are far more confusing - Open Suse and Fedora are two that come to mind, Debian as well. I would hazard to guess your favorite Linux is based on a distro that lacks a decent installer (Ubuntu and Mint are Debian based). 
> 
> Will
> 
> Sent from my iPhone
> 
> > On Jan 30, 2021, at 8:25 PM, Larry McVoy <lm@mcvoy.com> wrote:
> > 
> > If you like ZFS you don't understand operating systems design.  I do.
> > Jeff Bonwick was a stats student at Stanford when he took my OS class,
> > I convinced him to come to Sun.  Bill Moore worked for me.  That's the two
> > main ZFS guys and I thought I had taught them well but they let me down.
> > 
> > ZFS doesn't use the page cache, they said it was too hard because ZFS
> > is compressed.  A typical file system just has block numbers, a compressed
> > one needs another int per block, it's the int that says these many bytes
> > are a block uncompressed.  It's not that hard, it is 2 ints instead of 1.
> > 
> > In case I'm not being clear, the page cache is what everyone else uses
> > but ZFS has its own cache.  So if you want to mmap() a ZFS file, ZFS
> > has to bcopy() the data into the page cache and then spend a shit ton
> > of code to make sure that the page cache data is in sync with the ZFS
> > cache data.
> > 
> > SunOS came from BSD but SunOS added mmap.  Which had the same problem,
> > the BSD buffer cache was exactly the same as the ZFS cache, Sun spent 
> > years of effort to get rid of the buffer cache, everything is in the 
> > page cache.  So ZFS was a HUGE step backwards in systems design.  Might
> > be the best file system ever (it is not) but it was not a good player
> > in the OS world.
> > 
> > Those guys said that it was too hard to make a compressed file fit in
> > the page cache.  BitKeeper has that code and proves that it can be done.
> > Be happy to walk anyone who cares through that code, I didn't write that,
> > Wayne Scott did, but it's some of the best written code I've ever seen.
> > Up there with Mojo's work on the SunOS VM system.  (I'll bet that noone
> > takes me up on this offer, people love to argue but most don't want to
> > learn.  Prove me wrong, please).
> > 
> > So good on you that you like ZFS and FreeBSD.  I don't and I don't for
> > really good reasons.
> > 
> > Let's try it this way.  Get back to me when you can show me 40 people 
> > who have installed FreeBSD on their own, with no help.  In the same 
> > time, I can show you 40,000 people who have installed Linux on their
> > own, with no help.  Probably 400,000.
> > 
> > Technology is great, ease of use is what gets you users.  ZFS is
> > great but doesn't play nice with the OS.
> > 
> > That's my oh brother.
> > 
> >> On Sat, Jan 30, 2021 at 07:47:41PM -0600, Will Senn wrote:
> >> Oh brother. I use FreeBSD all the time. I prefer it for its stability and ZFS which has NEVER let me down and I???ve done my share of stupid user error. Now that Linux has ZFS, it doesn???t seem as stuck in the dark ages, but uptime on my fbsd instance is 10x any of my Linux instances. We are soooo off topic, I think :). But, I???m always up for talking up FBSD. I use it in my classes, too and the system is much more coherent for my systems programming classes than linux.
> >> 
> >> Will
> >> 
> >> Sent from my iPhone
> >> 
> >>>> On Jan 30, 2021, at 5:11 PM, Greg 'groggy' Lehey <grog@lemis.com> wrote:
> >>>> 
> >>>>> On Saturday, 30 January 2021 at 14:28:54 -0800, Larry McVoy wrote:
> >>>>> On Sat, Jan 30, 2021 at 04:28:26PM -0500, Clem Cole wrote:
> >>>>> If I could get the day-2-day
> >>>>> applications that I need to work on FreeBSD, I suspect I would be there in
> >>>>> a heartbeat.
> >>>> 
> >>>> I dunno about that.  I tried out FreeBSD a couple of years ago when
> >>>> Netflix was flirting with me.  The installer hasn't seen any loving in
> >>>> 30 years it would seem.  The disk setup tool sucks just as bad as it
> >>>> did back in 1988.
> >>> 
> >>> You could be right there, for some value of 1988 (FreeBSD came into
> >>> being in 1992).  The tools work without being good.  But how often do
> >>> you use them?  I've been using FreeBSD since the beginning, and I
> >>> can't recall when I last used the disk partitioning tool, though I'm
> >>> sure that when I did I overrode a lot of (all?) the suggestions.
> >>> 
> >>>> I remember when Linux was this bad in the .90ish releases.  A long
> >>>> time ago.  Now their install is painless, it's every bit as good as
> >>>> Windows and maybe better.
> >>> 
> >>> FWIW, I find Microsoft "Windows" installation terminally confusing
> >>> (that's what you were talking about, right?).  And I've run into
> >>> serious problems with various Linux installations too.  That doesn't
> >>> make the FreeBSD tools better, but maybe it relativizes it.
> >>> 
> >>>> And it got that way fast, I remember doing an install on some
> >>>> machine around 1998 or 1999, I didn't have a mouse plugged in, no
> >>>> worries, you could just move around with the keyboard.  X11 came up
> >>>> as part of the install, the entire install was graphical and
> >>>> seamless.
> >>> 
> >>> The FreeBSD installer *does* install X if you select it.
> >>> 
> >>>> FreeBSD is stuck in the 1990's in terms of user interface.
> >>> 
> >>> You're still talking about the installer, aren't you?  The normal user
> >>> interface is via the shell, which hasn't changed, and for a good
> >>> reason.
> >>> 
> >>>> They've done some good stuff in the kernel but it's not an end user
> >>>> system,
> >>> 
> >>> There I have to agree with you.  A little TLC would go a long way.
> >>> But I hope that you're not advocating the "change your GUI with your
> >>> underwear" attitude that Microsoft, Apple and many Linux distros
> >>> have.  One of the reasons I don't use Linux is because every time I
> >>> try, the interface has changed.
> >>> 
> >>> Greg
> >>> --
> >>> Sent from my desktop computer.
> >>> Finger grog@lemis.com for PGP public key.
> >>> See complete headers for address and phone numbers.
> >>> This message is digitally signed.  If your Microsoft mail program
> >>> reports problems, please read http://lemis.com/broken-MUA
> > 
> > -- 
> > ---
> > Larry McVoy                     lm at mcvoy.com             http://www.mcvoy.com/lm 

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [TUHS] FreeBSD behind the times? (was: Favorite unix design principles?)
  2021-01-31  3:00                           ` Larry McVoy
@ 2021-01-31  3:06                             ` Will Senn
  2021-01-31  3:32                               ` John Cowan
  0 siblings, 1 reply; 70+ messages in thread
From: Will Senn @ 2021-01-31  3:06 UTC (permalink / raw)
  To: Larry McVoy; +Cc: The Eunuchs Hysterical Society

No worries. Maybe it’s time for a vi emacs discussion... totally kidding :)

Sent from my iPhone

> On Jan 30, 2021, at 9:00 PM, Larry McVoy <lm@mcvoy.com> wrote:
> 
> I think this has gone on along enough.  Don't want it to be personal, not
> my intent.
> 
> Like I said it seems like a Linux vs FreeBSD thing.  Don't want that.
> You can search the archives about Ted talking about how ext was not
> all that (I'm a fan).
> 
>> On Sat, Jan 30, 2021 at 08:52:09PM -0600, Will Senn wrote:
>> Ha. Zfs may not be the be all and end all, but like I said, it???s never failed me. Whereas extX and btrfs, and, and, and have many times. Please don???t denigrate my knowledge, as so far as I know, we???ve never met, and nothing I said warrants such. The installer reminds me of Redhat???s old anaconda installer, I???ll grant you it???s dated. However, I typically install a new linux distro every week and there are many, many installers that are far more confusing - Open Suse and Fedora are two that come to mind, Debian as well. I would hazard to guess your favorite Linux is based on a distro that lacks a decent installer (Ubuntu and Mint are Debian based). 
>> 
>> Will
>> 
>> Sent from my iPhone
>> 
>>> On Jan 30, 2021, at 8:25 PM, Larry McVoy <lm@mcvoy.com> wrote:
>>> 
>>> If you like ZFS you don't understand operating systems design.  I do.
>>> Jeff Bonwick was a stats student at Stanford when he took my OS class,
>>> I convinced him to come to Sun.  Bill Moore worked for me.  That's the two
>>> main ZFS guys and I thought I had taught them well but they let me down.
>>> 
>>> ZFS doesn't use the page cache, they said it was too hard because ZFS
>>> is compressed.  A typical file system just has block numbers, a compressed
>>> one needs another int per block, it's the int that says these many bytes
>>> are a block uncompressed.  It's not that hard, it is 2 ints instead of 1.
>>> 
>>> In case I'm not being clear, the page cache is what everyone else uses
>>> but ZFS has its own cache.  So if you want to mmap() a ZFS file, ZFS
>>> has to bcopy() the data into the page cache and then spend a shit ton
>>> of code to make sure that the page cache data is in sync with the ZFS
>>> cache data.
>>> 
>>> SunOS came from BSD but SunOS added mmap.  Which had the same problem,
>>> the BSD buffer cache was exactly the same as the ZFS cache, Sun spent 
>>> years of effort to get rid of the buffer cache, everything is in the 
>>> page cache.  So ZFS was a HUGE step backwards in systems design.  Might
>>> be the best file system ever (it is not) but it was not a good player
>>> in the OS world.
>>> 
>>> Those guys said that it was too hard to make a compressed file fit in
>>> the page cache.  BitKeeper has that code and proves that it can be done.
>>> Be happy to walk anyone who cares through that code, I didn't write that,
>>> Wayne Scott did, but it's some of the best written code I've ever seen.
>>> Up there with Mojo's work on the SunOS VM system.  (I'll bet that noone
>>> takes me up on this offer, people love to argue but most don't want to
>>> learn.  Prove me wrong, please).
>>> 
>>> So good on you that you like ZFS and FreeBSD.  I don't and I don't for
>>> really good reasons.
>>> 
>>> Let's try it this way.  Get back to me when you can show me 40 people 
>>> who have installed FreeBSD on their own, with no help.  In the same 
>>> time, I can show you 40,000 people who have installed Linux on their
>>> own, with no help.  Probably 400,000.
>>> 
>>> Technology is great, ease of use is what gets you users.  ZFS is
>>> great but doesn't play nice with the OS.
>>> 
>>> That's my oh brother.
>>> 
>>>> On Sat, Jan 30, 2021 at 07:47:41PM -0600, Will Senn wrote:
>>>> Oh brother. I use FreeBSD all the time. I prefer it for its stability and ZFS which has NEVER let me down and I???ve done my share of stupid user error. Now that Linux has ZFS, it doesn???t seem as stuck in the dark ages, but uptime on my fbsd instance is 10x any of my Linux instances. We are soooo off topic, I think :). But, I???m always up for talking up FBSD. I use it in my classes, too and the system is much more coherent for my systems programming classes than linux.
>>>> 
>>>> Will
>>>> 
>>>> Sent from my iPhone
>>>> 
>>>>>>> On Jan 30, 2021, at 5:11 PM, Greg 'groggy' Lehey <grog@lemis.com> wrote:
>>>>>>> 
>>>>>>> On Saturday, 30 January 2021 at 14:28:54 -0800, Larry McVoy wrote:
>>>>>>> On Sat, Jan 30, 2021 at 04:28:26PM -0500, Clem Cole wrote:
>>>>>>> If I could get the day-2-day
>>>>>>> applications that I need to work on FreeBSD, I suspect I would be there in
>>>>>>> a heartbeat.
>>>>>> 
>>>>>> I dunno about that.  I tried out FreeBSD a couple of years ago when
>>>>>> Netflix was flirting with me.  The installer hasn't seen any loving in
>>>>>> 30 years it would seem.  The disk setup tool sucks just as bad as it
>>>>>> did back in 1988.
>>>>> 
>>>>> You could be right there, for some value of 1988 (FreeBSD came into
>>>>> being in 1992).  The tools work without being good.  But how often do
>>>>> you use them?  I've been using FreeBSD since the beginning, and I
>>>>> can't recall when I last used the disk partitioning tool, though I'm
>>>>> sure that when I did I overrode a lot of (all?) the suggestions.
>>>>> 
>>>>>> I remember when Linux was this bad in the .90ish releases.  A long
>>>>>> time ago.  Now their install is painless, it's every bit as good as
>>>>>> Windows and maybe better.
>>>>> 
>>>>> FWIW, I find Microsoft "Windows" installation terminally confusing
>>>>> (that's what you were talking about, right?).  And I've run into
>>>>> serious problems with various Linux installations too.  That doesn't
>>>>> make the FreeBSD tools better, but maybe it relativizes it.
>>>>> 
>>>>>> And it got that way fast, I remember doing an install on some
>>>>>> machine around 1998 or 1999, I didn't have a mouse plugged in, no
>>>>>> worries, you could just move around with the keyboard.  X11 came up
>>>>>> as part of the install, the entire install was graphical and
>>>>>> seamless.
>>>>> 
>>>>> The FreeBSD installer *does* install X if you select it.
>>>>> 
>>>>>> FreeBSD is stuck in the 1990's in terms of user interface.
>>>>> 
>>>>> You're still talking about the installer, aren't you?  The normal user
>>>>> interface is via the shell, which hasn't changed, and for a good
>>>>> reason.
>>>>> 
>>>>>> They've done some good stuff in the kernel but it's not an end user
>>>>>> system,
>>>>> 
>>>>> There I have to agree with you.  A little TLC would go a long way.
>>>>> But I hope that you're not advocating the "change your GUI with your
>>>>> underwear" attitude that Microsoft, Apple and many Linux distros
>>>>> have.  One of the reasons I don't use Linux is because every time I
>>>>> try, the interface has changed.
>>>>> 
>>>>> Greg
>>>>> --
>>>>> Sent from my desktop computer.
>>>>> Finger grog@lemis.com for PGP public key.
>>>>> See complete headers for address and phone numbers.
>>>>> This message is digitally signed.  If your Microsoft mail program
>>>>> reports problems, please read http://lemis.com/broken-MUA
>>> 
>>> -- 
>>> ---
>>> Larry McVoy                     lm at mcvoy.com             http://www.mcvoy.com/lm 
> 
> -- 
> ---
> Larry McVoy                     lm at mcvoy.com             http://www.mcvoy.com/lm 

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [TUHS] FreeBSD behind the times? (was: Favorite unix design principles?)
  2021-01-31  3:06                             ` Will Senn
@ 2021-01-31  3:32                               ` John Cowan
  0 siblings, 0 replies; 70+ messages in thread
From: John Cowan @ 2021-01-31  3:32 UTC (permalink / raw)
  To: Will Senn; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 7985 bytes --]

Since, I am an ex(1) troglodyte, I'll be happy to umpire.  (I know ed(1) is
the standard editor, but I'm willing to trade a little standardosity for
more convenience.)

On Sat, Jan 30, 2021 at 10:06 PM Will Senn <will.senn@gmail.com> wrote:

> No worries. Maybe it’s time for a vi emacs discussion... totally kidding :)
>
> Sent from my iPhone
>
> > On Jan 30, 2021, at 9:00 PM, Larry McVoy <lm@mcvoy.com> wrote:
> >
> > I think this has gone on along enough.  Don't want it to be personal, not
> > my intent.
> >
> > Like I said it seems like a Linux vs FreeBSD thing.  Don't want that.
> > You can search the archives about Ted talking about how ext was not
> > all that (I'm a fan).
> >
> >> On Sat, Jan 30, 2021 at 08:52:09PM -0600, Will Senn wrote:
> >> Ha. Zfs may not be the be all and end all, but like I said, it???s
> never failed me. Whereas extX and btrfs, and, and, and have many times.
> Please don???t denigrate my knowledge, as so far as I know, we???ve never
> met, and nothing I said warrants such. The installer reminds me of
> Redhat???s old anaconda installer, I???ll grant you it???s dated. However,
> I typically install a new linux distro every week and there are many, many
> installers that are far more confusing - Open Suse and Fedora are two that
> come to mind, Debian as well. I would hazard to guess your favorite Linux
> is based on a distro that lacks a decent installer (Ubuntu and Mint are
> Debian based).
> >>
> >> Will
> >>
> >> Sent from my iPhone
> >>
> >>> On Jan 30, 2021, at 8:25 PM, Larry McVoy <lm@mcvoy.com> wrote:
> >>>
> >>> If you like ZFS you don't understand operating systems design.  I do.
> >>> Jeff Bonwick was a stats student at Stanford when he took my OS class,
> >>> I convinced him to come to Sun.  Bill Moore worked for me.  That's the
> two
> >>> main ZFS guys and I thought I had taught them well but they let me
> down.
> >>>
> >>> ZFS doesn't use the page cache, they said it was too hard because ZFS
> >>> is compressed.  A typical file system just has block numbers, a
> compressed
> >>> one needs another int per block, it's the int that says these many
> bytes
> >>> are a block uncompressed.  It's not that hard, it is 2 ints instead of
> 1.
> >>>
> >>> In case I'm not being clear, the page cache is what everyone else uses
> >>> but ZFS has its own cache.  So if you want to mmap() a ZFS file, ZFS
> >>> has to bcopy() the data into the page cache and then spend a shit ton
> >>> of code to make sure that the page cache data is in sync with the ZFS
> >>> cache data.
> >>>
> >>> SunOS came from BSD but SunOS added mmap.  Which had the same problem,
> >>> the BSD buffer cache was exactly the same as the ZFS cache, Sun spent
> >>> years of effort to get rid of the buffer cache, everything is in the
> >>> page cache.  So ZFS was a HUGE step backwards in systems design.  Might
> >>> be the best file system ever (it is not) but it was not a good player
> >>> in the OS world.
> >>>
> >>> Those guys said that it was too hard to make a compressed file fit in
> >>> the page cache.  BitKeeper has that code and proves that it can be
> done.
> >>> Be happy to walk anyone who cares through that code, I didn't write
> that,
> >>> Wayne Scott did, but it's some of the best written code I've ever seen.
> >>> Up there with Mojo's work on the SunOS VM system.  (I'll bet that noone
> >>> takes me up on this offer, people love to argue but most don't want to
> >>> learn.  Prove me wrong, please).
> >>>
> >>> So good on you that you like ZFS and FreeBSD.  I don't and I don't for
> >>> really good reasons.
> >>>
> >>> Let's try it this way.  Get back to me when you can show me 40 people
> >>> who have installed FreeBSD on their own, with no help.  In the same
> >>> time, I can show you 40,000 people who have installed Linux on their
> >>> own, with no help.  Probably 400,000.
> >>>
> >>> Technology is great, ease of use is what gets you users.  ZFS is
> >>> great but doesn't play nice with the OS.
> >>>
> >>> That's my oh brother.
> >>>
> >>>> On Sat, Jan 30, 2021 at 07:47:41PM -0600, Will Senn wrote:
> >>>> Oh brother. I use FreeBSD all the time. I prefer it for its stability
> and ZFS which has NEVER let me down and I???ve done my share of stupid user
> error. Now that Linux has ZFS, it doesn???t seem as stuck in the dark ages,
> but uptime on my fbsd instance is 10x any of my Linux instances. We are
> soooo off topic, I think :). But, I???m always up for talking up FBSD. I
> use it in my classes, too and the system is much more coherent for my
> systems programming classes than linux.
> >>>>
> >>>> Will
> >>>>
> >>>> Sent from my iPhone
> >>>>
> >>>>>>> On Jan 30, 2021, at 5:11 PM, Greg 'groggy' Lehey <grog@lemis.com>
> wrote:
> >>>>>>>
> >>>>>>> On Saturday, 30 January 2021 at 14:28:54 -0800, Larry McVoy wrote:
> >>>>>>> On Sat, Jan 30, 2021 at 04:28:26PM -0500, Clem Cole wrote:
> >>>>>>> If I could get the day-2-day
> >>>>>>> applications that I need to work on FreeBSD, I suspect I would be
> there in
> >>>>>>> a heartbeat.
> >>>>>>
> >>>>>> I dunno about that.  I tried out FreeBSD a couple of years ago when
> >>>>>> Netflix was flirting with me.  The installer hasn't seen any loving
> in
> >>>>>> 30 years it would seem.  The disk setup tool sucks just as bad as it
> >>>>>> did back in 1988.
> >>>>>
> >>>>> You could be right there, for some value of 1988 (FreeBSD came into
> >>>>> being in 1992).  The tools work without being good.  But how often do
> >>>>> you use them?  I've been using FreeBSD since the beginning, and I
> >>>>> can't recall when I last used the disk partitioning tool, though I'm
> >>>>> sure that when I did I overrode a lot of (all?) the suggestions.
> >>>>>
> >>>>>> I remember when Linux was this bad in the .90ish releases.  A long
> >>>>>> time ago.  Now their install is painless, it's every bit as good as
> >>>>>> Windows and maybe better.
> >>>>>
> >>>>> FWIW, I find Microsoft "Windows" installation terminally confusing
> >>>>> (that's what you were talking about, right?).  And I've run into
> >>>>> serious problems with various Linux installations too.  That doesn't
> >>>>> make the FreeBSD tools better, but maybe it relativizes it.
> >>>>>
> >>>>>> And it got that way fast, I remember doing an install on some
> >>>>>> machine around 1998 or 1999, I didn't have a mouse plugged in, no
> >>>>>> worries, you could just move around with the keyboard.  X11 came up
> >>>>>> as part of the install, the entire install was graphical and
> >>>>>> seamless.
> >>>>>
> >>>>> The FreeBSD installer *does* install X if you select it.
> >>>>>
> >>>>>> FreeBSD is stuck in the 1990's in terms of user interface.
> >>>>>
> >>>>> You're still talking about the installer, aren't you?  The normal
> user
> >>>>> interface is via the shell, which hasn't changed, and for a good
> >>>>> reason.
> >>>>>
> >>>>>> They've done some good stuff in the kernel but it's not an end user
> >>>>>> system,
> >>>>>
> >>>>> There I have to agree with you.  A little TLC would go a long way.
> >>>>> But I hope that you're not advocating the "change your GUI with your
> >>>>> underwear" attitude that Microsoft, Apple and many Linux distros
> >>>>> have.  One of the reasons I don't use Linux is because every time I
> >>>>> try, the interface has changed.
> >>>>>
> >>>>> Greg
> >>>>> --
> >>>>> Sent from my desktop computer.
> >>>>> Finger grog@lemis.com for PGP public key.
> >>>>> See complete headers for address and phone numbers.
> >>>>> This message is digitally signed.  If your Microsoft mail program
> >>>>> reports problems, please read http://lemis.com/broken-MUA
> >>>
> >>> --
> >>> ---
> >>> Larry McVoy                     lm at mcvoy.com
> http://www.mcvoy.com/lm
> >
> > --
> > ---
> > Larry McVoy                     lm at mcvoy.com
> http://www.mcvoy.com/lm
>

[-- Attachment #2: Type: text/html, Size: 11005 bytes --]

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [TUHS] [SPAM] Re: FreeBSD behind the times?
  2021-01-30 23:54                             ` Larry McVoy
@ 2021-01-31 12:23                               ` Dermot Tynan
  0 siblings, 0 replies; 70+ messages in thread
From: Dermot Tynan @ 2021-01-31 12:23 UTC (permalink / raw)
  To: tuhs

On 30/01/2021 23:54, Larry McVoy wrote:
> You like FreeBSD, cool, it's fine. Nobody will ever know because nobody
> is going to put up with a 1990's era installer.  Nobody.  It's 2020, shit
> is just supposed to work, it's supposed do so in a graphical environment
> let works with or without a mouse.  Anyone who doesn't see that isn't
> going to get any market share.

It's "horses for courses". I run a mix of FreeBSD and Linux servers. As 
they're headless, the last thing I want is X on there. Ideally, I'd 
strip out the automount crap as well, to say nothing of the horror that 
is systemd. But yeah, those people with desktops want a simple GUI 
install and they want their USB stick to appear as a "folder". I run 
Ubuntu on my desktop for vaguely those reasons (and Dropbox!).

I think the biggest threat to FreeBSD is docker/k8s and things like 
libvirt. Unfortunately, most open source (and closed source) software 
runs de facto on Linux (if it runs on Unix-esque systems), and the ports 
to FreeBSD are slow in coming. Last time I looked, there was no native 
Dropbox client.

As a server though, if you don't need to use it as a hypervisor or a 
container system, it gets my vote. But again it's down to preference. 
Linux has the breeze now, and is streaking ahead of the *BSDs. Sad, but 
true.
                         - Der

-- 
Dermot Tynan
dtynan@kalopa.com


^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [TUHS] FreeBSD behind the times? (was: Favorite unix design principles?)
  2021-01-31  2:25                       ` Larry McVoy
  2021-01-31  2:52                         ` Will Senn
@ 2021-02-04  5:43                         ` Dave Horsfall
  2021-02-04  6:10                           ` Angus Robinson
  2021-02-04 15:45                           ` Will Senn
  2021-02-04  7:46                         ` Chris Torek
  2021-02-11 21:01                         ` Angel M Alganza
  3 siblings, 2 replies; 70+ messages in thread
From: Dave Horsfall @ 2021-02-04  5:43 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

On Sat, 30 Jan 2021, Larry McVoy wrote:

[ Usual insightful...  insights ]

> If you like ZFS you don't understand operating systems design.  I do.

Indeed...

> Jeff Bonwick was a stats student at Stanford when he took my OS class, I 
> convinced him to come to Sun.  Bill Moore worked for me.  That's the two 
> main ZFS guys and I thought I had taught them well but they let me down.

{ ... ]

There's no way that I'd use ZFS; lose a block in an ordinary file, well, 
you now have a hole (but not in the file-system sense); lose a block in a 
compressed system, well...

Or perhaps I'm becoming conservative in my old age; I remember when I once 
rewrote utilities that when writing a zero block merely did a seek instead 
(or something like that; you had to remember to actually write out the 
last block).  I wouldn't try it these days, as Unix file systems were 
simple back then.

[ ... ]

> Let's try it this way.  Get back to me when you can show me 40 people 
> who have installed FreeBSD on their own, with no help.  In the same 
> time, I can show you 40,000 people who have installed Linux on their 
> own, with no help.  Probably 400,000.

Well, I did (but without ZFS) on several boxes, with zero help.  Having
had SunOS experience (4.4 was the best) helped :-)

I can't stand Penguin/OS; it looks too much like Windoze for my liking
(and does its best to be almost-Unix-but-not-quite).

-- Dave, a grey-beard

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [TUHS] FreeBSD behind the times? (was: Favorite unix design principles?)
  2021-02-04  5:43                         ` Dave Horsfall
@ 2021-02-04  6:10                           ` Angus Robinson
  2021-02-04  7:46                             ` Andy Kosela
  2021-02-04 22:25                             ` Dave Horsfall
  2021-02-04 15:45                           ` Will Senn
  1 sibling, 2 replies; 70+ messages in thread
From: Angus Robinson @ 2021-02-04  6:10 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 1946 bytes --]

Not entirely sure as it's been a while since iI have used it but last time
I remember TrueOS which used FreeBSD was easy to use for a newbie. There
are other FreeBSD distro's like GhostBSD,etc that have an installer like
Linux.

My 2c is that FreeBSD is not trying to get people in that are newbies, it's
for the server environment and it works extremely well.

Kind Regards,
Angus Robinson


On Thu, Feb 4, 2021 at 7:45 AM Dave Horsfall <dave@horsfall.org> wrote:

> On Sat, 30 Jan 2021, Larry McVoy wrote:
>
> [ Usual insightful...  insights ]
>
> > If you like ZFS you don't understand operating systems design.  I do.
>
> Indeed...
>
> > Jeff Bonwick was a stats student at Stanford when he took my OS class, I
> > convinced him to come to Sun.  Bill Moore worked for me.  That's the two
> > main ZFS guys and I thought I had taught them well but they let me down.
>
> { ... ]
>
> There's no way that I'd use ZFS; lose a block in an ordinary file, well,
> you now have a hole (but not in the file-system sense); lose a block in a
> compressed system, well...
>
> Or perhaps I'm becoming conservative in my old age; I remember when I once
> rewrote utilities that when writing a zero block merely did a seek instead
> (or something like that; you had to remember to actually write out the
> last block).  I wouldn't try it these days, as Unix file systems were
> simple back then.
>
> [ ... ]
>
> > Let's try it this way.  Get back to me when you can show me 40 people
> > who have installed FreeBSD on their own, with no help.  In the same
> > time, I can show you 40,000 people who have installed Linux on their
> > own, with no help.  Probably 400,000.
>
> Well, I did (but without ZFS) on several boxes, with zero help.  Having
> had SunOS experience (4.4 was the best) helped :-)
>
> I can't stand Penguin/OS; it looks too much like Windoze for my liking
> (and does its best to be almost-Unix-but-not-quite).
>
> -- Dave, a grey-beard
>

[-- Attachment #2: Type: text/html, Size: 2615 bytes --]

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [TUHS] FreeBSD behind the times? (was: Favorite unix design principles?)
  2021-01-31  2:25                       ` Larry McVoy
  2021-01-31  2:52                         ` Will Senn
  2021-02-04  5:43                         ` Dave Horsfall
@ 2021-02-04  7:46                         ` Chris Torek
  2021-02-04 15:47                           ` Will Senn
  2021-02-11 21:01                         ` Angel M Alganza
  3 siblings, 1 reply; 70+ messages in thread
From: Chris Torek @ 2021-02-04  7:46 UTC (permalink / raw)
  To: lm, will.senn; +Cc: tuhs

For what it's worth, you don't *have* to use compression on ZFS.
But everything still goes through the ARC, which is ... messy.
And eats memory for breakfast and then more memory for snacks and
lunch and more snacks and so on.  Fortunately memory is cheap, if
you have a modern box.  Unfortunately, I still don't, yet.

ZFS has a ton of stuff in it.  That, also, is messy, and not a
great thing in terms of kernel size and security and alacrity and
so on.  But it has some really cool ideas in it.  I'm perfectly
happy to use it, or will be once I build a new box (still haven't
made the jump to an AMD system with ECC).

Chris

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [TUHS] FreeBSD behind the times? (was: Favorite unix design principles?)
  2021-02-04  6:10                           ` Angus Robinson
@ 2021-02-04  7:46                             ` Andy Kosela
  2021-02-04 22:25                             ` Dave Horsfall
  1 sibling, 0 replies; 70+ messages in thread
From: Andy Kosela @ 2021-02-04  7:46 UTC (permalink / raw)
  To: Angus Robinson; +Cc: The Eunuchs Hysterical Society

On 2/4/21, Angus Robinson <angus@fairhaven.za.net> wrote:
>  it's for the server environment and it works extremely well.
>

Well...20 years ago it was a catchy phrase  when FreeBSD was still in
stiff competition with Linux.  Now 20 years later we all see who won
the Unix server wars.  Literally every corporate entity is using some
form of commercial Red Hat Enterprise Linux now.  It is running
everywhere.

There are some individual companies that still utilizes FreeBSD like
Netflix, but the overall majority of server systems are based on
Linux.  I am not saying it is better; I am just pointing out the
facts.  I generally despise all modern Unix: be it Linux with systemd
or FreeBSD as being too bloated and complex.  My personal opinion is
that Linux peaked around late 90s-early/mid 2000s.  It was still
pretty logical and simple, but excelled in performance.  It went
downhill since then...

--Andy

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [TUHS] FreeBSD behind the times? (was: Favorite unix design principles?)
  2021-02-04  5:43                         ` Dave Horsfall
  2021-02-04  6:10                           ` Angus Robinson
@ 2021-02-04 15:45                           ` Will Senn
  2021-02-04 16:03                             ` Henry Bent
                                               ` (2 more replies)
  1 sibling, 3 replies; 70+ messages in thread
From: Will Senn @ 2021-02-04 15:45 UTC (permalink / raw)
  To: tuhs

On 2/3/21 11:43 PM, Dave Horsfall wrote:
> On Sat, 30 Jan 2021, Larry McVoy wrote:
>
> [ Usual insightful...  insights ]
>
>> If you like ZFS you don't understand operating systems design.  I do.
> ...
>
> There's no way that I'd use ZFS; lose a block in an ordinary file, 
> well, you now have a hole (but not in the file-system sense); lose a 
> block in a compressed system, well...
>
ZFS needn't be compressed, and I don't generally do compression or 
encryption unless required by law, so I can't speak from personal 
experience on those use cases (others, far more experienced can). I do 
know that it's truly a pain to recover from issues with either.

In response to the negative vibes around ZFS. I've never lost a file (or 
a piece of a file) in 10+ years of using ZFS. I get the feeling we may 
not be talking about the same ZFS. My experience is with the ZFS FreeBSD 
comes with, not the version that Oracle owns. Perhaps the info is a 
little out of date for the naysayers. In my experience, using ZFS is 
fairly transparent and simple to use - no partitioning to deal with, no 
need to worry about generating filesystems, none of that - add your 
disks to a pool, choose your RAID levels and it gets mounted, no fuss. 
I've lost plenty of disks along the way, but ZFS just keeps on chugging 
along nicely until I replace them and then rebuilds the arrays, again, 
no fuss other than replacing the hardware. In terms of massive system 
updates and such, I just snapshot the environment (a near instantaneous 
operation) before making significant changes to my system, that might 
break things and when they do break (and they do, more often than I'd 
like), I just rollback. man bectl. Painless (and I mean painless, 
hundreds of times, or mor). I'm sure it all sounds scifi, but it's my 
experience along with plenty of other folks, and this ZFS sucks thread 
seems to be FUD to me - ala Microsoft vs Linux, or at best informed 
hypothetical speculations - reminds me of an if statement conversation I 
had online in the early 1990's where one group of folks claimed that 
braces worked a certain way, based on the then current standard, and 
another group of folks (I'd be on this side of things), tested the 
theory with a host of compilers, observed the functions effects, shook 
their heads and wondered why it didn't match up with the theory, and 
said it worked another. Who was right? I'm still not entirely sure, from 
a philosophical perspective, but I have since coded my if statements 
according to my environment, not the standards.

As I mentioned in the prior thread, I've lost my share of files and file 
systems (many, many times since 1993 when I started with linux - 0.9 
kernel, slackware, then redhat, then debian, now mint) with ext3/4, and 
btrfs, though, and the only recovery was backup (a time intensive 
process). I really don't see the logic behind the negative arguments. 
Don't like it, fine, say it and live it. Claim it sucks? Then, back it 
up with a real-world, current experience and I'll cede the point - I'll 
keep using ZFS though :).

I want to be clear, I don't dislike Linux. I don't think FreeBSD is 
superior. I like both. I use both... daily. With enough prep and 
planning, my linux environment is similarly recoverable, but with 
freebsd, the prep and planning requires a lot less time and effort. 
Personally, I heart linux Mint - it's based on Debian and Ubuntu - is a 
straightforward install, works well, has zfs (not yet on boot), has 
timeshift (lovely piece of software), and can be quite pretty.

Vive la difference.

Will





^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [TUHS] FreeBSD behind the times? (was: Favorite unix design principles?)
  2021-02-04  7:46                         ` Chris Torek
@ 2021-02-04 15:47                           ` Will Senn
  0 siblings, 0 replies; 70+ messages in thread
From: Will Senn @ 2021-02-04 15:47 UTC (permalink / raw)
  To: Chris Torek, lm; +Cc: tuhs

On 2/4/21 1:46 AM, Chris Torek wrote:
> For what it's worth, you don't *have* to use compression on ZFS.
> But everything still goes through the ARC, which is ... messy.
> And eats memory for breakfast and then more memory for snacks and
> lunch and more snacks and so on.  Fortunately memory is cheap, if
> you have a modern box.  Unfortunately, I still don't, yet.
>
> ZFS has a ton of stuff in it.  That, also, is messy, and not a
> great thing in terms of kernel size and security and alacrity and
> so on.  But it has some really cool ideas in it.  I'm perfectly
> happy to use it, or will be once I build a new box (still haven't
> made the jump to an AMD system with ECC).
>
> Chris
OMG! It's a memory hog, for sure, and messy :)

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [TUHS] FreeBSD behind the times? (was: Favorite unix design principles?)
  2021-02-04 15:45                           ` Will Senn
@ 2021-02-04 16:03                             ` Henry Bent
  2021-02-04 16:32                             ` Dan Cross
  2021-02-05 20:50                             ` Dave Horsfall
  2 siblings, 0 replies; 70+ messages in thread
From: Henry Bent @ 2021-02-04 16:03 UTC (permalink / raw)
  To: Will Senn; +Cc: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 4431 bytes --]

I don't really know enough about filesystem internals to comment on the
design one way or another.  I can say that Oberlin College Computer Science
switched to using ZFS with snapshots in 2008 or so (on Solaris 10) and it
greatly simplified restoring from backups.  Home directories had weekly
snapshots taken, rolling over a month or two, and it was a godsend when a
student (or a professor...) accidentally deleted something important.  No
more trawling through backup tapes by the admin to restore the file you
wanted, it could easily be taken from an on-disk snapshot.  Obviously it
required a certain greater amount of disk space, but I contend that it was
worth it.

-Henry

On Thu, 4 Feb 2021 at 10:47, Will Senn <will.senn@gmail.com> wrote:

> On 2/3/21 11:43 PM, Dave Horsfall wrote:
> > On Sat, 30 Jan 2021, Larry McVoy wrote:
> >
> > [ Usual insightful...  insights ]
> >
> >> If you like ZFS you don't understand operating systems design.  I do.
> > ...
> >
> > There's no way that I'd use ZFS; lose a block in an ordinary file,
> > well, you now have a hole (but not in the file-system sense); lose a
> > block in a compressed system, well...
> >
> ZFS needn't be compressed, and I don't generally do compression or
> encryption unless required by law, so I can't speak from personal
> experience on those use cases (others, far more experienced can). I do
> know that it's truly a pain to recover from issues with either.
>
> In response to the negative vibes around ZFS. I've never lost a file (or
> a piece of a file) in 10+ years of using ZFS. I get the feeling we may
> not be talking about the same ZFS. My experience is with the ZFS FreeBSD
> comes with, not the version that Oracle owns. Perhaps the info is a
> little out of date for the naysayers. In my experience, using ZFS is
> fairly transparent and simple to use - no partitioning to deal with, no
> need to worry about generating filesystems, none of that - add your
> disks to a pool, choose your RAID levels and it gets mounted, no fuss.
> I've lost plenty of disks along the way, but ZFS just keeps on chugging
> along nicely until I replace them and then rebuilds the arrays, again,
> no fuss other than replacing the hardware. In terms of massive system
> updates and such, I just snapshot the environment (a near instantaneous
> operation) before making significant changes to my system, that might
> break things and when they do break (and they do, more often than I'd
> like), I just rollback. man bectl. Painless (and I mean painless,
> hundreds of times, or mor). I'm sure it all sounds scifi, but it's my
> experience along with plenty of other folks, and this ZFS sucks thread
> seems to be FUD to me - ala Microsoft vs Linux, or at best informed
> hypothetical speculations - reminds me of an if statement conversation I
> had online in the early 1990's where one group of folks claimed that
> braces worked a certain way, based on the then current standard, and
> another group of folks (I'd be on this side of things), tested the
> theory with a host of compilers, observed the functions effects, shook
> their heads and wondered why it didn't match up with the theory, and
> said it worked another. Who was right? I'm still not entirely sure, from
> a philosophical perspective, but I have since coded my if statements
> according to my environment, not the standards.
>
> As I mentioned in the prior thread, I've lost my share of files and file
> systems (many, many times since 1993 when I started with linux - 0.9
> kernel, slackware, then redhat, then debian, now mint) with ext3/4, and
> btrfs, though, and the only recovery was backup (a time intensive
> process). I really don't see the logic behind the negative arguments.
> Don't like it, fine, say it and live it. Claim it sucks? Then, back it
> up with a real-world, current experience and I'll cede the point - I'll
> keep using ZFS though :).
>
> I want to be clear, I don't dislike Linux. I don't think FreeBSD is
> superior. I like both. I use both... daily. With enough prep and
> planning, my linux environment is similarly recoverable, but with
> freebsd, the prep and planning requires a lot less time and effort.
> Personally, I heart linux Mint - it's based on Debian and Ubuntu - is a
> straightforward install, works well, has zfs (not yet on boot), has
> timeshift (lovely piece of software), and can be quite pretty.
>
> Vive la difference.
>
> Will
>
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 5149 bytes --]

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [TUHS] FreeBSD behind the times? (was: Favorite unix design principles?)
  2021-02-04 15:45                           ` Will Senn
  2021-02-04 16:03                             ` Henry Bent
@ 2021-02-04 16:32                             ` Dan Cross
  2021-02-04 16:49                               ` Will Senn
                                                 ` (2 more replies)
  2021-02-05 20:50                             ` Dave Horsfall
  2 siblings, 3 replies; 70+ messages in thread
From: Dan Cross @ 2021-02-04 16:32 UTC (permalink / raw)
  To: Will Senn; +Cc: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 2349 bytes --]

On Thu, Feb 4, 2021 at 10:47 AM Will Senn <will.senn@gmail.com> wrote:

> [snip]
>
> In response to the negative vibes around ZFS. [snip]
>

I think the discordance is around the semantics ZFS's implementation
implies. Larry's point about mmap() vs a buffer cache is entirely valid; it
took lots of people heroic amounts of work worthy of Greek sagas to bridge
the difference between the original buffer and VM page caches, but ZFS
says, "meh. too much work; not worth it." The practical implication of that
is that memory mapped IO (via `mmap`) is no longer coherent with file IO
(via `open`/`close`/`read`/`write`) without lots of work that both degrades
performance and add complexity.

The question that a lot of folks who use ZFS regularly ask is, "does that
matter?" And perhaps it doesn't: if I've got a file server sitting there
serving NFS, do I care what it's kernel is doing? As long as it's
saturating the network and disks, and it's reliable...not really.
(Incidentally, that was kind of the philosophy behind the original plan9
file server kernel...as I heard the story, the rate of change of the plan9
kernel proper was too high, so Ken split off the file server portion into
its own, special-purpose kernel, and it stayed like that for ~20 years).
Similarly, if I'm on the local machine and the required coherence code is
there and largely works, then again, perhaps as a consumer of the
filesystem, I just don't care. After all, one can still get work done, and
ZFS has a bunch of other features that make it very attractive, right? In
particular, it's very good at NOT losing my data, kernel purity be damned.

On the other hand, if we're discussing OS design and implementation,
(re)splitting the VM and buffer caches is a poor decision. One might well
ask, "why?" and the answer may be, "because it adds significant complexity
to the kernel." This to me seems like the crux of the disagreement.
Satisfied users of ZFS might legitimately ask, "who cares?" and one might
respond, "kernel maintainers." If the kernel is mostly transparent as far
as a particular use case goes, though, then I can see why one would bulk at
the suggestion that this matters. If one is concerned with the design and
implementation of kernels, I could see why one would care very much.

Like many things, it's a matter of perspective.

        - Dan C.

[-- Attachment #2: Type: text/html, Size: 2861 bytes --]

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [TUHS] FreeBSD behind the times? (was: Favorite unix design principles?)
  2021-02-04 16:32                             ` Dan Cross
@ 2021-02-04 16:49                               ` Will Senn
  2021-02-04 17:46                               ` Larry McVoy
  2021-02-04 18:41                               ` Bakul Shah
  2 siblings, 0 replies; 70+ messages in thread
From: Will Senn @ 2021-02-04 16:49 UTC (permalink / raw)
  To: Dan Cross; +Cc: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 3160 bytes --]

On 2/4/21 10:32 AM, Dan Cross wrote:
> On Thu, Feb 4, 2021 at 10:47 AM Will Senn <will.senn@gmail.com 
> <mailto:will.senn@gmail.com>> wrote:
>
>     [snip]
>
>     In response to the negative vibes around ZFS. [snip]
>
>
> I think the discordance is around the semantics ZFS's implementation 
> implies. Larry's point about mmap() vs a buffer cache is entirely 
> valid; it took lots of people heroic amounts of work worthy of Greek 
> sagas to bridge the difference between the original buffer and VM page 
> caches, but ZFS says, "meh. too much work; not worth it." The 
> practical implication of that is that memory mapped IO (via `mmap`) is 
> no longer coherent with file IO (via `open`/`close`/`read`/`write`) 
> without lots of work that both degrades performance and add complexity.
>
> The question that a lot of folks who use ZFS regularly ask is, "does 
> that matter?" And perhaps it doesn't: if I've got a file server 
> sitting there serving NFS, do I care what it's kernel is doing? As 
> long as it's saturating the network and disks, and it's reliable...not 
> really. (Incidentally, that was kind of the philosophy behind the 
> original plan9 file server kernel...as I heard the story, the rate of 
> change of the plan9 kernel proper was too high, so Ken split off the 
> file server portion into its own, special-purpose kernel, and it 
> stayed like that for ~20 years). Similarly, if I'm on the local 
> machine and the required coherence code is there and largely works, 
> then again, perhaps as a consumer of the filesystem, I just don't 
> care. After all, one can still get work done, and ZFS has a bunch of 
> other features that make it very attractive, right? In particular, 
> it's very good at NOT losing my data, kernel purity be damned.
>
> On the other hand, if we're discussing OS design and implementation, 
> (re)splitting the VM and buffer caches is a poor decision. One might 
> well ask, "why?" and the answer may be, "because it adds significant 
> complexity to the kernel." This to me seems like the crux of the 
> disagreement. Satisfied users of ZFS might legitimately ask, "who 
> cares?" and one might respond, "kernel maintainers." If the kernel is 
> mostly transparent as far as a particular use case goes, though, then 
> I can see why one would bulk at the suggestion that this matters. If 
> one is concerned with the design and implementation of kernels, I 
> could see why one would care very much.
>
> Like many things, it's a matter of perspective.
>
>         - Dan C.
>
Thanks for the comments, Dan. I see your point. I was thinking as a 
user/admin. In this light, I'll admit that I'm not an expert on the 
internals and say that I can only imagine the breadth of design 
tradeoffs that were contemplated and the many decisions that were made 
when coming up with ZFS. I'm glad somebody thought through them, and 
worked through them, though. So I could consume their work, 
Frankensteinian though it may be. Now, if somebody would only get it 
working properly in Linux (boot environments included), or even get 
BTRFS to be more realiable, I'd be a happy camper, at least for a while :).


[-- Attachment #2: Type: text/html, Size: 4608 bytes --]

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [TUHS] FreeBSD behind the times? (was: Favorite unix design principles?)
  2021-02-04 16:32                             ` Dan Cross
  2021-02-04 16:49                               ` Will Senn
@ 2021-02-04 17:46                               ` Larry McVoy
  2021-02-04 18:41                               ` Bakul Shah
  2 siblings, 0 replies; 70+ messages in thread
From: Larry McVoy @ 2021-02-04 17:46 UTC (permalink / raw)
  To: Dan Cross; +Cc: TUHS main list

+1 to everything Dan said, including the "who cares if it works?".

I was definitely coming at it from the kernel perspective, I joined Sun
just after SunOS 4.0 came out; that was the release that made mmap/page
cache be a coherent thing, the buffer cache was almost completely gone,
I think it was still used for inodes and directories but no user data
was in there.

The amount of work that went into that was huge but the resulting kernel
was actually smaller (I think) and much easier to understand and maintain
(I know).  And the kernel team was quite proud of that work, with good
reason.

Which is why it blows my mind that the same organization that saw the
value of have one way to do things, did a 180 and said the page cache
isn't that important.  When I talked to the ZFS guys about it, their
plan was that ZFS was going to be the only local file system so it sort
of didn't matter.  But that's nonsense, you are going to have tmpfs,
nfs, vfat, ntfs, whatever apple uses, etc.  So you are going to have a
page cache for all of those, which means the page cache is never going
away, which means that mmap() wants pages (remember, you can mmap stuff
that isn't in memory, you need the hardware to fault for you so you can
go get it).  The ZFS guys said making that work is too hard, we did it
in BitKeeper, it works fine.  

So the combination of going back to something anyone with OS smarts 
knows is a bad idea plus the fact that I know from personal experience
that they could have done in the page cache and still have compression
and XOR, yeah, I lost a lot of respect for those guys.  

ZFS is very useful, it could have been that and played nice with the 
page cache.

On Thu, Feb 04, 2021 at 11:32:31AM -0500, Dan Cross wrote:
> On Thu, Feb 4, 2021 at 10:47 AM Will Senn <will.senn@gmail.com> wrote:
> 
> > [snip]
> >
> > In response to the negative vibes around ZFS. [snip]
> >
> 
> I think the discordance is around the semantics ZFS's implementation
> implies. Larry's point about mmap() vs a buffer cache is entirely valid; it
> took lots of people heroic amounts of work worthy of Greek sagas to bridge
> the difference between the original buffer and VM page caches, but ZFS
> says, "meh. too much work; not worth it." The practical implication of that
> is that memory mapped IO (via `mmap`) is no longer coherent with file IO
> (via `open`/`close`/`read`/`write`) without lots of work that both degrades
> performance and add complexity.
> 
> The question that a lot of folks who use ZFS regularly ask is, "does that
> matter?" And perhaps it doesn't: if I've got a file server sitting there
> serving NFS, do I care what it's kernel is doing? As long as it's
> saturating the network and disks, and it's reliable...not really.
> (Incidentally, that was kind of the philosophy behind the original plan9
> file server kernel...as I heard the story, the rate of change of the plan9
> kernel proper was too high, so Ken split off the file server portion into
> its own, special-purpose kernel, and it stayed like that for ~20 years).
> Similarly, if I'm on the local machine and the required coherence code is
> there and largely works, then again, perhaps as a consumer of the
> filesystem, I just don't care. After all, one can still get work done, and
> ZFS has a bunch of other features that make it very attractive, right? In
> particular, it's very good at NOT losing my data, kernel purity be damned.
> 
> On the other hand, if we're discussing OS design and implementation,
> (re)splitting the VM and buffer caches is a poor decision. One might well
> ask, "why?" and the answer may be, "because it adds significant complexity
> to the kernel." This to me seems like the crux of the disagreement.
> Satisfied users of ZFS might legitimately ask, "who cares?" and one might
> respond, "kernel maintainers." If the kernel is mostly transparent as far
> as a particular use case goes, though, then I can see why one would bulk at
> the suggestion that this matters. If one is concerned with the design and
> implementation of kernels, I could see why one would care very much.
> 
> Like many things, it's a matter of perspective.
> 
>         - Dan C.

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [TUHS] FreeBSD behind the times? (was: Favorite unix design principles?)
  2021-02-04 16:32                             ` Dan Cross
  2021-02-04 16:49                               ` Will Senn
  2021-02-04 17:46                               ` Larry McVoy
@ 2021-02-04 18:41                               ` Bakul Shah
  2021-02-04 22:28                                 ` George Michaelson
  2 siblings, 1 reply; 70+ messages in thread
From: Bakul Shah @ 2021-02-04 18:41 UTC (permalink / raw)
  To: Dan Cross; +Cc: TUHS main list

On Feb 4, 2021, at 8:34 AM, Dan Cross <crossd@gmail.com> wrote:
> 
> On the other hand, if we're discussing OS design and implementation, (re)splitting the VM and buffer caches is a poor decision. One might well ask, "why?" and the answer may be, "because it adds significant complexity to the kernel." This to me seems like the crux of the disagreement. Satisfied users of ZFS might legitimately ask, "who cares?" and one might respond, "kernel maintainers." If the kernel is mostly transparent as far as a particular use case goes, though, then I can see why one would bulk at the suggestion that this matters. If one is concerned with the design and implementation of kernels, I could see why one would care very much.

Largely agree; though the complexity battle has long been lost. On multiple fronts. Many of us are happy to use such complex systems for their ease of use or their feature set but wouldn’t want to maintain these systems!

I have used ZFS since 2005 and largely happy with it. Replaced all the disks twice. Moved the same set of disks to a new machine. etc. Features: cheap and fast snapshots, send/receive, clone, adding disks, checksummed blocks, redundancy etc. The dedup impl. is suboptimal so I don't use it. No idea if they considered using a bloom filter and a cache to reduce memory use. If a new FS came along with a similar set of features and a simpler, better integrated implementation, I'd switch.



^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [TUHS] FreeBSD behind the times? (was: Favorite unix design principles?)
  2021-02-04  6:10                           ` Angus Robinson
  2021-02-04  7:46                             ` Andy Kosela
@ 2021-02-04 22:25                             ` Dave Horsfall
  1 sibling, 0 replies; 70+ messages in thread
From: Dave Horsfall @ 2021-02-04 22:25 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 616 bytes --]

On Thu, 4 Feb 2021, Angus Robinson wrote:

> Not entirely sure as it's been a while since iI have used it but last 
> time I remember TrueOS which used FreeBSD was easy to use for a newbie. 
> There are other FreeBSD distro's like GhostBSD,etc that have an 
> installer like Linux. My 2c is that FreeBSD is not trying to get 
> people in that are newbies, it's for the server environment and it works 
> extremely well. 

Exactly; FreeBSD is not for newbies: I'll leave Penguin/OS to that market.

Mind you, OpenBSD was a bit of a bugger; all services are off by default. 
It's perfect for a firewall :-)

-- Dave

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [TUHS] FreeBSD behind the times? (was: Favorite unix design principles?)
  2021-02-04 18:41                               ` Bakul Shah
@ 2021-02-04 22:28                                 ` George Michaelson
  2021-02-04 22:41                                   ` Bakul Shah
  2021-02-05  0:33                                   ` Larry McVoy
  0 siblings, 2 replies; 70+ messages in thread
From: George Michaelson @ 2021-02-04 22:28 UTC (permalink / raw)
  To: TUHS main list

snapshots of FS state existed for years before ZFS/BTRFS did it,
because FS journaling existed. The underlying model of COW forking of
the inodes and a journal were all there.

What ZFS did, and what Docker does, and snap does, and flatpack does,
is package things in a way which make modalities for use for  modern
sysadmin "just work"

I don't recall seeing a backup model built on UFS+journalling with an
integrated command tooling to do what zfs snapshot; zfs send | zfs
receive does as an incremental copy mechanism. I'm not trying to
disrespect the prior art, if there was a good packaging, I probably
missed it. ZFS made this "yea, I get it now" for a lot of people.

I think ZFS is fine. I have adopted it wholesale in the work context
for the last 15+ years and at home for about a year. The FUD around
minimum memory for ARC is a misunderstanding of an Oracle document
"back then" and you can run ZFS on rPi class systems fine, if you can
accept some lumpy paging and VM behaviour, and if you don't enable
compression which burns the ARC. (you need the extent of memory to
deal with things a lot more) -And there are modern OpenZFS docs which
patiently explain this stuff.

Zsys is going to get better. This means rollback from systems update
under Ubuntu snaps and things, will get better. It will be a lot less
risky to do significant upgrade on systems. -Think about Android and
the two-root model of updating the passive root in the background, so
the new OS is live across a reboot without having the spinning
beachball of upgrade on your phone, or analogues of the "keep this
setting or go back" model WIndows does, and Windows has had OS
snapshots for a long time now, and offers "undo that major update"
models to users: people expect this.

I also think ZFS was a godsend for getting over the smart RAID card
mistakes of the past. I HAVE lost data with these puppies. I've moved
multi TB fs between FreeBSD and Linux and back again (with care) under
ZFS, and you can't do that with Apples FS, or EXT3 with anything like
the same confidence.

Really? I like UUID. UUID are a godsend, for making things have
unique,  but asynchronously generated identity, so when you move them
and mix them, you can stop worrying about device/bus order and simply
re-create them as they were defined semantically. ZFS does this too:
zfs import is leveraging what UUID does for you.

Basically Larry, I think you are kindof wrong. These alumni of yours
did what all kids should do: they ran ahead. Did they scrape their
knees doing it? Sure. But if they don't try things their teachers say
are bad, how do they advance the art? If we'd listened to Eddy
Dijkstra, we'd never have got BGP: He said it couldn't scale, even
though it was based on his own work.

-G

On Fri, Feb 5, 2021 at 4:41 AM Bakul Shah <bakul@iitbombay.org> wrote:
>
> On Feb 4, 2021, at 8:34 AM, Dan Cross <crossd@gmail.com> wrote:
> >
> > On the other hand, if we're discussing OS design and implementation, (re)splitting the VM and buffer caches is a poor decision. One might well ask, "why?" and the answer may be, "because it adds significant complexity to the kernel." This to me seems like the crux of the disagreement. Satisfied users of ZFS might legitimately ask, "who cares?" and one might respond, "kernel maintainers." If the kernel is mostly transparent as far as a particular use case goes, though, then I can see why one would bulk at the suggestion that this matters. If one is concerned with the design and implementation of kernels, I could see why one would care very much.
>
> Largely agree; though the complexity battle has long been lost. On multiple fronts. Many of us are happy to use such complex systems for their ease of use or their feature set but wouldn’t want to maintain these systems!
>
> I have used ZFS since 2005 and largely happy with it. Replaced all the disks twice. Moved the same set of disks to a new machine. etc. Features: cheap and fast snapshots, send/receive, clone, adding disks, checksummed blocks, redundancy etc. The dedup impl. is suboptimal so I don't use it. No idea if they considered using a bloom filter and a cache to reduce memory use. If a new FS came along with a similar set of features and a simpler, better integrated implementation, I'd switch.
>
>

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [TUHS] FreeBSD behind the times? (was: Favorite unix design principles?)
  2021-02-04 22:28                                 ` George Michaelson
@ 2021-02-04 22:41                                   ` Bakul Shah
  2021-02-05  0:33                                   ` Larry McVoy
  1 sibling, 0 replies; 70+ messages in thread
From: Bakul Shah @ 2021-02-04 22:41 UTC (permalink / raw)
  To: TUHS main list

On Feb 4, 2021, at 2:28 PM, George Michaelson <ggm@algebras.org> wrote:
> 
> Basically Larry, I think you are kindof wrong. These alumni of yours
> did what all kids should do: they ran ahead. Did they scrape their
> knees doing it? Sure. But if they don't try things their teachers say
> are bad, how do they advance the art? If we'd listened to Eddy
> Dijkstra, we'd never have got BGP: He said it couldn't scale, even
> though it was based on his own work.

I think Larry is talking about ZFS *implementation* design choices;
which we, as ZFS users, mostly don't care about!

It was OSPF, not BGP, that used Dijkstra's SPF algorithm. The last
I knew BGP was all about "policy" -- why random bad actors can sling
half of the internet traffic through China or Vanuatu or whatever.


^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [TUHS] FreeBSD behind the times? (was: Favorite unix design principles?)
  2021-02-04 22:28                                 ` George Michaelson
  2021-02-04 22:41                                   ` Bakul Shah
@ 2021-02-05  0:33                                   ` Larry McVoy
  2021-02-05  5:17                                     ` Bakul Shah
  1 sibling, 1 reply; 70+ messages in thread
From: Larry McVoy @ 2021-02-05  0:33 UTC (permalink / raw)
  To: George Michaelson; +Cc: TUHS main list

On Fri, Feb 05, 2021 at 08:28:12AM +1000, George Michaelson wrote:
> What ZFS did, and what Docker does, and snap does, and flatpack does,
> is package things in a way which make modalities for use for  modern
> sysadmin "just work"

No argument there.

> Basically Larry, I think you are kindof wrong. These alumni of yours
> did what all kids should do: they ran ahead. Did they scrape their
> knees doing it? Sure. But if they don't try things their teachers say
> are bad, how do they advance the art? 

Before I show you I'm not wrong, if you are saying (and I think you
are) that you like ZFS and find it useful, I have no disagreement with
that.  I'm in no way arguing that ZFS isn't useful.  If you are just 
an end user and you don't run into any of the coherency problems, 
it's great.

I'm arguing from the point of view of how a kernel is supposed to work.
What ZFS did is a gross violation of how the kernel is supposed to work
and both Bonwick and Moore have admitted that, they just thought it was
too hard to do it right.  There is a body of code in BitKeeper that does
the exact part that they thought was too hard, a layer that takes a page
fault and fills in the page from a compressed and xor-ed data source.
Works great, one guy did it in a few months or so.  It's not that hard.

So why is what ZFS did so wrong?

Ignoring the page cache and make their own cache has big problems.
You can mmap() ZFS files and doing so means that when a page is referenced
it is copied from the ZFS cache to the page cache.  That creates a
coherency problem, I can write via the mapping and I can write via
write(2) and now you have two copies of the data that don't match,
that's pretty much OS no-no #1.

You can get around it, I know, because I've written the coherency code
for SGI's IRIX when I did the bulk data server that went around the page
cache and made NFS go at 60MB/sec for a single stream (and many times
that for multiple streams).  So I'm not talking out of my ass, I know
what coherency means when you have the same data in two different places,
I know it is possible to make it work, I've done that, and I don't think
it is a good idea (it was OK in SGI's case, it was for O_DIRECT which
exists to completely bypass the page cache; so a special case that wasn't
so bad and wasn't general).

It's messy.  You could remove the data from the ZFS cache when you put
it in the page cache but ZFS is compresses so it's not going line up on
page boundaries like you'd want it to.  That means you're removing more
than your page which sort of sucks.

You could never map the pages writable, take a fault every time someone
wants to write the page and then do the write back to the ZFS cache.
That doesn't really work because you take the fault before the write
completes, not after.  You can make it work, the write fault has to
get an exclusive lock on the data in the ZFS cache, then return, then
the page gets modified, now someone has to wake up and copy that data
from the page cache to ZFS.  It's messy and it performs really poorly,
nobody would do it this way.  

You could lock the data in the ZFS cache, making it read only.  That
doesn't work because you can write via mmap() and read via ZFS and you
get old data.

All of these sorts of problems, which are solvable, I've solved them,
Sun solved them, are why you don't really want what ZFS did.  It's non
ending case of wack a mole as the code evolves and someone slips in
something that makes the page cache and the ZFS cache incoherent again.
There isn't a pleasant way to make this stuff work, that's exactly
why Sun made everything live in the page cache, there was only one
copy of any chunk of data.

Which makes it baffling to me that Sun would allow ZFS into the kernel
but I guess the benefits were perceived to outweigh the ongoing work to
make the caches coherent.  Personally, I think just doing it right is
way easier.

--lm

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [TUHS] FreeBSD behind the times? (was: Favorite unix design principles?)
  2021-02-05  0:33                                   ` Larry McVoy
@ 2021-02-05  5:17                                     ` Bakul Shah
  2021-02-05 14:18                                       ` Larry McVoy
  0 siblings, 1 reply; 70+ messages in thread
From: Bakul Shah @ 2021-02-05  5:17 UTC (permalink / raw)
  To: Larry McVoy; +Cc: TUHS main list

On Feb 4, 2021, at 4:33 PM, Larry McVoy <lm@mcvoy.com> wrote:
> 
> Ignoring the page cache and make their own cache has big problems.
> You can mmap() ZFS files and doing so means that when a page is referenced
> it is copied from the ZFS cache to the page cache.  That creates a
> coherency problem, I can write via the mapping and I can write via
> write(2) and now you have two copies of the data that don't match,
> that's pretty much OS no-no #1.

Write(2)ing to a mapped page sounds pretty dodgy. Likely to get you
in trouble in any case. Similarly read(2)ing. And you can keep track of
mapped pages and read/write from them if necessary even if you have
a  separate cache for any compressed pages. I haven’t read zfs code
but this doesn’t seem like a tricky problem.

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [TUHS] FreeBSD behind the times? (was: Favorite unix design principles?)
  2021-02-05  5:17                                     ` Bakul Shah
@ 2021-02-05 14:18                                       ` Larry McVoy
  2021-02-05 18:16                                         ` Warner Losh
                                                           ` (3 more replies)
  0 siblings, 4 replies; 70+ messages in thread
From: Larry McVoy @ 2021-02-05 14:18 UTC (permalink / raw)
  To: Bakul Shah; +Cc: TUHS main list

On Thu, Feb 04, 2021 at 09:17:54PM -0800, Bakul Shah wrote:
> On Feb 4, 2021, at 4:33 PM, Larry McVoy <lm@mcvoy.com> wrote:
> > 
> > Ignoring the page cache and make their own cache has big problems.
> > You can mmap() ZFS files and doing so means that when a page is referenced
> > it is copied from the ZFS cache to the page cache.  That creates a
> > coherency problem, I can write via the mapping and I can write via
> > write(2) and now you have two copies of the data that don't match,
> > that's pretty much OS no-no #1.
> 
> Write(2)ing to a mapped page sounds pretty dodgy. Likely to get you
> in trouble in any case. Similarly read(2)ing. 

The entire point of the SunOS 4.0 VM system was that the page you
saw via mmap(2) is the exact same page you saw via read(2).  It's
the page cache, it has page sized chunks of memory that cache 
file,offset pairs.

There is one, and only one, copy of the truth.  Doesn't matter how
you get at it, there is only one "it".

ZFS broke that contract and that was a step backwards in terms of
OS design.

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [TUHS] FreeBSD behind the times? (was: Favorite unix design principles?)
  2021-02-05 14:18                                       ` Larry McVoy
@ 2021-02-05 18:16                                         ` Warner Losh
  2021-02-05 18:21                                         ` ron minnich
                                                           ` (2 subsequent siblings)
  3 siblings, 0 replies; 70+ messages in thread
From: Warner Losh @ 2021-02-05 18:16 UTC (permalink / raw)
  To: Larry McVoy; +Cc: Bakul Shah, TUHS main list

[-- Attachment #1: Type: text/plain, Size: 1540 bytes --]

On Fri, Feb 5, 2021, 7:19 AM Larry McVoy <lm@mcvoy.com> wrote:

> On Thu, Feb 04, 2021 at 09:17:54PM -0800, Bakul Shah wrote:
> > On Feb 4, 2021, at 4:33 PM, Larry McVoy <lm@mcvoy.com> wrote:
> > >
> > > Ignoring the page cache and make their own cache has big problems.
> > > You can mmap() ZFS files and doing so means that when a page is
> referenced
> > > it is copied from the ZFS cache to the page cache.  That creates a
> > > coherency problem, I can write via the mapping and I can write via
> > > write(2) and now you have two copies of the data that don't match,
> > > that's pretty much OS no-no #1.
> >
> > Write(2)ing to a mapped page sounds pretty dodgy. Likely to get you
> > in trouble in any case. Similarly read(2)ing.
>
> The entire point of the SunOS 4.0 VM system was that the page you
> saw via mmap(2) is the exact same page you saw via read(2).  It's
> the page cache, it has page sized chunks of memory that cache
> file,offset pairs.
>
> There is one, and only one, copy of the truth.  Doesn't matter how
> you get at it, there is only one "it".
>
> ZFS broke that contract and that was a step backwards in terms of
> OS design.
>

The double copy is the primary reason we don't use it to store videos we
serve. It's a performance bottleneck as well.

And fixing it is... rather involved... possible, but a lot of work to teach
the ARC about the buffer cache or the buffer cache about the ARC...

But for everything else I do, I accept the imperfect design because of all
the other features it unlocks.

Warner

>

[-- Attachment #2: Type: text/html, Size: 2396 bytes --]

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [TUHS] FreeBSD behind the times? (was: Favorite unix design principles?)
  2021-02-05 14:18                                       ` Larry McVoy
  2021-02-05 18:16                                         ` Warner Losh
@ 2021-02-05 18:21                                         ` ron minnich
  2021-02-06  0:03                                         ` Bakul Shah
  2021-02-06  1:18                                         ` John Gilmore
  3 siblings, 0 replies; 70+ messages in thread
From: ron minnich @ 2021-02-05 18:21 UTC (permalink / raw)
  To: Larry McVoy; +Cc: Bakul Shah, TUHS main list

I think hearing *why* they did that would be interesting.

On Fri, Feb 5, 2021 at 6:19 AM Larry McVoy <lm@mcvoy.com> wrote:
>
> On Thu, Feb 04, 2021 at 09:17:54PM -0800, Bakul Shah wrote:
> > On Feb 4, 2021, at 4:33 PM, Larry McVoy <lm@mcvoy.com> wrote:
> > >
> > > Ignoring the page cache and make their own cache has big problems.
> > > You can mmap() ZFS files and doing so means that when a page is referenced
> > > it is copied from the ZFS cache to the page cache.  That creates a
> > > coherency problem, I can write via the mapping and I can write via
> > > write(2) and now you have two copies of the data that don't match,
> > > that's pretty much OS no-no #1.
> >
> > Write(2)ing to a mapped page sounds pretty dodgy. Likely to get you
> > in trouble in any case. Similarly read(2)ing.
>
> The entire point of the SunOS 4.0 VM system was that the page you
> saw via mmap(2) is the exact same page you saw via read(2).  It's
> the page cache, it has page sized chunks of memory that cache
> file,offset pairs.
>
> There is one, and only one, copy of the truth.  Doesn't matter how
> you get at it, there is only one "it".
>
> ZFS broke that contract and that was a step backwards in terms of
> OS design.

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [TUHS] FreeBSD behind the times? (was: Favorite unix design principles?)
  2021-02-04 15:45                           ` Will Senn
  2021-02-04 16:03                             ` Henry Bent
  2021-02-04 16:32                             ` Dan Cross
@ 2021-02-05 20:50                             ` Dave Horsfall
  2021-02-06  0:21                               ` Brad Spencer
                                                 ` (2 more replies)
  2 siblings, 3 replies; 70+ messages in thread
From: Dave Horsfall @ 2021-02-05 20:50 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

On Thu, 4 Feb 2021, Will Senn wrote:

> ZFS needn't be compressed, and I don't generally do compression or 
> encryption unless required by law, so I can't speak from personal 
> experience on those use cases (others, far more experienced can). I do 
> know that it's truly a pain to recover from issues with either.

[...]

Thanks; I'd heard that ZFS was a compressed file system, so I stopped 
right there (I had lots of experience in recovering from corrupted RK05s, 
and didn't need any more trouble).

Ah, the RK05 - evil incarnate.  I mean, a disk drive exposed to the air? 
Out There Somewhere [tm] is a picture of a human hair compared with the 
head clearance; yikes!

Once a month, our DEC ginger-beer[*] would PM our 40s, and I was most 
perturbed to learn that the sole job of the internal NiCd battery was to 
drag those heads back in the event of a power failure; what, you were 
writing at the time?  Too bad...

[*]
His surname was "Roth", so naturally his nickname was "Portnoy".

-- Dave

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [TUHS] FreeBSD behind the times? (was: Favorite unix design principles?)
  2021-02-05 14:18                                       ` Larry McVoy
  2021-02-05 18:16                                         ` Warner Losh
  2021-02-05 18:21                                         ` ron minnich
@ 2021-02-06  0:03                                         ` Bakul Shah
  2021-02-06  2:06                                           ` Dan Cross
  2021-02-06  1:18                                         ` John Gilmore
  3 siblings, 1 reply; 70+ messages in thread
From: Bakul Shah @ 2021-02-06  0:03 UTC (permalink / raw)
  To: Larry McVoy; +Cc: TUHS main list

On Feb 5, 2021, at 6:18 AM, Larry McVoy <lm@mcvoy.com> wrote:
> 
> On Thu, Feb 04, 2021 at 09:17:54PM -0800, Bakul Shah wrote:
>> On Feb 4, 2021, at 4:33 PM, Larry McVoy <lm@mcvoy.com> wrote:
>>> 
>>> Ignoring the page cache and make their own cache has big problems.
>>> You can mmap() ZFS files and doing so means that when a page is referenced
>>> it is copied from the ZFS cache to the page cache.  That creates a
>>> coherency problem, I can write via the mapping and I can write via
>>> write(2) and now you have two copies of the data that don't match,
>>> that's pretty much OS no-no #1.
>> 
>> Write(2)ing to a mapped page sounds pretty dodgy. Likely to get you
>> in trouble in any case. Similarly read(2)ing. 
> 
> The entire point of the SunOS 4.0 VM system was that the page you
> saw via mmap(2) is the exact same page you saw via read(2).  It's
> the page cache, it has page sized chunks of memory that cache 
> file,offset pairs.
> 
> There is one, and only one, copy of the truth.  Doesn't matter how
> you get at it, there is only one "it".
> 
> ZFS broke that contract and that was a step backwards in terms of
> OS design.

Let me repeat a part of my response you cut out:

    And you can keep track of mapped pages and read/write from them if
    necessary even if you have a  separate cache for any compressed pages.

In essence you pass the ownership of a page's data from a compressed
page cache to the mapped page. Just like in processor cache coherence
algorithms there is one source of truth: the current owner of a cached
unit (line or page or whatever). In other words, the you see via mmap(2)
will be the exact same page you will see via read(2). Not having actually
tried this I may have missed corner cases + any practical considerations
complicating things but *conceptually* this doesn't seem hard.

Warner mentions not using ZFS for its double copying. May be omething
like the above can a step in the direction of integrating the caches?

As Ron says, I too would like to hear what the authors of ZFS have to say....


^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [TUHS] FreeBSD behind the times? (was: Favorite unix design principles?)
  2021-02-05 20:50                             ` Dave Horsfall
@ 2021-02-06  0:21                               ` Brad Spencer
  2021-02-06  2:22                               ` Rico Pajarola
  2021-02-06  4:55                               ` John Cowan
  2 siblings, 0 replies; 70+ messages in thread
From: Brad Spencer @ 2021-02-06  0:21 UTC (permalink / raw)
  To: Dave Horsfall; +Cc: tuhs

Dave Horsfall <dave@horsfall.org> writes:

> On Thu, 4 Feb 2021, Will Senn wrote:
>
>> ZFS needn't be compressed, and I don't generally do compression or 
>> encryption unless required by law, so I can't speak from personal 
>> experience on those use cases (others, far more experienced can). I do 
>> know that it's truly a pain to recover from issues with either.
>
> [...]
>
> Thanks; I'd heard that ZFS was a compressed file system, so I stopped 
> right there (I had lots of experience in recovering from corrupted RK05s, 
> and didn't need any more trouble).

[snip]

I have some real world experience with ZFS and bad blocks.  As mentioned
by others, compression is not required, but it would not matter too
much.  ZFS is somewhat odd in that you can mount and use a damaged
filesystem without too much trouble and recover anything possible.  A
real example (and to keep it a TUHS topic), we had an older Solaris 10
Sparc at the $DAYJOB about two years ago that developed bad blocks on
the drive (ZFS detected this for us).  Not a surprise given the age of
the system, being 6 to 8 years old at the time, we replaced the drive
without issue and started a re-silver (ZFS's version of fsck and raid
rebuild) and during that re-silver another drive developed block errors.
This was a RAIDZ1 set up, so having two drives go out at the same time
would cause something to be lost.  If it were another RAID variant, it
would probably have been fatal.  What ZFS did was told us exactly which
file was effected by the bad block and the system kept going, no
unmounts, reboots or down time.  We replaced the second drive and the
only problem we had was a single lost file.  Compression would not have
changed this situation much, except perhaps making the problem a bit
bigger, we may have lost two files or something.  I have another example
with a Sun NFS appliance that runs under the covers Solaris 11 that
developed multiple drive fails.  In the end, we estimated that around
40% or so of the multi terabyte filesystem was damaged.  It was possible
to still use the appliance and we were able to get a lot off of it as it
continued to function as best as it could you just could not access the
files that had bad blocks in them.  ZFS has honestly been amazing in the
face of the problems I have seen.



-- 
Brad Spencer - brad@anduin.eldar.org - KC8VKS - http://anduin.eldar.org

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [TUHS] FreeBSD behind the times? (was: Favorite unix design principles?)
  2021-02-05 14:18                                       ` Larry McVoy
                                                           ` (2 preceding siblings ...)
  2021-02-06  0:03                                         ` Bakul Shah
@ 2021-02-06  1:18                                         ` John Gilmore
  2021-02-06  1:43                                           ` joe mcguckin
  2021-02-06  1:55                                           ` Bakul Shah
  3 siblings, 2 replies; 70+ messages in thread
From: John Gilmore @ 2021-02-06  1:18 UTC (permalink / raw)
  To: Bakul Shah, Larry McVoy, TUHS main list

On Thu, Feb 04, 2021 at 09:17:54PM -0800, Bakul Shah wrote:
> Write(2)ing to a mapped page sounds pretty dodgy. Likely to get you
> in trouble in any case. Similarly read(2)ing. 

Uh, no.  You misunderstand completely.

The purpose of the kernel is to provide a reliable interface to system
facilities, that lets processes NOT DEPEND on what other processes are
doing.

The decision about whether Tool X uses mmap() versus read() to access a
file, or mmap() versus write() to change one, is a decision that DOES
NOT DEPEND on what Tool Y is doing.  Tools X and Y may have been written
by different groups in different decades.  Tool X may have been written
to use stdio, which used read().  Three years later, stdio got rewritten
to use mmap() for speed, but that's invisible to the author of Tool X.
And maybe an end user in 2025 decides to use both Tool X and Tool Y on
the same file.  So only much later will any malign interactions between
read/write and mmap actually be noticed by end users.  And the fix is
not to create new dependencies between Tool X, stdio, and Tool Y.  It is
to fix the kernel so they do not depend on each other!

Here is a real-life example from my own experience.

There is a long-standing bug in the Linux kernel, in which the inotify()
system call simply didn't work on nested file systems.  This caused a
long-standing bug in Ubuntu, which I reported in 2012 here:

  https://bugs.launchpad.net/ubuntu/+source/rpcbind/+bug/977847

The symptom was that after booting from a LiveCD image, "apt-get
install" for system services (in my case an NFS client package) wouldn't
work.  Turned out the system startup scripts used inotify() to notice
and start newly installed system services.  The root cause was that
inotify failed because the root file system was an "overlayfs" that
overlaid a RAMdisk on top of the read-only LiveCD file system.  The
people who implemented "overlayfs" didn't think inotify() was important,
or they thought it would be too much work to make it actually meet its
specs, so they just made it ignore changes to the files in the overlaid
file system.  So the startup daemon's inotify() would never report the
creation of new files about the new services, because those files were
in the overlaying RAM disk, and so it would not start them and the user
would notice the error.

The underlying overlayfs bug was reported in 2011 here:

  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/882147

As far as I know it has never been fixed.  (The bug report was
closed in 2019 for one of the usual bogus reasons.)

The problem came because real tools (like systemd, or the tail command)
actually started using inotify, assuming that as a well documented
kernel interface, it would actually meet its specs.  And because a
completely unrelated other real tool (like the LiveCD installer)
actually started using overlayfs, assuming that as a well documented
kernel interface, it too would actually meet its specs.  And then one
day somebody tried to use both those tools together and they failed.

That's why telling people "Don't use mmap() on the same file that you
use read() on" is an invalid attitude for a Real Kernel Maintainer.
Props to Larry McVoy for caring about this.  Boos to the Linux
maintainers of overlayfs who didn't give a shit.

	John
	

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [TUHS] FreeBSD behind the times? (was: Favorite unix design principles?)
  2021-02-06  1:18                                         ` John Gilmore
@ 2021-02-06  1:43                                           ` joe mcguckin
  2021-02-06  1:55                                           ` Bakul Shah
  1 sibling, 0 replies; 70+ messages in thread
From: joe mcguckin @ 2021-02-06  1:43 UTC (permalink / raw)
  To: John Gilmore; +Cc: Bakul Shah, TUHS main list

[-- Attachment #1: Type: text/plain, Size: 4476 bytes --]

When I was working for a big chip testing company, a STDIO vs MMAP problem came up.

The tester was at it’s heart a SPARC VME system running Solaris.  The tester read in ‘patterns’ 
from disk, it it literally took hours to read in all the test patterns. At the scale of the large chip vendors,
every minute you can’t test because the tester is booting, etc means dollars are lost.

We wrote a bunch of macros that replaced the STDIO file system I/O calls with the equivalent 
mmap calls. . It turns out STDIO does a lot of prefetching and has some assumptions that you’re 
going to read a file linearly from beginning to end, whereas we wanted to jump around a lot in the pattern files.

Pattern loading went from 4 hours to 30 minutes. Our customer was ecstatic.

Joe McGuckin
ViaNet Communications

joe@via.net
650-207-0372 cell
650-213-1302 office
650-969-2124 fax



> On Feb 5, 2021, at 5:18 PM, John Gilmore <gnu@toad.com> wrote:
> 
> On Thu, Feb 04, 2021 at 09:17:54PM -0800, Bakul Shah wrote:
>> Write(2)ing to a mapped page sounds pretty dodgy. Likely to get you
>> in trouble in any case. Similarly read(2)ing. 
> 
> Uh, no.  You misunderstand completely.
> 
> The purpose of the kernel is to provide a reliable interface to system
> facilities, that lets processes NOT DEPEND on what other processes are
> doing.
> 
> The decision about whether Tool X uses mmap() versus read() to access a
> file, or mmap() versus write() to change one, is a decision that DOES
> NOT DEPEND on what Tool Y is doing.  Tools X and Y may have been written
> by different groups in different decades.  Tool X may have been written
> to use stdio, which used read().  Three years later, stdio got rewritten
> to use mmap() for speed, but that's invisible to the author of Tool X.
> And maybe an end user in 2025 decides to use both Tool X and Tool Y on
> the same file.  So only much later will any malign interactions between
> read/write and mmap actually be noticed by end users.  And the fix is
> not to create new dependencies between Tool X, stdio, and Tool Y.  It is
> to fix the kernel so they do not depend on each other!
> 
> Here is a real-life example from my own experience.
> 
> There is a long-standing bug in the Linux kernel, in which the inotify()
> system call simply didn't work on nested file systems.  This caused a
> long-standing bug in Ubuntu, which I reported in 2012 here:
> 
>  https://bugs.launchpad.net/ubuntu/+source/rpcbind/+bug/977847
> 
> The symptom was that after booting from a LiveCD image, "apt-get
> install" for system services (in my case an NFS client package) wouldn't
> work.  Turned out the system startup scripts used inotify() to notice
> and start newly installed system services.  The root cause was that
> inotify failed because the root file system was an "overlayfs" that
> overlaid a RAMdisk on top of the read-only LiveCD file system.  The
> people who implemented "overlayfs" didn't think inotify() was important,
> or they thought it would be too much work to make it actually meet its
> specs, so they just made it ignore changes to the files in the overlaid
> file system.  So the startup daemon's inotify() would never report the
> creation of new files about the new services, because those files were
> in the overlaying RAM disk, and so it would not start them and the user
> would notice the error.
> 
> The underlying overlayfs bug was reported in 2011 here:
> 
>  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/882147
> 
> As far as I know it has never been fixed.  (The bug report was
> closed in 2019 for one of the usual bogus reasons.)
> 
> The problem came because real tools (like systemd, or the tail command)
> actually started using inotify, assuming that as a well documented
> kernel interface, it would actually meet its specs.  And because a
> completely unrelated other real tool (like the LiveCD installer)
> actually started using overlayfs, assuming that as a well documented
> kernel interface, it too would actually meet its specs.  And then one
> day somebody tried to use both those tools together and they failed.
> 
> That's why telling people "Don't use mmap() on the same file that you
> use read() on" is an invalid attitude for a Real Kernel Maintainer.
> Props to Larry McVoy for caring about this.  Boos to the Linux
> maintainers of overlayfs who didn't give a shit.
> 
> 	John
> 	


[-- Attachment #2: Type: text/html, Size: 7707 bytes --]

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [TUHS] FreeBSD behind the times? (was: Favorite unix design principles?)
  2021-02-06  1:18                                         ` John Gilmore
  2021-02-06  1:43                                           ` joe mcguckin
@ 2021-02-06  1:55                                           ` Bakul Shah
  1 sibling, 0 replies; 70+ messages in thread
From: Bakul Shah @ 2021-02-06  1:55 UTC (permalink / raw)
  To: John Gilmore; +Cc: TUHS main list

Please see my followup message. My fault for mixing two separate things
(what a user should not do vs how the kernel can still provide coherence).

> On Feb 5, 2021, at 5:18 PM, John Gilmore <gnu@toad.com> wrote:
> 
> On Thu, Feb 04, 2021 at 09:17:54PM -0800, Bakul Shah wrote:
>> Write(2)ing to a mapped page sounds pretty dodgy. Likely to get you
>> in trouble in any case. Similarly read(2)ing. 
> 
> Uh, no.  You misunderstand completely.
> 
> The purpose of the kernel is to provide a reliable interface to system
> facilities, that lets processes NOT DEPEND on what other processes are
> doing.
> 
> The decision about whether Tool X uses mmap() versus read() to access a
> file, or mmap() versus write() to change one, is a decision that DOES
> NOT DEPEND on what Tool Y is doing.  Tools X and Y may have been written
> by different groups in different decades.  Tool X may have been written
> to use stdio, which used read().  Three years later, stdio got rewritten
> to use mmap() for speed, but that's invisible to the author of Tool X.
> And maybe an end user in 2025 decides to use both Tool X and Tool Y on
> the same file.  So only much later will any malign interactions between
> read/write and mmap actually be noticed by end users.  And the fix is
> not to create new dependencies between Tool X, stdio, and Tool Y.  It is
> to fix the kernel so they do not depend on each other!
> 
> Here is a real-life example from my own experience.
> 
> There is a long-standing bug in the Linux kernel, in which the inotify()
> system call simply didn't work on nested file systems.  This caused a
> long-standing bug in Ubuntu, which I reported in 2012 here:
> 
>  https://bugs.launchpad.net/ubuntu/+source/rpcbind/+bug/977847
> 
> The symptom was that after booting from a LiveCD image, "apt-get
> install" for system services (in my case an NFS client package) wouldn't
> work.  Turned out the system startup scripts used inotify() to notice
> and start newly installed system services.  The root cause was that
> inotify failed because the root file system was an "overlayfs" that
> overlaid a RAMdisk on top of the read-only LiveCD file system.  The
> people who implemented "overlayfs" didn't think inotify() was important,
> or they thought it would be too much work to make it actually meet its
> specs, so they just made it ignore changes to the files in the overlaid
> file system.  So the startup daemon's inotify() would never report the
> creation of new files about the new services, because those files were
> in the overlaying RAM disk, and so it would not start them and the user
> would notice the error.
> 
> The underlying overlayfs bug was reported in 2011 here:
> 
>  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/882147
> 
> As far as I know it has never been fixed.  (The bug report was
> closed in 2019 for one of the usual bogus reasons.)
> 
> The problem came because real tools (like systemd, or the tail command)
> actually started using inotify, assuming that as a well documented
> kernel interface, it would actually meet its specs.  And because a
> completely unrelated other real tool (like the LiveCD installer)
> actually started using overlayfs, assuming that as a well documented
> kernel interface, it too would actually meet its specs.  And then one
> day somebody tried to use both those tools together and they failed.
> 
> That's why telling people "Don't use mmap() on the same file that you
> use read() on" is an invalid attitude for a Real Kernel Maintainer.
> Props to Larry McVoy for caring about this.  Boos to the Linux
> maintainers of overlayfs who didn't give a shit.
> 
> 	John
> 	


^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [TUHS] FreeBSD behind the times? (was: Favorite unix design principles?)
  2021-02-06  0:03                                         ` Bakul Shah
@ 2021-02-06  2:06                                           ` Dan Cross
  2021-02-06  3:01                                             ` Bakul Shah
  0 siblings, 1 reply; 70+ messages in thread
From: Dan Cross @ 2021-02-06  2:06 UTC (permalink / raw)
  To: Bakul Shah; +Cc: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 3633 bytes --]

On Fri, Feb 5, 2021 at 7:04 PM Bakul Shah <bakul@iitbombay.org> wrote:

> On Feb 5, 2021, at 6:18 AM, Larry McVoy <lm@mcvoy.com> wrote:
> >
> > On Thu, Feb 04, 2021 at 09:17:54PM -0800, Bakul Shah wrote:
> >> On Feb 4, 2021, at 4:33 PM, Larry McVoy <lm@mcvoy.com> wrote:
> >>>
> >>> Ignoring the page cache and make their own cache has big problems.
> >>> You can mmap() ZFS files and doing so means that when a page is
> referenced
> >>> it is copied from the ZFS cache to the page cache.  That creates a
> >>> coherency problem, I can write via the mapping and I can write via
> >>> write(2) and now you have two copies of the data that don't match,
> >>> that's pretty much OS no-no #1.
> >>
> >> Write(2)ing to a mapped page sounds pretty dodgy. Likely to get you
> >> in trouble in any case. Similarly read(2)ing.
> >
> > The entire point of the SunOS 4.0 VM system was that the page you
> > saw via mmap(2) is the exact same page you saw via read(2).  It's
> > the page cache, it has page sized chunks of memory that cache
> > file,offset pairs.
> >
> > There is one, and only one, copy of the truth.  Doesn't matter how
> > you get at it, there is only one "it".
> >
> > ZFS broke that contract and that was a step backwards in terms of
> > OS design.
>
> Let me repeat a part of my response you cut out:
>
>     And you can keep track of mapped pages and read/write from them if
>     necessary even if you have a  separate cache for any compressed pages.
>
> In essence you pass the ownership of a page's data from a compressed
> page cache to the mapped page. Just like in processor cache coherence
> algorithms there is one source of truth: the current owner of a cached
> unit (line or page or whatever). In other words, the you see via mmap(2)
> will be the exact same page you will see via read(2). Not having actually
> tried this I may have missed corner cases + any practical considerations
> complicating things but *conceptually* this doesn't seem hard.


In essence, that's what the merged page/buffer cache is all about: file IO
(read/write) operations are satisfied from the same memory cache that backs
up VM objects. I agree that conceptually it's not that complex; but that's
not what ZFS does.

Of course the original Unix buffer cache didn't do that either, because no
one was mmap'ing files on the PDP-11, let alone the PDP-7. A RAM-based
buffer cache for blocks as the nexus around which the system serialized
access to the disc-resident filesystem sufficed. When virtual address
spaces got bigger (starting on the VAX) and folks wanted to start being
more clever with marrying virtual memory and IO, you had an impedance
mismatch with a fairly large extant kernel that had developed not taking
into consideration memory-mapped IO to/from files. Sun fixed this, at what
I take to be great expense (I followed keenly the same path of development
in *BSD and Linux at the time and saw how long that took, so I believe
this). But then the same Sun broke it again.

Warner mentions not using ZFS for its double copying. May be omething
> like the above can a step in the direction of integrating the caches?
>

But the cache was integrated! Until it wasn't again....

As Ron says, I too would like to hear what the authors of ZFS have to
> say....
>

Sounds like they thought it was too hard because compression means the
place on storage where an offset in a file lands is no longer a linear
function of the file's contents. Presumably the compressed contents are not
kept in RAM in any of the caches (aside from a temporary buffer to which
the compressed contents are read or something).

        - Dan C.

[-- Attachment #2: Type: text/html, Size: 4759 bytes --]

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [TUHS] FreeBSD behind the times? (was: Favorite unix design principles?)
  2021-02-05 20:50                             ` Dave Horsfall
  2021-02-06  0:21                               ` Brad Spencer
@ 2021-02-06  2:22                               ` Rico Pajarola
  2021-02-06  2:55                                 ` Larry McVoy
  2021-02-06  4:55                               ` John Cowan
  2 siblings, 1 reply; 70+ messages in thread
From: Rico Pajarola @ 2021-02-06  2:22 UTC (permalink / raw)
  To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 4534 bytes --]

On Fri, Feb 5, 2021 at 12:51 PM Dave Horsfall <dave@horsfall.org> wrote:

>
> [...]
>
> Thanks; I'd heard that ZFS was a compressed file system, so I stopped
> right there (I had lots of experience in recovering from corrupted RK05s,
> and didn't need any more trouble).
>
That's funny, for me this is the main reason to use ZFS... What really sets
ZFS apart from everything else is the lack of trouble and its resilience to
failures.  We used to have lots and lots of ZFS filesystems at work, and
I've been using ZFS exclusively at home ever since. I have run into a
non-importable ZFS file system (all drives are there, but it's corrupt and
won't import) only once, and was able to fix it with zdb.

ZFS compression is completely optional, and not even on by default. I've
only tried it once and found it cost too much performance on something
that's not very fast to begin with, but I don't think it affects data
recovery much (the way ZFS stripes data makes traditional data recovery
tools pretty useless anyway).

I personally don't care about purity of implementation, because everything
is a trade-off. The argument really reminds me of Tanenbaums criticism of
the Linux Monokernel (was Tanenbaum right? Maybe, but who cares, because
Linux took over the world, and Minix didn't, so from a practical point of
view, Linus was right). The other one it reminds me of is the criticism of
TCPs "blatant layering violation" (vs OSI). But IMHO the critics were just
jealous of the cool things they couldn't do because they needed to respect
the division of labor along those pesky layers.

I remember reading on one of the Sun engineers blogs (remember when Sun
allowed their engineers to keep blogs about Solaris development? Good
times!) about the heated discussions they had over the ARC and bypassing
the page cache. I don't remember the actual arguments for it, but it was
certainly not a decision that was made out of laziness.

Performance wise, ZFS is not the best, and if that's all you care about,
there are better options. It needs a lot of tuning to just reach
"acceptable" and it definitely does not play well with doing other stuff on
the same machine (it pretty much assumes that your storage appliance is
dedicated). It has particularly abysmal performance when you do lots of
small random writes and then try to read that back in order, but if you
care about not losing your data, it's 2nd to none.

In $JOB-1 (almost 15 years ago), we spent a few weeks stress testing ZFS.
The setup was 24x4TB SATA drives, divided into 2 12 drive raidz2 vdevs or
something like that. All tests were done while it was busy reading/writing
checksummed test files at full speed, 1GB/s or so (see? Performance was not
impressive. We definitely got a lot more out of that with UFS). What was
absolutely stunning was the fact that in all our tests it never served one
bit of corrupted data. It either had it, or it returned an error.

We tortured the storage in any way we could imagine. Wiggled the cables,
yanked out drives, used dd to overwrite random parts or entire drives,
smashed a drive with a hammer and put it back in, put in drives of the
wrong size, put in known bad drives, yanked out drives while it was
resilvering, put drives back into a different slot, overwrote stuff while
it was resilvering. Unplugged the entire storage, plugged the storage into
another machine and imported it, plugged the drives back into the first
machine in a different order. We even did things like "copy a drive onto a
spare with dd, remove 3 drives, and then substitute the spare drive for the
removed one" (this led to some data loss because making the copy was not
atomic, but most of the data was recoverable). And no matter what we did,
it just kept going unless the data was simply not there, and even then, it
kept serving the files (or parts of files) that were available, and
indicated exactly which files were affected by data loss. And when you put
the drives back (or restored the overwritten parts), it would continue as
if nothing had ever happened.

If you've ever wrestled a hardware RAID controller, or VxFS/JFS/HPFS, or
mdadm, you know that none of that can be taken for granted, and that doing
any of the stupid things mentioned above would most likely lead to complete
data loss and/or serving lots of random corrupted data and no way to tell
what had been corrupted.

I remember some performance issues with mmap, but I don't remember how we
fixed it. Probably just sucked it up. Using ZFS was not for maximum
performance.

[-- Attachment #2: Type: text/html, Size: 5261 bytes --]

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [TUHS] FreeBSD behind the times? (was: Favorite unix design principles?)
  2021-02-06  2:22                               ` Rico Pajarola
@ 2021-02-06  2:55                                 ` Larry McVoy
  2021-02-06  3:07                                   ` Will Senn
  2021-02-27  8:54                                   ` Stuart Remphrey
  0 siblings, 2 replies; 70+ messages in thread
From: Larry McVoy @ 2021-02-06  2:55 UTC (permalink / raw)
  To: Rico Pajarola; +Cc: The Eunuchs Hysterical Society

On Fri, Feb 05, 2021 at 06:22:32PM -0800, Rico Pajarola wrote:
> On Fri, Feb 5, 2021 at 12:51 PM Dave Horsfall <dave@horsfall.org> wrote:
> > Thanks; I'd heard that ZFS was a compressed file system, so I stopped
> > right there (I had lots of experience in recovering from corrupted RK05s,
> > and didn't need any more trouble).
> >
> That's funny, for me this is the main reason to use ZFS... What really sets
> ZFS apart from everything else is the lack of trouble and its resilience to
> failures.  

I'm gonna call Bill tomorrow and get his take again, that's Bill Moore
one of the two main guys who did ZFS.

This whole thread is sort of silly.  There are the users of ZFS who love
it for what it does for them.  I have no argument with them.  Then there
are the much smaller, depressingly so, group of people who care about OS
design that think ZFS took a step backwards.

I think Dennis might have stepped in here, if he was still with us, and
had some words.

I think Dennis would have brought us back to lets talk about the kernel
and what is right.  ZFS is useful, no doubt, but it is not right from
a kernel guy's point of view.

I miss Dennis.

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [TUHS] FreeBSD behind the times? (was: Favorite unix design principles?)
  2021-02-06  2:06                                           ` Dan Cross
@ 2021-02-06  3:01                                             ` Bakul Shah
  0 siblings, 0 replies; 70+ messages in thread
From: Bakul Shah @ 2021-02-06  3:01 UTC (permalink / raw)
  To: Dan Cross; +Cc: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 1203 bytes --]



> On Feb 5, 2021, at 6:06 PM, Dan Cross <crossd@gmail.com> wrote:
> 
> On Fri, Feb 5, 2021 at 7:04 PM Bakul Shah <bakul@iitbombay.org <mailto:bakul@iitbombay.org>> wrote:
> 
>     And you can keep track of mapped pages and read/write from them if
>     necessary even if you have a  separate cache for any compressed pages.
> 
> In essence you pass the ownership of a page's data from a compressed
> page cache to the mapped page. Just like in processor cache coherence
> algorithms there is one source of truth: the current owner of a cached
> unit (line or page or whatever). In other words, the you see via mmap(2)
> will be the exact same page you will see via read(2). Not having actually
> tried this I may have missed corner cases + any practical considerations
> complicating things but *conceptually* this doesn't seem hard.
> 
> In essence, that's what the merged page/buffer cache is all about: file IO (read/write) operations are satisfied from the same memory cache that backs up VM objects. I agree that conceptually it's not that complex; but that's not what ZFS does.

Good that we agree on that at least! This is why it would be good to hear from Bonwick/Moore.


[-- Attachment #2: Type: text/html, Size: 2562 bytes --]

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [TUHS] FreeBSD behind the times? (was: Favorite unix design principles?)
  2021-02-06  2:55                                 ` Larry McVoy
@ 2021-02-06  3:07                                   ` Will Senn
  2021-02-27  8:54                                   ` Stuart Remphrey
  1 sibling, 0 replies; 70+ messages in thread
From: Will Senn @ 2021-02-06  3:07 UTC (permalink / raw)
  To: Larry McVoy, Rico Pajarola; +Cc: The Eunuchs Hysterical Society

On 2/5/21 8:55 PM, Larry McVoy wrote:
> I'm gonna call Bill tomorrow and get his take again, that's Bill Moore
> one of the two main guys who did ZFS.
>
> This whole thread is sort of silly.  There are the users of ZFS who love
> it for what it does for them.  I have no argument with them.  Then there
> are the much smaller, depressingly so, group of people who care about OS
> design that think ZFS took a step backwards.
>
> I think Dennis might have stepped in here, if he was still with us, and
> had some words.
>
> I think Dennis would have brought us back to lets talk about the kernel
> and what is right.  ZFS is useful, no doubt, but it is not right from
> a kernel guy's point of view.
>
> I miss Dennis.

Larry,

Now, after the last 50 emails or so on this topic, I get it :). At 
least, I understand that technical decision were made in creating ZFS 
that were likely ill considered, the impact of those changes dubbed 
insignificant, or even possibly sound design principles ignored. It's 
debatable whether or not these decisions were deliberately contrary to 
good OS design, but I appreciate your and the other experts hanging in 
there and explaining your perspectives. I'm a systems guy, so a lot of 
the detailed OS discussions go over my head, but after enough of them, 
it kinda makes sense. At least, now, I'll pay closer attention to the 
ZFS developer list discussions :).

Will

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [TUHS] FreeBSD behind the times? (was: Favorite unix design principles?)
  2021-02-05 20:50                             ` Dave Horsfall
  2021-02-06  0:21                               ` Brad Spencer
  2021-02-06  2:22                               ` Rico Pajarola
@ 2021-02-06  4:55                               ` John Cowan
  2 siblings, 0 replies; 70+ messages in thread
From: John Cowan @ 2021-02-06  4:55 UTC (permalink / raw)
  To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 1340 bytes --]

On Fri, Feb 5, 2021 at 3:50 PM Dave Horsfall <dave@horsfall.org> wrote:


> Ah, the RK05 - evil incarnate.  I mean, a disk drive exposed to the air?
> Out There Somewhere [tm] is a picture of a human hair compared with the
> head clearance; yikes!
>

IIRC, the picture showed that even a smoke particle or a fingerprint is
bigger than the gap, never mind the hair.

Once I had to take a PDP-11 accounting application from $EMPLOYER's NJ
office to a customer in KC.  It fit on a single RK, so I took two identical
disks just in case.  This was in the late 70s.  They were already X-raying
carry-on luggage then, and I had a Bad Feeling about what might happen, so
I said no.

"No problem.  Does it open up?"

"Well, yes, but dust will ruin it."

"Well, what should we do?"

"Trust me?"

"Well -- okay.  Go ahead."

Of course when I got there both RKs were scrambled completely, so I took
the next plane home.  The next weekend, a colleague took the application on
the same flight.  On floppies.  Floppy floppies.  Lots and lots of them.
It installed fine.  Of course it took him all day and much of the following
day.



John Cowan          http://vrici.lojban.org/~cowan        cowan@ccil.org
You cannot enter here.  Go back to the abyss prepared for you!  Go back!
Fall into the nothingness that awaits you and your Master.  Go! --Gandalf

[-- Attachment #2: Type: text/html, Size: 3916 bytes --]

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [TUHS] FreeBSD behind the times? (was: Favorite unix design principles?)
  2021-01-30 23:22                       ` Warner Losh
  2021-01-30 23:31                         ` [TUHS] [SPAM] " Larry McVoy
@ 2021-02-09  2:15                         ` Will Senn
  2021-02-09  2:16                           ` Will Senn
  1 sibling, 1 reply; 70+ messages in thread
From: Will Senn @ 2021-02-09  2:15 UTC (permalink / raw)
  To: tuhs

[-- Attachment #1: Type: text/plain, Size: 278 bytes --]

On 1/30/21 5:22 PM, Warner Losh wrote some pretty good stuff and I 
needed a hook back into the thread...

Today, I found out that on Jan 12, distrowatch transitioned to FreeBSD. 
I guess it's not so far behind the times to scare off the folks that 
track the bleeding edge :)


[-- Attachment #2.1: Type: text/html, Size: 557 bytes --]

[-- Attachment #2.2: alcoppkfalhecjmi.png --]
[-- Type: image/png, Size: 55860 bytes --]

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [TUHS] FreeBSD behind the times? (was: Favorite unix design principles?)
  2021-02-09  2:15                         ` [TUHS] " Will Senn
@ 2021-02-09  2:16                           ` Will Senn
  2021-02-09  2:30                             ` Greg 'groggy' Lehey
  0 siblings, 1 reply; 70+ messages in thread
From: Will Senn @ 2021-02-09  2:16 UTC (permalink / raw)
  To: tuhs

[-- Attachment #1: Type: text/plain, Size: 368 bytes --]

On 2/8/21 8:15 PM, Will Senn wrote:
> On 1/30/21 5:22 PM, Warner Losh wrote some pretty good stuff and I 
> needed a hook back into the thread...
>
> Today, I found out that on Jan 12, distrowatch transitioned to 
> FreeBSD. I guess it's not so far behind the times to scare off the 
> folks that track the bleeding edge :)
>
OK. So it was Jan 12, of 2020 - sue me :)

[-- Attachment #2.1: Type: text/html, Size: 966 bytes --]

[-- Attachment #2.2: alcoppkfalhecjmi.png --]
[-- Type: image/png, Size: 55860 bytes --]

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [TUHS] FreeBSD behind the times? (was: Favorite unix design principles?)
  2021-02-09  2:16                           ` Will Senn
@ 2021-02-09  2:30                             ` Greg 'groggy' Lehey
  0 siblings, 0 replies; 70+ messages in thread
From: Greg 'groggy' Lehey @ 2021-02-09  2:30 UTC (permalink / raw)
  To: Will Senn; +Cc: tuhs

[-- Attachment #1: Type: text/plain, Size: 746 bytes --]

On Monday,  8 February 2021 at 20:16:50 -0600, Will Senn wrote:
> On 2/8/21 8:15 PM, Will Senn wrote:
>> On 1/30/21 5:22 PM, Warner Losh wrote some pretty good stuff and I
>> needed a hook back into the thread...
>>
>> Today, I found out that on Jan 12, distrowatch transitioned to
>> FreeBSD. I guess it's not so far behind the times to scare off the
>> folks that track the bleeding edge :)
>>
> OK. So it was Jan 12, of 2020 - sue me :)

No, just proof that we're behind the times :-)

Greg
--
Sent from my desktop computer.
Finger grog@lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [TUHS] FreeBSD behind the times? (was: Favorite unix design principles?)
  2021-01-31  2:25                       ` Larry McVoy
                                           ` (2 preceding siblings ...)
  2021-02-04  7:46                         ` Chris Torek
@ 2021-02-11 21:01                         ` Angel M Alganza
  3 siblings, 0 replies; 70+ messages in thread
From: Angel M Alganza @ 2021-02-11 21:01 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

On Sat, Jan 30, 2021 at 06:25:00PM -0800, Larry McVoy wrote:

> BitKeeper has that code and proves that it can be done.

I'm still using BitKeeper and enjoing it a lot.
I like it much better than Git.  :-)

> So good on you that you like ZFS and FreeBSD.  I don't and I don't for
> really good reasons.

I like FreeBSD, and I like ZFS (as a user, without knowing the
internals), but I like Btrfs much better.  I wish it was supported by
the BSD's, mainly OpenBSD.

What are your views on BTRFS, Larry?  I'd like to know.  :-)

Regards.
Ángel

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [TUHS] FreeBSD behind the times? (was: Favorite unix design principles?)
  2021-02-06  2:55                                 ` Larry McVoy
  2021-02-06  3:07                                   ` Will Senn
@ 2021-02-27  8:54                                   ` Stuart Remphrey
  1 sibling, 0 replies; 70+ messages in thread
From: Stuart Remphrey @ 2021-02-27  8:54 UTC (permalink / raw)
  To: Larry McVoy; +Cc: The Eunuchs Hysterical Society, Rico Pajarola

[-- Attachment #1: Type: text/plain, Size: 2651 bytes --]

Hi Larry et al,

Just curious about this: was there any feedback from Jeff Bonwick and/or
Bill Moore re the ARC -vs- page cache?

Or would any of the design notes document the reasoning behind the decision?
Surely it must have come up and been justified or got an exception in the
Solaris architecture review (SARC "20 Q's", wasn't it called?) Since AFAICS
it affected Solaris O/S interface (former-)guarantees. Although those notes
are probably lost / inaccessible now...


There's also the monthly OpenZFS leadership meeting, Matt Ahrens et al are
in there: I wonder if they would have access to some of the original
reasoning; how it was justified / why it was permitted.


Dave, btw: check out the high-level structure of ZFS metadata -- every
block is checksummed, and the checksum kept in the parent block (i.e. *not*
kept together), applicable for both data and metadata blocks, and at least
two copies are kept of metadata (but you can request more depending on your
paranoia, see also "ditto" blocks). Compression is optional at the
filesystem level (not held at the pool aka volume level; a pool may contain
multiple filesystems), when compression is enabled if affects future
created files, same if unset or changed to another algorithm; the
filesystem handles a mix of files (blocks, even; I forget offhand) existing
with various or no compression.

Rgds, Stuart.


On Sat, 6 Feb 2021 at 10:56, Larry McVoy <lm@mcvoy.com> wrote:

> On Fri, Feb 05, 2021 at 06:22:32PM -0800, Rico Pajarola wrote:
> > On Fri, Feb 5, 2021 at 12:51 PM Dave Horsfall <dave@horsfall.org> wrote:
> > > Thanks; I'd heard that ZFS was a compressed file system, so I stopped
> > > right there (I had lots of experience in recovering from corrupted
> RK05s,
> > > and didn't need any more trouble).
> > >
> > That's funny, for me this is the main reason to use ZFS... What really
> sets
> > ZFS apart from everything else is the lack of trouble and its resilience
> to
> > failures.
>
> I'm gonna call Bill tomorrow and get his take again, that's Bill Moore
> one of the two main guys who did ZFS.
>
> This whole thread is sort of silly.  There are the users of ZFS who love
> it for what it does for them.  I have no argument with them.  Then there
> are the much smaller, depressingly so, group of people who care about OS
> design that think ZFS took a step backwards.
>
> I think Dennis might have stepped in here, if he was still with us, and
> had some words.
>
> I think Dennis would have brought us back to lets talk about the kernel
> and what is right.  ZFS is useful, no doubt, but it is not right from
> a kernel guy's point of view.
>
> I miss Dennis.
>

[-- Attachment #2: Type: text/html, Size: 3314 bytes --]

^ permalink raw reply	[flat|nested] 70+ messages in thread

end of thread, other threads:[~2021-02-27  8:55 UTC | newest]

Thread overview: 70+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-01-25 11:10 [TUHS] Favorite unix design principles? Tyler Adams
2021-01-25 12:32 ` Steve Nickolas
2021-01-26  2:06   ` M Douglas McIlroy
2021-01-26  2:53     ` Steve Nickolas
2021-01-26 10:22     ` Tyler Adams
2021-01-26 12:26       ` John P. Linderman
2021-01-26 15:23       ` Clem Cole
2021-01-26 16:00         ` Niklas Karlsson
2021-01-26 16:13           ` Adam Thornton
     [not found]       ` <CAKH6PiXKjksEpQOMMMQTbcsMvX2thz3WzqjoRWJAsXnZ4Eq_iQ@mail.gmail.com>
2021-01-30 19:01         ` Tyler Adams
2021-01-30 19:50           ` Jon Steinhart
2021-01-30 20:06             ` Tyler Adams
2021-01-30 21:28               ` Clem Cole
2021-01-30 21:42                 ` Dave Horsfall
2021-01-30 21:45                 ` Tyler Adams
2021-01-30 22:31                   ` Larry McVoy
2021-01-30 22:28                 ` Larry McVoy
2021-01-30 23:11                   ` [TUHS] FreeBSD behind the times? (was: Favorite unix design principles?) Greg 'groggy' Lehey
2021-01-30 23:17                     ` Larry McVoy
2021-01-30 23:22                       ` Warner Losh
2021-01-30 23:31                         ` [TUHS] [SPAM] " Larry McVoy
2021-01-30 23:37                           ` Jon Steinhart
2021-01-30 23:54                             ` Larry McVoy
2021-01-31 12:23                               ` [TUHS] [SPAM] Re: FreeBSD behind the times? Dermot Tynan
2021-01-31  0:00                             ` [TUHS] [SPAM] Re: FreeBSD behind the times? (was: Favorite unix design principles?) Bakul Shah
2021-02-09  2:15                         ` [TUHS] " Will Senn
2021-02-09  2:16                           ` Will Senn
2021-02-09  2:30                             ` Greg 'groggy' Lehey
2021-01-31  0:39                     ` Steve Nickolas
2021-01-31  1:47                     ` Will Senn
2021-01-31  2:25                       ` Larry McVoy
2021-01-31  2:52                         ` Will Senn
2021-01-31  3:00                           ` Larry McVoy
2021-01-31  3:06                             ` Will Senn
2021-01-31  3:32                               ` John Cowan
2021-02-04  5:43                         ` Dave Horsfall
2021-02-04  6:10                           ` Angus Robinson
2021-02-04  7:46                             ` Andy Kosela
2021-02-04 22:25                             ` Dave Horsfall
2021-02-04 15:45                           ` Will Senn
2021-02-04 16:03                             ` Henry Bent
2021-02-04 16:32                             ` Dan Cross
2021-02-04 16:49                               ` Will Senn
2021-02-04 17:46                               ` Larry McVoy
2021-02-04 18:41                               ` Bakul Shah
2021-02-04 22:28                                 ` George Michaelson
2021-02-04 22:41                                   ` Bakul Shah
2021-02-05  0:33                                   ` Larry McVoy
2021-02-05  5:17                                     ` Bakul Shah
2021-02-05 14:18                                       ` Larry McVoy
2021-02-05 18:16                                         ` Warner Losh
2021-02-05 18:21                                         ` ron minnich
2021-02-06  0:03                                         ` Bakul Shah
2021-02-06  2:06                                           ` Dan Cross
2021-02-06  3:01                                             ` Bakul Shah
2021-02-06  1:18                                         ` John Gilmore
2021-02-06  1:43                                           ` joe mcguckin
2021-02-06  1:55                                           ` Bakul Shah
2021-02-05 20:50                             ` Dave Horsfall
2021-02-06  0:21                               ` Brad Spencer
2021-02-06  2:22                               ` Rico Pajarola
2021-02-06  2:55                                 ` Larry McVoy
2021-02-06  3:07                                   ` Will Senn
2021-02-27  8:54                                   ` Stuart Remphrey
2021-02-06  4:55                               ` John Cowan
2021-02-04  7:46                         ` Chris Torek
2021-02-04 15:47                           ` Will Senn
2021-02-11 21:01                         ` Angel M Alganza
2021-01-30 23:09                 ` [TUHS] Favorite unix design principles? John Cowan
2021-01-30 23:22                   ` Jon Steinhart

The Unix Heritage Society mailing list

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://inbox.vuxu.org/tuhs

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 tuhs tuhs/ http://inbox.vuxu.org/tuhs \
		tuhs@minnie.tuhs.org
	public-inbox-index tuhs

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.tuhs


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git