Slashdot Mirror

Containers are a good mitigation, but see https://research.swtch.com/ver... from Russ Cox for an overview of the underlying (really evil!) problem. My own views? https://leaflessca.wordpress.c... (and others)

Windows NT was designed by Dave Cutler, who chose C as the language for the NT kernel. It was the most significant impact of UNIX on NT.

Cutler also designed VMS, and likely had deep familiarity with "Digitial Command Language" (DCL) that is a well-built and powerful command processor itself (if you like writing your scripts in FORTRAN).

Cutler wanted to "get UNIX." Why he allowed a product as shockingly poor as cmd.exe to be written for the NT command shell simply baffles me.

The cmd.exe shell is described as a serial killer by Microsoft employees.

I also disagree with elevating BASH. Steven Borne disliked C, and retrofitted ALGOL on it, not only for the parsing syntax that became BASH, but also on top of the C compiler itself.

Cutler had a chance to see source code for multiple OS implementations and their parsers: RSX11, UNIX sh/csh, DEC DCL, and likely many more. How cmd.exe could have emerged from his group is quite simply beyond me.

Integrated circuits weren't invented until the late 1960's

That's not really true, the AGC was using IC gates around 1962 already.

Perhaps they're thinking of MSI, which first showed up in the late 1960's; SSI predated that.

Although this video doesn't mention it the Megaprocessor is actually a clone of the 6502, based on the reverse engineering of that chip which was done by the visual6502 people. Actual discrete transistor designs were a bit more streamlined to reduce the discrete component count.

Which is peculiar because the 6502 should have not nearly as many as 40k transistors.

And, in fact, the 6502 had more like 3.5k transistors; the MOnSter 6502, which is what the "clome of the 6502" person was actually thinking of, has about 4300 transistors.

Actually, that would be ALGOL

.

That problem was solved, and there's a handy open source project aimed at full text indexing local source code for fast search based on it: http://swtch.com/~rsc/regexp/r...

The original was kinda buggy for me, but this fork is working well: https://github.com/junkblocker...

Go was developed in large part by Rob Pike who has a long history of concucrrency programming going back to Plan 9 from Bell Labs and earlier.

Some of his more interesting papers about concurrency are:

http://swtch.com/~rsc/thread/n... (The Newsqueak Programming Language)
http://swtch.com/~rsc/thread/n... (Newsqueak Implementation)
https://www.usenix.org/legacy/... (A Concurrent Window System)

You can even see some hints of what was to come in his paper outlining the design of the Blit terminal for Unix:
http://doc.cat-v.org/bell_labs...

Go was developed in large part by Rob Pike who has a long history of concucrrency programming going back to Plan 9 from Bell Labs and earlier.

Some of his more interesting papers about concurrency are:

http://swtch.com/~rsc/thread/n... (The Newsqueak Programming Language)
http://swtch.com/~rsc/thread/n... (Newsqueak Implementation)
https://www.usenix.org/legacy/... (A Concurrent Window System)

You can even see some hints of what was to come in his paper outlining the design of the Blit terminal for Unix:
http://doc.cat-v.org/bell_labs...

AFAIKT Aura is a more than just a UI Toolkit, it's a complete Window Manager.

You are aware, that - at least in sane computer system designs - this is mostly the same thing?

Does this mean Plan 9 from User Space (an implementation of Plan 9 tools and libraries for UNIX and Linux) will be GPLv2 licensed too now?

You know.. I've seen plenty of real security research that says that the RdRand RNG is actually very good and produces very high quality output.

Here's just one set of results showing that the output is truly random, so-called NSA "backdoors" or not:
http://smackerelofopinion.blogspot.com/2012/10/intel-rdrand-instruction-revisited.html

You know what *ISN'T* truly random? When guys just like you who are all paranoid about the NSA went and broke OpenSSL in Debian for over 2 years in the name of "fixing" code: http://research.swtch.com/openssl

Oh, and are you and the petitioners going to be intellectually honest and demand the complete removal of Via Padlock support from Linux, or is this only an anti-Intel fanboy rant thinly disguised as "sticking it to the man?"

Guess what the NSA loves: When lemmings throw away real security solutions because they think the NSA engineers every transistor in every piece of hardware. Go ahead and try to put together your own crypto solutions, the NSA *wants* you to do that, because they are a hell of a lot smarter than you are.

I think he's referring to when Debian did exactly this to their openssl library.

It took two years for anyone to notice.

So you're saying that, in order to ensure I never fall foul of being sued for defects in the software I use to supply services to my customers I need to audit every line of the open source software in my solution. Nah, I think I'll find a proprietary supplier that is prepared to give me a warranty.

To an extent, this happens already. This is the main reason why companies like Red Hat can charge people a lot of money for software that can be obtained for free on the Internet.

This idea that FOSS is "the higher standard" because of the possibility of review is pie in the sky, by the way. In principle it is possible to review FOSS, in practice, it is often impossible due to the complexity of the software. And at least one very serious bug has been caused by downstream people reviewing software and applying an incorrect patch.

One of the reasons context-free searches isn't more prevalent in everyday computing is the increase in complexity and thus computation resources needed to process it. If regular grammar was linear, then context-free is closer to linearithmic (n*log(n)).

Regular grammar searches are linear, or they are in a proper implementation. In addition, LALR parsers also run in linear time. There is an increased space requirement; regular grammars are equivalent of finite-state automata, and therefore require constant state, whereas a context-free grammar is equivalent to a pushdown automata, or a FSA with an extra stack. I couldn't find any sources on the space requirements of an LALR or an LR parser, but I should probably note that a linearly-bounded automaton requires O(n) space and is more powerful than a pushdown automaton, so the space requirements are likely less than linear for an LALR parser.

Seconded. You don't even need to be actually running Plan 9 either: http://swtch.com/plan9port/

Or just run Plan 9 with whatever *nix GUI floats your boat: http://swtch.com/plan9port/

IMHO, the coolest Plan 9 stuff is not graphical anyway.

The pthreads model is a pain to program with. Have a look at Russ Cox's summary of CSP-style multiprocessing. Google's Go uses it, as did Bell Labs' Alef, Limbo, etc.

I'm sorry you're uneducated about Perl's notoriously poor regex implementation, that has unfortunately become the standard in most languages. Reference: http://swtch.com/~rsc/regexp/regexp1.html

ALL of it is user facing. That's the very point of an API. The user is the developer.

Yes, developers are "users" of APIs. But any "developer" worthy of that moniker has an assumed baseline of specialized domain knowledge *far* greater than any 5 or 7 year old.

Yes, there can and should be will be high-level framework APIs that mask inner complexity for straightforward use cases. The open source web world is littered with such things. See "idiomatic" Ruby and Python libraries that wrap native (OS/REST/etc.) counterparts. See what MS did with C#-based APIs that wrap many of the hellish old direct Win32 calls. Sometimes an early design is refined by experience into a simpler one (cf. Plan9's dial() API versus bind/accept/listen).

But sometimes you've just got to give access right down to the metal -- the problem domain is truly complex, and oversimplification of that simply makes users' lives much, much worse.

Most languages still handle concurrency very badly. C and C++ are clueless about concurrency.

c itself isn't aware of concurrency, but so what? that doesn't mean that a program written in c can't be aware of concurrency. for example, the bell labs thread library manages threads and procs and provides channels for locking and communication between them. the syntax can get clumsy if you aren't careful, but that's the only problem i can think of

Go [... is] intended for server-side processing.

what makes you think that? it's a general purpose language

here's a ton of stuff that might interest you: http://swtch.com/~rsc/thread/

How do you make a concurrent process in [...] C?

with the plan 9 thread library. it has channels similar to those in go for synchronization

http://swtch.com/plan9port/man/man3/thread.html

That's a really unfair and inaccurate summary of how it went down.

Here's an article arbitrarily picked from googling "valgrind ssh". It checks out, follow the link to the openssl-dev list archive.

All parties involved, including the openssl people, made the mistake of thinking Valgrind was more of a cryptography programming expert. The maintainer did everything he could.

Any discussion of parallel programming would benefit from have read and understood the resources and history covered by Russ Cox at http://swtch.com/~rsc/thread/

This is sounding more and more like Plan Nine from User Space.

http://en.wikipedia.org/wiki/VX32

which enables the User Mode Plan 9 - http://swtch.com/9vx/

I use venti, an archival storage system originally develloped for Plan 9 from Bell Labs and now available on a host of other systems via Plan 9 from User Space. Venti is strictly archival: it stores blocks permanently. This storage is organized into "arenas", or pools of a fixed size. When one arena fills up, it is sealed, never written to again, and the system starts dumping bits into the next one.

Primary storage for my venti system is a pair of mirrored SATA disks. Yes, magnetic disks can fail, but with mirroring they're still cheap enough to almost certainly be your first line of defense. When an arena fills up, I burn it to CD (by default, they're 512MB each) and mail that to a friend three time zones away. If my house burns down, I can recreate everything up through the last arena by basically dd'ing the contents of those CDs to a new disk.

Using a real archival system has other neat benefits, too. You don't have to worry about whether you saved the right version of something, or how to organize different versions over time; it's all automatic. I've used this for "work stuff" for a long time with very good results; after my last laptop hard drive crash, I've started using it for personal stuff (although I haven't made that quite as automatic yet). I can now "cat /n/dump/2008/0712/usr/a/src/cmd/ngcscatgen.c" to see the version of that file as I was working on it over the summer. Pretty nice.

threads needn't be hard, it's just that most of the popular models for working with them suck. check out C. A. R. Hoare's work with CSP and some of the modern languages influenced by, or modeled on, it. my personal favorite's Limbo, but there's a good library for C using the model, and it shows up in places like Occam and Erlang's process model. the right concurrency model just makes a world of difference.

you're still right that they're not magic bullets and they have a host of new issues to consider (although they make a whole host of other ones go away, and can be much friendlier in the right model).

Actually some of my scripts run on linux ( a total of 7 different distro / major release combinations ), solaris, hp-ux, aix and cygwin. good old raw sh is about the only thing that hasn't caused cross platform issues on these (yes, including perl).
As for your pathological case, it only makes the point that shell scripting is a Bad Idea for *that* case. Go brush up your formal logic, showing 'There Exists' does not prove 'For All' - e.g. for a counter example, go look at http://swtch.com/~rsc/regexp/regexp1.html - there, since we have a pathological case where perl is much worse than awk, perhaps we should advise that perl is a Bad Idea for anything other than simple single-platform scripts...

I've written a decent amount of Erlang. I can do it.

Point is, why would I want to?

Given the gross misunderstandings demonstrated in your comments, you may have written some Erlang, but you sure as hell didn't understand it

Done, in Ruby. Took a weekend. I'm polishing it now.

You wrote a SMP-capable micro-stack green thread scheduler in Ruby, over the weekend? It supports transparent multi-node messaging?

Color me impressed. I've seen other implementations, such as libthread, but they were written in C, using a fair bit of OS-specific assembly to support micro-stack green threads, and didn't support multi-node messaging -- just process support

If you pulled this off in Ruby, which doesn't even -support- native threads, I'll be seriously impressed -- especially given the lack of understanding inherent in your previous comments. Perhaps I misjudged you

Or, more likely, you're just another know-it-all shithead who implemented 1% of the solution to a problem you don't even understand, and are now trumpeting it on the blogowww-twittersphere.

Get a better programming language.
And if don't like the taste of that one (what? Dennis Ritchie & Brian Kernighan not good enough for you!) there are other CSP languages available (what? Sir Charles Hoare not good enough for you!)

Seriously, this problem has been solved for 30 years.

That's basically what I do, although I use drawterm instead because my stuff is on a Plan 9 box.

Packard Bell did machines with mercury delays & CRT storage in the 1960s

http://research.swtch.com/2008/04/computing-history-at-bell-labs.html

Comments on the Cox paper from the Haskell regex implementer. Another response, from the Perl side.

I'll start with an Obligatory quote.

Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems. --Jamie Zawinski, in comp.lang.emacs

I'll close with a somewhat depressing fact: Regular expression and string processing can be done quickly and efficiently (and was done that way back decades ago, with grep and awk), but is actually done in a horribly inefficient way in all modern/popular programming language regexp engines.

It is already free/open source, under the Lucent Public License (assuming you can bring yourself to run non-GPL code, I know it's hard for some people here). Plan 9 Port will allow you to run Venti on Linux, but ideally you just download Plan 9 and install it on your file server; you can then use v9fs to access Plan 9's fileservers.
I do my work natively under Plan 9, so I don't have much experience using Venti and Linux.

Communication channels are the right way to tackle this. Bell Labs had the right idea. See http://swtch.com/~rsc/thread/ and the slides at http://www.cs.kent.ac.uk/teaching/07/modules/CO/6/31/slides/ if you have an inquisative mind. For the slides, read them in this order: motivation.pdf -- just pages 1-39, basics.pdf, applying.pdf, choice.pdf, replicators.pdf, protocol.pdf, shared-etc.pdf.

Indeed. A language built around highly-efficient message-passing concurrency (rather than shared state) was seen as the way forward the last time the computing world was getting excited about using large-scale parallelism to increase processing power. Bell Labs also implemented the same kind of model when they started taking concurrency seriously. It's an idea that's been percolating in the background for many years now, but has never quite seemed to hit the mainstream (too many programmers wedded to sequential programming and the "small" jump from there to shared-state concurrency). Hopefully this time around, the idea will stick. Erlang certainly seems well-placed to gain mainstream acceptance, especially with Joe Armstrong's new PragProg book out, and the growing popularity of ErlyWeb.

I think Plan 9's Venti probably does what you want. There is a version which runs on Linux; see Plan 9 From Userspace for details.

Plan 9 from User Space (aka plan9port) is a port of many Plan 9 programs from their native Plan 9 environment to Unix-like operating systems.
supported systems

        Linux (x86, x86-64, PowerPC, and ARM), FreeBSD (x86), Mac OS X (x86 and Power PC), NetBSD (x86 and PowerPC), OpenBSD (x86 and PowerPC), SunOS (Sparc).

http://swtch.com/plan9port/

The Transputer took its model from Tony Hoare's CSP. You're right. Channels are the correct way to do this kind of thing instead of semaphores, etc. You can do them in C these days with things like LibTask.

I know about Venti, I'm running it. Score 1 for glenda (or rather 723cae95e0e6f0f8ecebc64ab41c4ece93c60362)

You don't even have to be running Plan 9. The Plan9 port has venti stuff

for instance backing up non-plan9 file systems
http://swtch.com/plan9port/man/man8/vbackup.html

or just plain venti itself. http://swtch.com/plan9port/man/man7/venti.html

Russ just did a new version today with better performance.

http://groups.google.com/group/comp.os.plan9/brows e_thread/thread/88a9b4cf365e8246/5c4c506b1c5fc92d

I know about Venti, I'm running it. Score 1 for glenda (or rather 723cae95e0e6f0f8ecebc64ab41c4ece93c60362)

You don't even have to be running Plan 9. The Plan9 port has venti stuff

for instance backing up non-plan9 file systems
http://swtch.com/plan9port/man/man8/vbackup.html

or just plain venti itself. http://swtch.com/plan9port/man/man7/venti.html

Russ just did a new version today with better performance.

http://groups.google.com/group/comp.os.plan9/brows e_thread/thread/88a9b4cf365e8246/5c4c506b1c5fc92d

Anyone interested in multiple threads of execution should be familiar with the excellent information presented by Russ Cox on Bell Labs and CSP Threads. This model of threading is far easier to reason about than what most of the world mucks around with, and is available to Unix as part of the Plan 9 from User Space project as libthread.

Anyone interested in multiple threads of execution should be familiar with the excellent information presented by Russ Cox on Bell Labs and CSP Threads. This model of threading is far easier to reason about than what most of the world mucks around with, and is available to Unix as part of the Plan 9 from User Space project as libthread.

Plan 9 has such a central key repository. It's called Factotum, and the best description is the USENIX paper. It has been ported to other UNIX-likes by the plan9port project.

For Lunix :
http://swtch.com/plan9port/man/man1/secstored.html
http://swtch.com/plan9port/man/man4/factotum.html

in which you can store *any* data, factotum will get the individual keys out for you

For Lunix :
http://swtch.com/plan9port/man/man1/secstored.html
http://swtch.com/plan9port/man/man4/factotum.html

in which you can store *any* data, factotum will get the individual keys out for you

different grep commands such as grep, egrep and fgrep which clearly shows the advantages that Perl has over grep.

I wonder if the author listed a significant disadvantage of Perl: it is very slow compared to awk and grep. For example: "Notice that Perl requires over sixty seconds to match a 29-character string. The other approach, [used by grep and awk], requires twenty microseconds to match the string. That's not a typo."

There's nothing like specialized Unix utilities, refined over thirty years with some GNU innovation thrown in, to deliver lightning fast speed.

The guys over at Bell Labs developed Venti as a part of their Plan9 Operating System. If you are not adventurous enough to install Plan9, they have a great set of ports called Plan9 Port that has most of the exciting bits of Plan9 for other *nix like Operating Systems including Linux and Max OS X. Venti is an archival storage server, utilities and filesystem. It works with both magnetic and optical media.

You could use Sam - written with remote editing across slow serial lines in mind.

Or import the remote file system in using srvssh in plan9 or p9 in p9port and use Acme

Plan9port is a port of the Plan 9 userland to Linux / BSD / OSX

You could use Sam - written with remote editing across slow serial lines in mind.

Or import the remote file system in using srvssh in plan9 or p9 in p9port and use Acme

Plan9port is a port of the Plan 9 userland to Linux / BSD / OSX