On Sun, Sep 3, 2017 at 11:08 AM, Warner Losh <imp(a)bsdimp.com> wrote:
>
>
> On Sat, Sep 2, 2017 at 8:54 PM, Dave Horsfall <dave(a)horsfall.org> wrote:
>
>> On Sat, 2 Sep 2017, Nemo wrote:
>>
>> Hhhmmm... This begs the historical question: When did LF replace CR/LF
>>> in UNIX?
>>>
>>
>> Unix has always used NL as the terminator :-)
>
>
> <CR><LF> was the line terminator in DEC operating systems that …
[View More]grew up
> around the same time as Unix. CP/M and MS-DOS inherited that from them
> since those systems were developed, in part, using cross compilers running
> on DEC gear with DEC OSes. Unix came from the Multics world where LF was
> used as the line terminator... Thankfully, neither CP/M nor MS-DOS picked
> up DEC's RMS...
>
> Warner
>
The fun story on that Warner is after years of dogged defense of RMS, when
C was written for VMS, Cutler had to add Stream I/O. The moment is was
released, much (?most?) of customer base (including a lot of internal folks
like the compiler runtime and DB folks) switched to using it. It was so
much easier. I never heard Dave back down, but it I used to smile when I
saw the statistics.
[View Less]
What is your favorite UNIX. Three possible categories, choose one or more:
1) Free
2) Forced to use a commercial platform. I guess that could include
macOS and z/OS with some vivid imagination, maybe even NT.
3) Historical
Me:
1) FreeBSD - I find it to generally be the least annoying desktop and
laptop experience with admittedly careful selection of hardware to
ensure compatibility. It's ideal to me for commercial appliances and
servers due to the license, tight coupling of kernel and base, …
[View More]and
features like ZFS, jails, and pluggable TCP stacks. Linux distros
lost their luster for me once systemd was integrated into Debian, and
that kind of culture seems to be prevailing up and down the stack in a
way that I'd prefer to be an outside observer of Linux and not
dependent on it for now.
2) AIX - I often see people disparage AIX but I like it. I learned a
lot in my teens about C, build systems, compilers, and lots of
libraries trying to port random software to it for auto-didactic
reasons. It definitely doesn't feel like any other UNIX. It probably
supports high core count and NUMA better than any other system except
Linux, it had advanced virtualization with LPARs and containers with
WPARs before most and hot patchable kernel, fully pagable kernel, lots
of rigorous kernel engineering there that didn't get a lot of fanfare.
SMIT is kind of cool as a TUI and spits out commands that you can
learn through repetition and use at the CLI or scripting. I think it
probably peaked in the early 2000s, but the memory management, volume
management, and file systems all seemed pretty forward thinking up
until then. I don't think SMP performance was a strong suite until it
was pretty much a relegated niche though.
3) IRIX - it just screams '90s cool like an acrylic sweater. Soft
real time, immense graphics support, pro audio and video features,
lots of interesting commercial software, NUMA, supercomputers. I
enjoy tinkering on this still, but a lot of that is due to the neat
hardware.
Regards,
Kevin
[View Less]
Warner Losh:
It's an abundance of caution thing. This code had security problems in the
past, we're not 100% sure that we've killed all the issues, though we
believe we have.
====
And if there isn't anyone who's actively interested in the
code, willing to dig in to clean it up and make security
issues less likely, deal with multiprocessing matters, and
so on, that's a perfectly reasonable stance.
I think it's an unfortunate result, and I wonder how much
of it comes from a cultural …
[View More]view that sysctl >> /proc.
(Recall how Ken and Dennis originally resisted Doug's push
for pipelines and filters, because--as Dennis once put it
in a talk--it just wasn't the way programs worked?)
But as someone who is sometimes credited with removing
more code than he wrote while working on the latter-day
Research kernel, it's hard for me to argue with the principle.
A lot of the code I tossed out was complicated stuff that
was barely used if used at all, and that nobody was willing
to step up to volunteer to maintain.
Norman Wilson
Toronto ON
[View Less]
What's your UNIX of choice to do normal "real" things these days?
Home file server (NAS), business stuff, develop code, whatever.
Mine is Solaris 11.3 at this point. Oracle has provided almost all the
"normal" utilities that are used by Linux folk, and it runs on Intel
hardware rather well. My main storage is a raidz2 of 24TB and I get
1.2GB/sec to a bunch of 3TB 512-byte-sector SAS drives.
It serves my vmware farm with iSCSI at 10gbe using COMSTAR, which also
houses a bunch of Solaris …
[View More]11 guests that perform various chores. It also
houses some Linux and Windows guests for prototyping/testing. It's also
my Samba server, servicing a few Windows workstations.
This is all in my home office where I do all my personal/professional work.
What do you all use for day-to-day development and general playing
around with new stuff?
AAK
[View Less]
>> The Fedora system I have access to lacks /usr/share/doc/groff
> Fedora defaults to loading only the package
"groff-base" so that man pages can be displayed. To actually use
groff for any other purpose, the packages "groff", "groff-doc",
"groff-perl", and "groff-X11" have to be installed. Annoying, but
there it is.
That explains all. Thanks.
doug
On Thu, Sep 28, 2017 at 06:44:20PM +0100, Derek Fawcus wrote:
> On Thu, Sep 28, 2017 at 08:34:28AM -0400, Chet Ramey wrote:
> > Yes, that changed in 2007 based on bug reports you filed while working at Cisco.
>
> So fd 255 is my fault? :-)
Or not - given that macOS, using an older bash already used 255:
$ set|fgrep VERSION
BASH_VERSION='3.2.57(1)-release'
$ lsof -p $$|fgrep CHR
bash 6843 derek 0u CHR 16,10 0t554677 701 /dev/ttys010
bash 6843 derek 1u CHR …
[View More]16,10 0t554677 701 /dev/ttys010
bash 6843 derek 2u CHR 16,10 0t554677 701 /dev/ttys010
bash 6843 derek 255u CHR 16,10 0t554677 701 /dev/ttys010
DF
[View Less]
>
> It's important to note, when talking about NFS, that there was Sun's NFS
> and everyone else's NFS. Sun ran their entire company on NFS. /usr/dist
> was where all the software that was not part of SunOS lived, it was an
> NFS mounted volume (that was replicated to each subnet). It was heavily
> used as were a lot of other things. The automounter at Sun just worked,
> wanted to see your buddies stuff? You just cd-ed to it and it worked.
>
> Much like mmap, …
[View More]NFS did not export well to other companies. When I went
> to SGI I actually had a principle engineer (like Suns distinguished
> engineer) tell me "nobody trusts NFS, use rcp if you care about your
> data". What. The. Fuck. At Sun, NFS just worked. All the time.
> The idea that it would not work was unthinkable and if it ever did
> not work it got fixed right away.
>
> Other companies, it was a checkbox thing, it sorta worked. That was
> an eye opener for me. mmap was the same way, Sun got it right and
> other companies sort of did.
>
I remember the days of NFS Connect-a-thons where all the different
vendors would get together and see if they all interoperated. It was
interesting to see who worked and who didn’t. And all the hacking to
fix your implementation to talk to vendor X while not breaking it working
with vendor Y.
Good times indeed.
David
[View Less]
> From: Theodore Ts'o
> when a file was truncated and then rewritten, and "truncate this file"
> packet got reordered and got received after the "here's the new 4k of
> contents of the file", Hilar[i]ty Enused.
This sounds _exactly_ like a bad bug found in the RVD protocol (Remote Virtual
Disk - a simple block device emulator). Disks kept suffering bit rot (damage
to the inodes, IIRC). After much suffering, and pain trying to debug it (lots
of disk writes, how do you …
[View More]figure out the one that's the problem), it was
finally found (IIRC, it wasn't something thinking about it, they actually
caught it). Turned out (I'm pretty sure my memory of the bug is correct), if
you had two writes of the same block in quick sucession, and the second was
lost, if the first one's ack was delayed Just Enough...
They had an unused 'hint' (I think) field in the protocol, and so they
recycled that to be a sequence number, so they could tell ack's apart.
Noel
[View Less]
Larry McVoy:
> +1 on what Ron said. I don't get the rationale for going back to ptrace.
> Anyone know what it is? Is there a perf issue?
Kurt H Maier:
The usual rationale presented is that someone can exhaust the fd table
and then you can't get anything done. Instead of fixing that problem,
the popular approach is to add more syscalls, like with getrandom(2).
====
Funny that that rationale isn't extended to its logical
conclusion: get rid of open and creat. Then nobody needs
…
[View More]to worry about running out of file descriptors ever!
I too am saddened to see such a retrograde step, but perhaps
I'm biased. When I arrived in 1127, the kernel had /proc but
still had ptrace as well. Why? Because no one was brave enough
to wade into sdb and adb.
After a couple of years, I felt brave enough, so I did it.
Once the revised sdb and adb had propagated to all our systems,
I removed the syscall. I celebrated by physically removing
ptrace(2) from the Eighth Edition manual in the UNIX room: the
manual entry comprised two facing pages, which I glued together.
I can sympathize with FreeBSD excuse someone cited elsewhere,
that nobody used the code so it should go--I'm always in favour
of improving programs by chopping sutff out--but I think the
decision here was backwards. The proper answer would have been
to teach ps et al to use /proc, not to invent a new complex of
system calls.
I dislike how Linux has tossed information about processes and
other system-related data into the same namespace (and now that
there is /sys as well as /proc, I wonder whether it's time to
divorce them, or even to move /proc into /sys/proc), but the
general direction of moving things into the file system makes
sense. I have some qualms about adding more and more code to
the kernel that just does string processing (making the kernel
bigger and more complicated, and widening the attack surface
for bad guys), though; maybe most of that stuff belongs not in
the OS proper but in a user-mode program that reads /dev/mem
and presents as a file system.
Norman Wilson
Toronto ON
[View Less]
On Wed, 27 Sep 2017, Roland Turner wrote:
> * Simply attaching the entire message as a message/rfc822 part is an
> appealing approach, but very few mail clients would do anything
> intelligent with it.
My MUA of choice, Alpine, certainly does, and it's hardly uncommon. I
tried Elm once, and immediately went straight back to Pine (as it was
known then); never bothered with Mutt.
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."