One half of Unix, and what more can I say? Well, I'll bet not many people know that he shares a birthday with Alice Cooper... -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
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. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
[-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 952 bytes --] On 4 Feb 2017 07:00 +1100, from dave at horsfall.org (Dave Horsfall): > Just think: without those two, we'd all be running M$ Windoze and > thinking that it's wonderful. I wouldn't be so sure that claim should stand uncontested, given that PC-DOS 2.0 (long before Windows) largely copied the concept of directories from UNIX. Just think how wonderful Windows would be if it was running on top of a file system that lacked the concept of directories. Then again IIRC the original Macintosh file system had no concept of directories, but they somehow faked them in software. Makes you wonder why they went through all that trouble instead of implementing _proper_ support for directories/folders/filing cabinets/drawers/etc. -- Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se “People who think they know everything really annoy those of us who know we don’t.” (Bjarne Stroustrup)
[-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1295 bytes --] On Sat, 4 Feb 2017, Michael Kjörling wrote: > On 4 Feb 2017 07:00 +1100, from dave at horsfall.org (Dave Horsfall): >> Just think: without those two, we'd all be running M$ Windoze and >> thinking that it's wonderful. > > I wouldn't be so sure that claim should stand uncontested, given that > PC-DOS 2.0 (long before Windows) largely copied the concept of > directories from UNIX. Just think how wonderful Windows would be if it > was running on top of a file system that lacked the concept of > directories. MS-DOS 2 took an OS that was largely inspired by CP/M and replaced the file API *with that of Xenix* just to add directory support. Best change they ever made. Now if only IBM hadn't forced them to use \ as the path separator instead of /, it would've been slightly better. Still, MS-DOS was probably the most C-friendly system out there that wasn't a Unix or Unix clone. Bit hackish how they emulated piping, though didn't "Mini Unix" do the same thing? > Then again IIRC the original Macintosh file system had no concept of > directories, but they somehow faked them in software. Makes you wonder > why they went through all that trouble instead of implementing > _proper_ support for directories/folders/filing cabinets/drawers/etc. I believe this is correct. -uso.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 794 bytes --] On 4 Feb 2017 07:44 -0500, from usotsuki at buric.co (Steve Nickolas): > Bit hackish how they emulated piping, Well, I suppose there's only so much you can really do in an inherently single-tasking OS that needs to be able to do useful work on a system with a single 160 KB floppy drive, no virtual memory capability, and 64 KiB RAM. All things told, I regularly look back at what people were able to make computers of days yonder _do_, and am often amazed at how well they were able to get things to work _in spite of_ the limitations of the hardware of the time. -- Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se “People who think they know everything really annoy those of us who know we don’t.” (Bjarne Stroustrup)
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."
Happy birthday, Ken, inventor of Unix, Father of Unix!
At 3 Feb 2018 20:58:25 +0000 (+00:00) from Dave Horsfall <dave at horsfall.org>:
> 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."
[-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 736 bytes --] 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 at 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."
Or as we old 1127ers would put it: What day is it, Ken?
[-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 559 bytes --] 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.
On Saturday, February 3, 2018, Donald ODona <mutiny.mutiny at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180203/aaac6f65/attachment.html>
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."
[-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 166 bytes --] 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
[-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1196 bytes --] 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."
> 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.
On Sat, Feb 3, 2018 at 5:52 PM, Dave Horsfall <dave at horsfall.org> wrote: > On Sat, 3 Feb 2018, Andy Kosela wrote: > >> 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... 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180203/7cb2c8db/attachment.html>
You can use make as much as you like; Go just doesn't need it. You can use Go to fetch code from internet if you like, or you can do it yourself if you prefer. Regarding the "hardwired" directories, you can change it through an environment variable. Em 3 de fev de 2018 23:20, "Lyndon Nerenberg" <lyndon at orthanc.ca> escreveu: 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180203/27419e6c/attachment.html>
> You can use make as much as you like; Go just doesn't need it. You can use
> Go to fetch code from internet if you like, or you can do it yourself if
> you prefer.
>
> Regarding the "hardwired" directories, you can change it through an
> environment variable.
My argument is that Go is making that an untenable exercise. E.g.,
forcing environment variable overrides means I don't have a source tree I
can check out *anywhere* and have it just build. No different from the
built-in assumptions the go command makes.
I get the feeling there won't be any sort of actual argument for or
against the Go regime, so I won't.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 580 bytes --] What do you mean plan9 is dead? It's even possible make a facebook post from inside plan9 nowadays! https://twitter.com/bigatojj/status/949838932841201664 See vmx(1) Em 3 de fev de 2018 23:25, "Steve Simon" <steve at quintile.net> escreveu: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180203/4d8fb14a/attachment-0001.html>
On Sat, Feb 03, 2018 at 06:14:30PM -0700, Warner Losh wrote:
> >> 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...
>
> 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
[-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 593 bytes --] On 2018-02-03 8:51 PM, Daniel Camolês wrote: > What do you mean plan9 is dead? It's even possible make a facebook post > from inside plan9 nowadays! So it's not only dead, it's in Hell. > > https://twitter.com/bigatojj/status/949838932841201664 > > See vmx(1) > > Em 3 de fev de 2018 23:25, "Steve Simon" <steve at quintile.net > <mailto:steve at quintile.net>> escreveu: > > 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 > > >
Andy Kosela <akosela at 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 at dotat.at> http://dotat.at/ - I xn--zr8h punycode Thames, Dover, Wight, Portland: Northeast 5 or 6. Slight or moderate. Wintry showers. Good.
On Mon, 05 Feb 2018 13:13:51 +0000 Tony Finch <dot at dotat.at> wrote:
Tony Finch writes:
> Andy Kosela <akosela at 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/
minix3 useland is basically the NetBSD userland.
I wonder if any of that is running on the IME.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 2066 bytes --] 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 at bitblocks.com> wrote: > On Mon, 05 Feb 2018 13:13:51 +0000 Tony Finch <dot at dotat.at> wrote: > Tony Finch writes: > > 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']. Clem ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180205/3424ab28/attachment-0001.html>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 2097 bytes --] On Feb 5, 2018, at 8:19 AM, Clem Cole <clemc at 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 at bitblocks.com> wrote: > On Mon, 05 Feb 2018 13:13:51 +0000 Tony Finch <dot at dotat.at> wrote: > Tony Finch writes: > > 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']. Makes sense. Thanks! World's most complex processor in service of world's most complex OSes being managed by a microkernel. Sad. Ironic.
On Monday, February 5, 2018, Tony Finch <dot at dotat.at> wrote: > Andy Kosela <akosela at 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/ > > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180205/18c1b6e3/attachment-0001.html>
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."
On 2018-02-05 5:47 PM, Dave Horsfall wrote:
> 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...
>
If he thought that was *important* surely he'd have mentioned it in his
otherwise self-aggrandising blog post?
--T
On Mon, Feb 5, 2018 at 5:47 PM, Dave Horsfall <dave at 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 >> 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... 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180205/ac5f7339/attachment.html>
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._Anderson [2] http://tech.mit.edu/V128/N30/subway/Defcon_Presentation.pdf - Ted
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 at gmail.com
"This signature fought the Time Wars, time and again."
On Mon, Feb 5, 2018 at 11:58 PM, Theodore Ts'o <tytso at 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._Anderson
> [2] http://tech.mit.edu/V128/N30/subway/Defcon_Presentation.pdf
>
> - Ted
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
[-- Attachment #1: Type: text/plain, Size: 630 bytes --] On Monday, 4 February 2019 at 7:23:35 +1100, Dave Horsfall 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). Without Unix, Microsoft would not have created Microsoft "Windows". Even it has roots in Unix. 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 --]
On Mon, 4 Feb 2019, Greg 'groggy' Lehey wrote: > Without Unix, Microsoft would not have created Microsoft "Windows". I'd like to see some evidence for that; without Unix, what would we be running now? I doubt whether it would've been Linux, there being no inspiration for it... My vague (and rough) recollection is CP/M -> DOS -> Windows. > Even it has roots in Unix. Only inasmuch as it has directories, users, and permissions (which any semi-decent OS would have anyway)... Admittedly I have never compromised my integrity by using/programming it, so I am willing to be corrected. And yes, I know about POSIX compatibility, but so is Linux, and it's different enough from Unix to be damned annoying. -- Dave
[-- Attachment #1: Type: text/plain, Size: 758 bytes --] On Sun, Feb 3, 2019 at 5:08 PM Dave Horsfall <dave@horsfall.org> wrote: > > My vague (and rough) recollection is CP/M -> DOS -> Windows. > "Windows" == Win95 -- which was a user Interface spec the kernel died IBM CP-DOS -> OS/2 --\ \ ---> NT OS-2 -> NT/WIN ....... Today's Windows CMU Mach --\ / ---> Mica -/ DEC VMS --/ When Cutler did Mica and then NT OS-2 he did not care what the user interface was. Mica was a pure uk and NT OS-2 was also, but by the time of the product it became a hybrid. Putting a different user interface, be it DOS, OS/2, Unix, VMS or Windows was in the kernel design. Clem ᐧ [-- Attachment #2: Type: text/html, Size: 2570 bytes --]
On 4 Feb 2019 09:07 +1100, from dave@horsfall.org (Dave Horsfall): > My vague (and rough) recollection is CP/M -> DOS -> Windows. CP/M is (was?) to MS-DOS roughly as UNIX is to Linux (the overall system, not referring to just the kernel); a source of inspiration, but not a direct ancestor. Then let's not get into the Windows / OS/2 / Windows NT confusion, product line splits/merges and rebranding. IIRC, at least until Windows 3.0 (1990), and possibly until Windows 95 when Microsoft did their best to hide the troubled history, Windows applications were _expected_ to ultimately rely on the old-style MS-DOS API for basic operating system services like file management, and could choose to (or were expected to) call those APIs directly instead of going through the Windows API. For a long time, Windows was just a fancy (some would almost certainly say overrated) graphical shell. I, too, would like to see some reference or at least justification for the claim that Microsoft would not have created Windows had it not been for Unix. As I recall, Visi On did use some Unix as its development platform; and Microsoft Windows was created in response to Visi On; but that's the only obvious causal connection between Unix and Windows that I can see, and it's a tenuous one at best. -- Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se “The most dangerous thought that you can have as a creative person is to think you know what you’re doing.” (Bret Victor)
On Mon, 4 Feb 2019, Dave Horsfall wrote:
> On Mon, 4 Feb 2019, Greg 'groggy' Lehey wrote:
>
>> Without Unix, Microsoft would not have created Microsoft "Windows".
>
> I'd like to see some evidence for that; without Unix, what would we be
> running now? I doubt whether it would've been Linux, there being no
> inspiration for it...
>
> My vague (and rough) recollection is CP/M -> DOS -> Windows.
>
>> Even it has roots in Unix.
>
> Only inasmuch as it has directories, users, and permissions (which any
> semi-decent OS would have anyway)... Admittedly I have never compromised my
> integrity by using/programming it, so I am willing to be corrected.
>
> And yes, I know about POSIX compatibility, but so is Linux, and it's
> different enough from Unix to be damned annoying.
>
> -- Dave
>
Keep in mind that the MS-DOS 2 "handles" API for file access is based
*directly* on Xenix, and replaced the MS-DOS 1 "FCB" API borrowed from
CP/M.
-uso.
[-- Attachment #1: Type: text/plain, Size: 1331 bytes --] On Sunday, February 3, 2019, Steve Nickolas <usotsuki@buric.co> wrote: > On Mon, 4 Feb 2019, Dave Horsfall wrote: > > On Mon, 4 Feb 2019, Greg 'groggy' Lehey wrote: >> >> Without Unix, Microsoft would not have created Microsoft "Windows". >>> >> >> I'd like to see some evidence for that; without Unix, what would we be >> running now? I doubt whether it would've been Linux, there being no >> inspiration for it... >> >> My vague (and rough) recollection is CP/M -> DOS -> Windows. >> >> Even it has roots in Unix. >>> >> >> Only inasmuch as it has directories, users, and permissions (which any >> semi-decent OS would have anyway)... Admittedly I have never compromised >> my integrity by using/programming it, so I am willing to be corrected. >> >> And yes, I know about POSIX compatibility, but so is Linux, and it's >> different enough from Unix to be damned annoying. >> >> -- Dave >> >> > Keep in mind that the MS-DOS 2 "handles" API for file access is based > *directly* on Xenix, and replaced the MS-DOS 1 "FCB" API borrowed from CP/M. > > And also don't forget that Xenix had the largest UNIX installed base measured by the number of machines it was installed on. People talking about BSD and System V in the 80s, but it was Xenix that ruled on micros. So at the time Microsoft offered both UNIX and MS-DOS. --Andy [-- Attachment #2: Type: text/html, Size: 2003 bytes --]
On Mon, Feb 04, 2019 at 09:07:52AM +1100, Dave Horsfall wrote: > On Mon, 4 Feb 2019, Greg 'groggy' Lehey wrote: > > >Without Unix, Microsoft would not have created Microsoft "Windows". > > I'd like to see some evidence for that; without Unix, what would we be > running now? I doubt whether it would've been Linux, there being no > inspiration for it... > > My vague (and rough) recollection is CP/M -> DOS -> Windows. Yep. > >Even it has roots in Unix. > > Only inasmuch as it has directories, users, and permissions (which any > semi-decent OS would have anyway)... Admittedly I have never compromised my > integrity by using/programming it, so I am willing to be corrected. > > And yes, I know about POSIX compatibility, but so is Linux, and it's > different enough from Unix to be damned annoying. It's what you are used to. I haven't tried it but apparently Microsoft has implemented the Linux syscall layer that you can just drop a distro on top of windows and the binaries work.
On Sun, 3 Feb 2019, Larry McVoy wrote:
> It's what you are used to. I haven't tried it but apparently Microsoft
> has implemented the Linux syscall layer that you can just drop a distro
> on top of windows and the binaries work.
I've used it with Debian. Add an X server and PulseAudio server on the
Windows side and it's really not bad.
-uso.
> without those two we'd all be running M$ Windoze
Apropos of which, I complained to Walter Isaacson about his
writing them out of "The Innovators"--Turing Award, National
Medal of Technology, Japan Prize and all. I suppose I should
not be surprised that he didn't deign to answer.
Doug
On 2/3/19, Clem Cole <clemc@ccc.com> wrote: > > IBM CP-DOS -> OS/2 --\ > \ > ---> NT OS-2 -> NT/WIN ....... > Today's Windows > CMU Mach --\ / > ---> Mica -/ > DEC VMS --/ I think that bottom part should read: CMU Mach --\ ---> VAXeln --> Mica DEC VMS --/ Cutler took the concept of a microkernel from CMU Mach and combined it with design concepts he had used in VMS to create a real-time OS for the VAX called VAXeln. DEC had several proposed machine architectures for a RISC-based successor to VAX. The one from Cutler's DECwest was called PRISM. Mica was the microkernel-based OS for PRISM. The intent was to build VMS and UNIX personality layers on top of the Mica microkernel. PRISM was cancelled in favor of Alpha, and that led to Cutler's departure for Microsoft. > When Cutler did Mica and then NT OS-2 he did not care what the user > interface was. Mica was a pure uk and NT OS-2 was also, but by the time of > the product it became a hybrid. Putting a different user interface, be it > DOS, OS/2, Unix, VMS or Windows was in the kernel design. As with Mica the original design was for various personality modules (DOS, OS/2, Unix, whatever) to be layered on top of the microkernel. The NT microkernel internals looked very familiar to VMS weenies such as I. Cutler was able to resist attempts to smear the layers by putting hooks etc. in the microkernel, but over time the clean break between the kernel and Windows has been muddied. CMU Mach was the microkernel for Jobs's NeXT OS, and with BSD Unix layered on top, was the basis for Apple's OS X. OS X still uses the Mach object file format, MACH-O. -Paul W.
[-- Attachment #1: Type: text/plain, Size: 1760 bytes --] Indeed, without Unix there wouldn't have been the same rise of Mach, or the drive to make a portable VMS, as there wouldn't be a C either. Many of the leaked internal tools to build NT reflect that all the back office stuff was on Xenix and VMS. Just as you can find mentions of emacs in the makefiles for NT, and how their life would be in jeopardy for changing the tab indentions. Unix had such an incredible impact on the market that without it everything would be different. Without Xenix micros would have continued to be snubbed by the high end crowd depriving that critical jump from machines that cost more than a large house to personal space. What would be the portable OS to rule them all? TripOS is the best I can imagine. BCPL everywhere. Get Outlook for Android On Mon, Feb 4, 2019 at 6:34 AM +0800, "Clem Cole" <clemc@ccc.com> wrote: On Sun, Feb 3, 2019 at 5:08 PM Dave Horsfall <dave@horsfall.org> wrote: My vague (and rough) recollection is CP/M -> DOS -> Windows. "Windows" == Win95 -- which was a user Interface spec the kernel died IBM CP-DOS -> OS/2 --\ \ ---> NT OS-2 -> NT/WIN ....... Today's WindowsCMU Mach --\ / ---> Mica -/DEC VMS --/ When Cutler did Mica and then NT OS-2 he did not care what the user interface was. Mica was a pure uk and NT OS-2 was also, but by the time of the product it became a hybrid. Putting a different user interface, be it DOS, OS/2, Unix, VMS or Windows was in the kernel design. Clemᐧ [-- Attachment #2: Type: text/html, Size: 5053 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1123 bytes --] On 2019-Feb-03 15:58:39 -0500, Clem Cole <clemc@ccc.com> wrote: >Portability was designed as an >>import<< idea, and they tried to keep you >from exporting by getting you to use 'value add.' This is definitely the approach used by FSF/GNU - witness gcc and bash. On 2019-Feb-04 09:07:52 +1100, Dave Horsfall <dave@horsfall.org> wrote: >And yes, I know about POSIX compatibility, but so is Linux, and it's >different enough from Unix to be damned annoying. IMO, POSIX wouldn't exist without Unix. On 2019-Feb-04 03:57:40 +0000, Jason Stevens <jsteve@superglobalmegacorp.com> wrote: >What would be the portable OS to rule them all? TripOS is the best I can imagine. BCPL everywhere. That was my thought as well, though TripOS started in 1976 so it's likely that the development team were aware of Unix and make have taken some of its ideas onboard. That said, Unix was not portable to start with. I think that the important parts were that the source was readily available within academia, it was written in a high level language and it was small enough to be understood. -- Peter Jeremy [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 963 bytes --]
On Mon, 4 Feb 2019, Peter Jeremy wrote:
> On 2019-Feb-03 15:58:39 -0500, Clem Cole <clemc@ccc.com> wrote:
>> Portability was designed as an >>import<< idea, and they tried to keep you
>> from exporting by getting you to use 'value add.'
>
> This is definitely the approach used by FSF/GNU - witness gcc and bash.
I think the term is "Embrace, Extend, Exterminate" <dalek.jpg>
-uso.
Ken invented *NIX(up to edition 3 he wrote 100% of the sources), ed(before regexp qed), b (and therefore most of c).
Ken is one of the most underrated persons of all. I hope the day will come, humankind will show respect !
At 3 Feb 2019 20:24:34 +0000 (+00:00) from Dave Horsfall <dave@horsfall.org>:
> 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
[-- Attachment #1: Type: text/plain, Size: 1013 bytes --] On Mon, 4 Feb 2019, Steve Nickolas wrote: > I think the term is "Embrace, Extend, Exterminate" <dalek.jpg> I heard it as "Embrace, Extend, Extinguish"; witness their attempt to take over PPP (which eventually had to accommodate their "extensions"), and Usenet before that, which thankfully failed, because they wanted a central authority. How the hell do you think that Usenet flourished? It was an utter anarchy, that's why! And the marketoid control-freaks hated it... If you look carefully at PPP, you will see certain negotiations which ∆ simply don't belong at that level (DNS etc). Cough MS/CHAP cough... If you want to talk PPP to an NT server, well, you'd better be prepared to accommodate their "extensions". And to those bods who think we're bashing M$, well, there might be a damned good reason for it (some of us here go back a *long* time, so you might have to brush up on your history, and grow out of your short pants). -- Dave, who used to be known as "Fowler Ware" on aus.flame
On 2019-02-04 2:59 AM, Steve Nickolas wrote: > On Mon, 4 Feb 2019, Peter Jeremy wrote: > >> On 2019-Feb-03 15:58:39 -0500, Clem Cole <clemc@ccc.com> wrote: >>> Portability was designed as an >>import<< idea, and they tried to >>> keep you >>> from exporting by getting you to use 'value add.' >> >> This is definitely the approach used by FSF/GNU - witness gcc and bash. > > I think the term is "Embrace, Extend, Exterminate" <dalek.jpg> Never heard that one. A Dalek would have a lot of trouble with the Embrace part. > > -uso. >
On 2/3/19 7:57 PM, Jason Stevens wrote:
> What would be the portable OS to rule them all?
TOPS-20 re-written in Mesa
That should make some people's heads explode.
The technology was there..
> Ken wrote ... ed(before regexp ed)
Actually Ken wrote a regexp qed (for Multics) before he wrote ed.
He wrote about it here, before the birth of Unix:
Programming Techniques: Regular expression search algorithm
Ken Thompson
June 1968 Communications of the ACM: Volume 11 Issue 6, June 1968
This is the nondetermistic regexp recognizer that's been used
ever since. Amusingly a reviewer for Computing Reviews panned
the article on the grounds that everybody already knew how to
write a deterministic recognizer that runs in linear time.
There's no use for this slower program. What the reviewer failed
to observe is that it may take time exponential in the size of
the regexp (and ditto for space) to make such a recognizer.
In real life for a one-shot recognizer that can easily be the
dominant cost.
The problem of exponential construction time arose in Al Aho's
egrep. I was an early adopter--for the calendar(1) daemon. The
daemon generated a date recognizer that accepted most any
(American style) date. The regular expresssions were a couple
of hundred bytes long, full of alternations. Aho was chagrinned
to learn that it took about 30 seconds to make a recognizer
that would be used for less than a second. That led Al to the
wonderful invention of a lazily-constructed recognizer that
would only construct the states that were actually visited
during recognition. At last a really linear-time algorithm!
This is one of my favorite examples of the synergy of having
sytems builders and theoreticians together in one small
department.
Doug
On Mon, Feb 04, 2019 at 06:42:08PM -0500, Doug McIlroy wrote:
> This is one of my favorite examples of the synergy of having
> sytems builders and theoreticians together in one small
> department.
Amen to that. One of my profs was Udi Manber, a super deep theory guy.
I dragged him into systems and he did great.