3 Feb
2018
3 Feb
'18
8:57 p.m.
Co-inventor of Unix, he was born on this day in 1943. Just think: without
those two, we'd all be running M$ Windoze and thinking that it's
wonderful (I know, it's an exaggeration, but think about it).
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will
suffer."
3 Feb
3 Feb
9:12 p.m.
Happy birthday, Ken, inventor of Unix, Father of Unix!
At 3 Feb 2018 20:58:25 +0000 (+00:00) from Dave Horsfall <dave(a)horsfall.org>rg>:
Co-inventor of Unix, he was born on this day in 1943.
Just think: without
those two, we'd all be running M$ Windoze and thinking that it's
wonderful (I know, it's an exaggeration, but think about it).
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will
suffer."
9:59 p.m.
On Saturday, February 3, 2018, Donald ODona <mutiny.mutiny(a)india.com> wrote:
Happy birthday, Ken, inventor of Unix, Father of
Unix!
Exactly. He is the true father of UNIX.
I always admired Ken's passion for minimalism and elegant, simple solutions
to IT problems. Ed(1) will always be the most beautiful editor ever
written.
Besides Go I have not seen him getting involved with other projects
recently though and the world needs him now more than ever...
Linux and FreeBSD are now two monstrous trolls, bloated and extremely
complex and large.
Plan 9 is dead. MINIX is dying too...
It seems UNIX fate is doomed. The only last remaining production quality
UNIX that still maintains minimalism as one of its goals is probably
OpenBSD these days...
I am glad Rob and Ken gave us Go. It breathed a new life into the complex
world of writing software.
Happy Birthday, Ken.
--Andy
4 Feb
4 Feb
12:52 a.m.
On Sat, 3 Feb 2018, Andy Kosela wrote:
I always admired Ken's passion for minimalism and
elegant, simple
solutions to IT problems. Ed(1) will always be the most beautiful
editor ever written.
And the one editor that every sysadmin should know. I still use "expr" in
my shell scripts, for example, because I don't know how portable the
Penguin "${...}" construct is.
[...]
Linux and FreeBSD are now two monstrous trolls,
bloated and extremely
complex and large.
Looking through /usr/include/***.h, I see:
FreeBSD 10.4: #define SYS_MAXSYSCALL 548
MacOS Sierra: #define SYS_MAXSYSCALL 522
Debian 8.10: I don't know where the Penguins have hidden it...
I am glad Rob and Ken gave us Go. It breathed a new
life into the
complex world of writing software.
That's the second endorsement I've seen for Go; I guess I should learn it.
And yes, I've read the amusing story on Wikipedia :-) I'm becoming
annoyed at Perl's bloatedness (I'd hate to see Perl 6), don't like
Python's silly indentation (although some swear by it), and looking at
Ruby for stuff where I used to use Perl.
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will
suffer."
1:07 a.m.
That's the second endorsement I've seen for
Go; I guess I should learn it.
In the scheme of "current" languages, Go is pretty good. With two major
caveats, IMO:
1) The build system. It doesn't work with make(1). That makes it a
non-starter for anything other than trivial projects at $WORK. While I
appreciate the arguments for the apparent simplicity of the "go" command,
that doesn't work for us. Which would have been fine, but for the
entirely antagonistic bent they have taken against being able to build Go
programs with make(1). Our build environment entirely precludes Go's
promiscuous insistence on unfettered internet access, and hardwired
directory paths.
2) Hardwired directory paths for the development/build environment (see
above).
It seems they have unlearned all the UNIX lessons. Sad, really. I would
love to toss out Python, Ruby, PHP, Perl, et al. And could make the
argument for it, I think. But the build environment will never work in
our shop, therefore Go won't either.
And that ... sucks.
1:14 a.m.
On Sat, Feb 3, 2018 at 5:52 PM, Dave Horsfall <dave(a)horsfall.org> wrote:
On Sat, 3 Feb 2018, Andy Kosela wrote:
Part of the reason for the bloat is that newer syscalls replace older ones
(with the option for keeping the older one around for compat). So, open
becomes openat (since the latter is more expressive). Also, over time,
different data types grow to allow, for example, larger than 2G files,
which has a big ripple effect on lots of system calls. But looking now, a
lot are due to MAC and ACL functions (well, 30). There's 80 'at' system
calls (though some are in the ~150 obsolete list)... So it isn't as utterly
horrific as it might sound, but it's still pretty bad. (There's 400
defined, with 20 of those being for prior versions of the OS).
Warner
Linux and FreeBSD are now two monstrous trolls,
bloated and extremely
complex and large.
Looking through /usr/include/***.h, I see:
FreeBSD 10.4: #define SYS_MAXSYSCALL 548
MacOS Sierra: #define SYS_MAXSYSCALL 522
Debian 8.10: I don't know where the Penguins have hidden it... 
1:59 p.m.
On Sat, Feb 03, 2018 at 06:14:30PM -0700, Warner Losh wrote:
Part of the reason for the bloat is that newer syscalls replace older ones
(with the option for keeping the older one around for compat). So, open
becomes openat (since the latter is more expressive). Also, over time,
different data types grow to allow, for example, larger than 2G files,
which has a big ripple effect on lots of system calls. But looking now, a
lot are due to MAC and ACL functions (well, 30). There's 80 'at' system
calls (though some are in the ~150 obsolete list)... So it isn't as utterly
horrific as it might sound, but it's still pretty bad. (There's 400
defined, with 20 of those being for prior versions of the OS).
Indeed. Linux has 292 system calls as of Linux 4.15. If you include
the backwards compatibility system calls, the number of system calls
goes up to 352.
Of course, just comparing system calls isn't really the whole story.
There are also system interfaces via /proc and /sys, ioctl's, etc.
(And by that measure Plan9 has a lot of complexity that doesn't show
up in plain system call counts.)
*And* of course, a lot of bloat doesn't show up in kernel/userspace
interfaces, but rather in the complexity that people expect to be
found in modern Systems, whether they be in the kernel or in the Java
class libraries, etc. Complaining about the OS complexity when people
are gleefully building super-complex systems in userspace seems to me
to be a kind of "get off my lawn" complaint.
The question is, given an overall system architecture, *including*
userspace, when does it make sense to try to simplify things by
pushing some of the work to the lower layers of the software stack,
and when does it make sense to force the userspace to deal with the
complexity?
Of course, if you want to do all of your programming on the equivalent
of a Raspberry Pi, that also can be your choice. :-)
- Ted
Linux and FreeBSD are now two monstrous trolls,
bloated and extremely
complex and large.
Looking through /usr/include/***.h, I see:
FreeBSD 10.4: #define SYS_MAXSYSCALL 548
MacOS Sierra: #define SYS_MAXSYSCALL 522
Debian 8.10: I don't know where the Penguins have hidden it... 
5 Feb
5 Feb
1:13 p.m.
Andy Kosela <akosela(a)andykosela.com> wrote:
MINIX is dying too...
Intel are now shipping MINIX as the embedded management OS on all their
CPUs. Here's Andrew Tanenbaum's view: http://www.cs.vu.nl/~ast/intel/
Tony.
--
f.anthony.n.finch <dot(a)dotat.at> http://dotat.at/ - I xn--zr8h punycode
Thames, Dover, Wight, Portland: Northeast 5 or 6. Slight or moderate. Wintry
showers. Good.
3:45 p.m.
On Mon, 05 Feb 2018 13:13:51 +0000 Tony Finch <dot(a)dotat.at> wrote:
Tony Finch writes:
Andy Kosela <akosela(a)andykosela.com> wrote:
minix3 useland is basically the NetBSD userland.
I wonder if any of that is running on the IME.
MINIX is dying too...
Intel are now shipping MINIX as the embedded management OS on all their
CPUs. Here's Andrew Tanenbaum's view: http://www.cs.vu.nl/~ast/intel/ 
4:19 p.m.
Note: I speak for me, not Intel and please don't blame me for the choices as*
I have had nothing to do with it.*..
On Mon, Feb 5, 2018 at 10:45 AM, Bakul Shah <bakul(a)bitblocks.com> wrote:
On Mon, 05 Feb 2018 13:13:51 +0000 Tony Finch
<dot(a)dotat.at> wrote:
Tony Finch writes:
I can not speak authoritatively (so in some ways this reply might be seen
as worthless), but I do not believe so. As I understand it (i.e.when I
asked about it with some of the CPU/BIOS types), the >>modified<< minix
kernel is basically an small embedded OS to support locally created custom
code for the management engine user code. There is not much there. The
while idea was an 'OS' to support the kinds of functions the management
engine needed -- from low level HW/device support to a networking stack --
'supporting' a complex application that could be written and debugged
outside of the production environment and the run 'as it' in the
'rom.'
Of course as our friends in the security side of the business point out,
the more that is there, the larger the attack surface, but I think the idea
is was to keep it small, light and simple and minix won out. Actually,
what's cool IMO is the choice of minix, often in my career, I have seen
those sorts of folks want to write their own and that to me a more
frightening. At least this means more people are likely to have hacked on
it >>before<< Intel took it in house [although I believe that action wrankels
many in the FOSS community - including a few on this list - who have
expressed that they think that the IME code needs to be 'published and free
to be inspected'].
Clem
ᐧ
Intel are now shipping MINIX as the embedded
management OS on all their
CPUs. Here's Andrew Tanenbaum's view: http://www.cs.vu.nl/~ast/intel/
minix3 useland is basically the NetBSD userland.
I wonder if any of that is running on the IME.
5:41 p.m.
On Feb 5, 2018, at 8:19 AM, Clem Cole <clemc(a)ccc.com> wrote:
Note: I speak for me, not Intel and please don't blame me for the choices as I have
had nothing to do with it...
On Mon, Feb 5, 2018 at 10:45 AM, Bakul Shah <bakul(a)bitblocks.com> wrote:
On Mon, 05 Feb 2018 13:13:51 +0000 Tony Finch <dot(a)dotat.at> wrote:
Tony Finch writes:
Makes sense. Thanks! World's most complex processor
in service of world's most complex OSes being managed
by a microkernel. Sad. Ironic.
Intel are now shipping MINIX as the embedded
management OS on all their
CPUs. Here's Andrew Tanenbaum's view: http://www.cs.vu.nl/~ast/intel/
minix3 useland is basically the NetBSD userland.
I wonder if any of that is running on the IME.
I can not speak authoritatively (so in some ways this reply might be seen as worthless),
but I do not believe so. As I understand it (i.e.when I asked about it with some of the
CPU/BIOS types), the >>modified<< minix kernel is basically an small embedded
OS to support locally created custom code for the management engine user code. There is
not much there. The while idea was an 'OS' to support the kinds of functions
the management engine needed -- from low level HW/device support to a networking stack --
'supporting' a complex application that could be written and debugged outside of
the production environment and the run 'as it' in the 'rom.'
Of course as our friends in the security side of the business point out, the more that is
there, the larger the attack surface, but I think the idea is was to keep it small, light
and simple and minix won out. Actually, what's cool IMO is the choice of minix,
often in my career, I have seen those sorts of folks want to write their own and that to
me a more frightening. At least this means more people are likely to have hacked on it
>>before<< Intel took it in house [although I believe that action wrankels
many in the FOSS community - including a few on this list - who have expressed that they
think that the IME code needs to be 'published and free to be inspected'].
9:58 p.m.
On Monday, February 5, 2018, Tony Finch <dot(a)dotat.at> wrote:
Andy Kosela <akosela(a)andykosela.com> wrote:
I am well aware of that, but ironically Intel did not even informed Andrew
about it... No one in the MINIX community was aware of that.
How long ago have you checked how busy are MINIX git commits... there has
been literally none since at least a few months. It is practically a dead
project as far as new development is concerned.
Plus it never really drew attention of really influential luminaries from
the open source world... there is no Theo or Alan Cox amongst MINIX kernel
hackers. Most of the core members were always coming from VU in Amsterdam
(where Andrew teaches).
I would love to see MINIX succeed, but it is just not happening and it has
been 10 years since the release of MINIX 3.
--Andy
MINIX is dying too...
Intel are now shipping MINIX as the embedded management OS on all their
CPUs. Here's Andrew Tanenbaum's view: http://www.cs.vu.nl/~ast/intel/
10:47 p.m.
On Mon, 5 Feb 2018, Andy Kosela wrote:
I am well aware of that, but ironically Intel did not
even informed
Andrew about it... No one in the MINIX community was aware of that.
And AndrewT was reportedly pissed off when he found that the ME could
actually snoop on (and respond to) network traffic etc without the OS even
being aware of it; apparently the ME hooks into the NIC...
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will
suffer."
10:52 p.m.
On 2018-02-05 5:47 PM, Dave Horsfall wrote:
On Mon, 5 Feb 2018, Andy Kosela wrote:
If he thought that was *important* surely he'd have mentioned it in his
otherwise self-aggrandising blog post?
--T
I am well aware of that, but ironically Intel did
not even informed
Andrew about it... No one in the MINIX community was aware of that.
And AndrewT was reportedly pissed off when he found that the ME could
actually snoop on (and respond to) network traffic etc without the OS
even being aware of it; apparently the ME hooks into the NIC...
10:54 p.m.
On Mon, Feb 5, 2018 at 5:47 PM, Dave Horsfall <dave(a)horsfall.org> wrote:
On Mon, 5 Feb 2018, Andy Kosela wrote:
I am well aware of that, but ironically Intel did not even informed Andrew
Speaking of things like that...This just landed in my inbox:
http://www.mymtaalerts.com/m?78F2F
The metrocard vending machines in the NYC subway are little PCs. I could
swear I've seen either an OS/2, Windows, or Linux startup sequence on one
or more of them before (maybe all three).
Anyway, what do you want to bet that the MTA is making people go around
with media and manually install updates for Spectre/Meltdown across the
transit system?
- Dan C.
about it... No one in the MINIX community was
aware of that.
And AndrewT was reportedly pissed off when he found that the ME could
actually snoop on (and respond to) network traffic etc without the OS even
being aware of it; apparently the ME hooks into the NIC...
6 Feb
6 Feb
4:58 a.m.
On Mon, Feb 05, 2018 at 05:54:57PM -0500, Dan Cross wrote:
Speaking of things like that...This just landed in my
inbox:
http://www.mymtaalerts.com/m?78F2F
The metrocard vending machines in the NYC subway are little PCs. I could
swear I've seen either an OS/2, Windows, or Linux startup sequence on one
or more of them before (maybe all three).
Anyway, what do you want to bet that the MTA is making people go around
with media and manually install updates for Spectre/Meltdown across the
transit system?
No bet. How much do you want to bet the MTA isn't bothering to update
gazillions of *other* already published and known security holes that
were zero days years ago? Holes that are probably *Way* easier to
exploit than those using Spectre/Meltdown?
If it's anything like the MBTA in Massachusetts their security is
limited to trying to sue graduate students[1] in an attempt to impose
prior restraint on their research (and including the presentation[2]
as an exhibit on the lawsuit and letting it be published on the
court's website for all to see?).
[1] https://en.wikipedia.org/wiki/Massachusetts_Bay_Transportation_Authority_v.…
[2] http://tech.mit.edu/V128/N30/subway/Defcon_Presentation.pdf
- Ted
5:05 a.m.
Hello!
In NYC the machines who sell MTA transit cards and refill them are
running Windows Embedded. And not the most up to date version. I've
watched them cause the classic BSOD more then once, and sometimes
worse.
The actual hardware that's delivers the cards and the single use ones
are running something else, and appear to be VME based. The whole
thing is a revolting kludge that's asking for trouble.
Oh and Dan Cross? Thank you for your service to this country, again and again.
-----
Gregg C Levine gregg.drwho8(a)gmail.com
"This signature fought the Time Wars, time and again."
On Mon, Feb 5, 2018 at 11:58 PM, Theodore Ts'o <tytso(a)mit.edu> wrote:
On Mon, Feb 05, 2018 at 05:54:57PM -0500, Dan Cross
wrote:
Speaking of things like that...This just landed
in my inbox:
http://www.mymtaalerts.com/m?78F2F
The metrocard vending machines in the NYC subway are little PCs. I could
swear I've seen either an OS/2, Windows, or Linux startup sequence on one
or more of them before (maybe all three).
Anyway, what do you want to bet that the MTA is making people go around
with media and manually install updates for Spectre/Meltdown across the
transit system?
No bet. How much do you want to bet the MTA isn't bothering to update
gazillions of *other* already published and known security holes that
were zero days years ago? Holes that are probably *Way* easier to
exploit than those using Spectre/Meltdown?
If it's anything like the MBTA in Massachusetts their security is
limited to trying to sue graduate students[1] in an attempt to impose
prior restraint on their research (and including the presentation[2]
as an exhibit on the lawsuit and letting it be published on the
court's website for all to see?).
[1] https://en.wikipedia.org/wiki/Massachusetts_Bay_Transportation_Authority_v.…
[2] http://tech.mit.edu/V128/N30/subway/Defcon_Presentation.pdf
- Ted 
3 Feb
3 Feb
9:35 p.m.
Not a day goes by when I am not soooo thankful that I don’t have to live in a windows
world. Unix and C have both had a huge impact on my career and computing life and I am
grateful for their creation and legacy. Thankfully, Ken couldn’t afford a nicer computer
and was forced to get creative with what he had to hand. Thanks Ken!
Will
Sent from my iPhone
On Feb 3, 2018, at 2:57 PM, Dave Horsfall
<dave(a)horsfall.org> wrote:
Co-inventor of Unix, he was born on this day in 1943. Just think: without those two,
we'd all be running M$ Windoze and thinking that it's wonderful (I know,
it's an exaggeration, but think about it).
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will
suffer."
9:49 p.m.
On 2/3/2018 4:35 PM, Will Senn wrote:
Not a day goes by when I am not soooo thankful that I
don’t have to live in a windows world
I would imagine that Windows wouldn't be what it is today without UNIX.
Matter of fact, Windows NT (which is what Windows has been based on
since Windows ME went away) is really DEC's VMS underneath the covers at
least to a small extent.
Would VMS become what it was without UNIX's influence? Would UNIX become
what it later was without VMS?
Would UNIX exist, or even be close to what it became without DEC?
art k.
10:59 p.m.
On Sat, 3 Feb 2018, Arthur Krewat wrote:
I would imagine that Windows wouldn't be what it
is today without UNIX.
Matter of fact, Windows NT (which is what Windows has been based on
since Windows ME went away) is really DEC's VMS underneath the covers at
least to a small extent.
I thought that NT has a POSIX-y kernel, which is why it was so reliable?
Or was VMS a POSIX-like system? I only used it for a couple of years in
the early 80s (up to 4.0, I think), and never dug inside it; to me, it was
just RSX-11/RSTS-11 on steroids.
Would VMS become what it was without UNIX's
influence? Would UNIX become
what it later was without VMS?
Would UNIX exist, or even be close to what it became without DEC?
I've oft wondered that, but we have to use a new thread to avoid
embarrassing Ken :-)
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will
suffer."
4 Feb
4 Feb
12:51 a.m.
Hi,
I have to take issue with the “plan9 is dead” statement,
I agree it seems on a downward spiral, but are a few who fight on.
[sent from my plan9]
-Steve
2283
days inactive
2286
days old
20 comments
15 participants
participants (15)
-
Andy Kosela -
Arthur Krewat -
Bakul Shah -
Clem Cole -
Dan Cross -
Dave Horsfall -
Donald ODona -
Gregg Levine -
Lyndon Nerenberg -
Steve Simon -
Theodore Ts'o -
Toby Thain -
Tony Finch -
Warner Losh -
Will Senn