Slashdot Mirror

To help answer your question (and it's a damn good one), I'd make two observations:

1. It's more than just one great idea or a collection of great ideas. It's all of those and a synergy between them. To beat it you have to more than replicate, but surpass that kind of synergy. It's a good reason why people have preferred to build on the core ideas rather than replace them.
2. Very few real resources are being put into OS research any more. Rob Pike put it best, but in a nutshell, there's no money in it, and it's really hard stuff. Sure, you may fantasize about an OS that allows, say, manipulation of data by pointing at images in the air, but if it can be realized, then it'll be an interface to a UNIX-like OS, because the cost of developing something completely different on the basis of an interface is prohibitive in money and man-hours, at least in the prevailing climate.

Hope that helped some, I appreciate your dilemma though, I think about it a lot myself.

The top of the image says its written by "Brian K White".. does anyone else think that maybe the people writing the article searched for something like "Brian K code" in an attempt to find source code related to Unix?

So, we used to have little dumb terminals that talked to the big smart backend. Then computer became cheaper and we had Personal Computers, but we have to manage and distribute all these updates and it's a real pain and it sometimes destroys your computer during the upgrade/install process. Now we can swing the pendulum back towards the Network Computer a little more.

This isn't a new idea. Software companies like MS would love to sell you a subscription to MS Office which you renew and they in turn patch and maintain the software on your company's server or on the MS servers. It's a neat idea for sure. Companies like Novel have made some interesting claims about Network Computers.

There is also the whole Plan9 type of mentality too.

Plan 9 provides mk, as a replacement for make. There are unix ports available. Since this isn't really a `better make' story, I'll not post more, but the papers and manual pages (yes, actually used in Plan 9) are often interesting reading regardless.

Plan 9 provides mk, as a replacement for make. There are unix ports available. Since this isn't really a `better make' story, I'll not post more, but the papers and manual pages (yes, actually used in Plan 9) are often interesting reading regardless.

Plan 9 provides mk, as a replacement for make. There are unix ports available. Since this isn't really a `better make' story, I'll not post more, but the papers and manual pages (yes, actually used in Plan 9) are often interesting reading regardless.

With Plan 9.

You are right.

Even the word UNIX is not exclusively for the operating system we all know and love (or hate!)

When NCR was part of AT&T, I was one day called by my manager because he was alerted that some company selling "pesticides" was using UNIX as a trademark to its product.

Turns out that UNIX was trademarked by some French fungicide company, as Dennis Ritchie has detailed.

Trademarks can be "duplicated" across product boundaries.

You are right.

Even the word UNIX is not exclusively for the operating system we all know and love (or hate!)

When NCR was part of AT&T, I was one day called by my manager because he was alerted that some company selling "pesticides" was using UNIX as a trademark to its product.

Turns out that UNIX was trademarked by some French fungicide company, as Dennis Ritchie has detailed.

Trademarks can be "duplicated" across product boundaries.

Of programming books, I like Kernighan & Ritchie's The C Programming Language (_K&R C_) best, mainly because it's short. But my favorite tome is Bruce Schneier's Applied Cryptography. It's focused on encryption, and security, but that's a great way to make the basic principle of programming implicit in one's programs: write a program that does what you expect, rather than what someone else can get it to do instead. And when you skim the 80% that is purely cryptological (though never cryptic ;), it's only 57% as big as _K&R C_.

I hope the moderators mod this up as interesting, because it certainly is. Very, very naive, but interesting none the less. Such a question implies that you are either a teenager or an ivory tower researcher ;-) I hope you manage to keep your idealism.

The system you describe is a distributed operating system. Your hypothetical system has been contemplated by many researchers, perhaps most famously with AT&T's Plan 9. The problem with this, as with all other distributed operating systems, is that is still *very* theoretical and likely will be for some time.

For such a system, you will need a network connecting the two computers. I am assuming you want to go with commodity hardware for price reasons. To get adequate performance for modern graphics cards, as well as to leave room for new cards debuting in the next couple of years, you will need an extremely high speed physical layer. A 1Gbps ethernet bus would be the bare minimum now, and you would likely need to go up to 10Gbps to get good perfromance for today's high end cards or the cards of the next few years. A 1Gbps network is just becoming affordable for high end consumers, while a 10Gbps network is still far too expensive for consumers and likely will be for several years to come.

Next comes building the "graphics card emulating computer". While graphics cards are miniature PCs in an abstract sense, in actual implementation they are very different. I won't claim to fully understand the design of a modern graphics card, but the GPU processor and data bus are highly optimized for graphics handling tasks. You would therefore likely need a top of the line general purpose motherboard and CPU to emulate a modern card's performance. Once again, not an inexpensive thing.

Next come software issues. Assuming you actually hope for more than research lab adoption, you cannot force vendors to rewrite all of their low-level graphics routines. Concordantly, you will need to provide an emulation layer that makes X11 (or whatever graphics system(s) you target) think your graphics computer is just another onboard video card. This will likely require at least a kernel hack, if nothing else. You will probably also want to hack on the drivers of the network cards you use, to improve their performance (mostly reduce latency). This is probably the easiest of your software challenges.

For network transport, TCP will certainly be overkill. If you want to make this friendly to existing network protocols, you will have to design a UDP-based protocol, but even UDP might cause a performance hit. For best performance, you will likely end up ditching compatibility with TCP/IP type networks and programming directly to the data link layer. In any case, designing a quality protocol of this type is an extremely difficult task! Don't expect to get it right on the first few tries.

Last of the software challenges, the software on the graphics computer will have to be customized heavily to emulate the high performance operations provided by a graphics card. Unless you can manage to find an expert in 3D accelerated graphics hardware who is *not* under an NDA from one of the graphics card companies, this will require a lot of research.

Finally come non-technical hurdles. First, you have to worry about competing implementations. If your project builds steam, your team will likely start to face competition. This will inevitably lead to incompatibilities, which will have to be straightened out by some standards process. Add a couple of years to the total time for that.

Even if we assume that after years of research such a system is built and everyone actually standardizes on it, it will likely cost *much* more per unit than an equivalent graphics card. I just don't think that "freedom from lock-in" will be enough to successfully market this to John Q Public, and without that support, even geeks may find it hard to afford such a setup.

In conclusion, what you suggest is

Snake oil.

Read why here. Get the info in Claude Shannon's own words here.

I was just thinking the same. I personally think of crosshurd. This lets you choose between several kernels (4 at the moment) for a lot of architectures (12 at the moment). This should be 1337 enough for anyone... However, if everything else fails, what about good old Plan 9?

i think you're right. Hurd was started because of the desire for a free vaguely unix-like OS. linux took care of that. Hurd's architecture was modeled after Plan 9 (except not as good), because Plan 9 wasn't free or open. that's taken care of, too. i'm surprised at how much attention Hurd still gets. just go work on the real things.

I always wanted to mess around the code on a simple, yet an operating system you could DO something with.

• support for variable width fonts. this would require some finessing tabs, and perhaps an easy way to switch to a fixed width font. while you're at it, support unicode and other fat fonts.
• ability to search for text (with a regexp, of course) in the output window.

For a start, they left out the S programming language (started in 1976), for which John Chambers won the ACM Software Systems Award. This, and its Libre dialect R (thanks to Robert Gentleman and Ross Ihaka at University of Aukland), are in daily use by folks who have to write programs to use data.

For a start, they left out the S programming language (started in 1976), for which John Chambers won the ACM Software Systems Award. This, and its Libre dialect R (thanks to Robert Gentleman and Ross Ihaka at University of Aukland), are in daily use by folks who have to write programs to use data.

The Phd: an exercise in self-aggrandizing behavior with little application to the real world.

In the event you actually research or do something worthwhile your expertise is basically a very tiny narrow slice of the pie in your discipline in which you possess astonishing depth, and you are likely no more knowledgeable about the rest of your field than a masters candidate.

I've worked with a number of Phd candidates in computer science, chemical engineering, history, and life sciences, and then EXPECT (yes, I said expect) one of two things to happen when they graduate:

1. A company offers them quite a bit of money to do the research that *they* love
2. *poof* Tenure track faculty position

in reality now, its usually

1. Teach as an adjunct
2. Try to convince private industry that you're okay taking that 60k a year position as a chemical engineer.. I'm not overqualified, HONEST!

If you're good at what you do, there'll be good jobs for you no matter what path in life you choose. If you're a lazy slackabout, then you're screwed no matter what. There's no "right" or "wrong" answer about whether a PhD is a good choice -- it's about whether it's a good choice for YOU. This is the real reason why people tell you to do something you love -- chances are, you'll be enthusiastic about it and do it well, and success will follow naturally.

I seem to remember hearing that a lot of Third World countries carried on using the German cryptosystems for a long time after the war, and that was why all the Bletchley technology was kept black - we rather liked being able to read everyone's mail. Don't know how true that is, though...

Well, there is something related here; Dennis Ritchie dabbles in cryptography. He talks about cryptanalysis of the hagelin m-209b crypto device (I bought one on ebay :)). They submitted their findings for voluntary review by the NSA before publishing, and Ritchie was visited by a "Retired Man" from the NSA. The relevant bit:

He got a bit more specific about two things: the agency didn't particularly care about the M-209. What they did care about was that the method that Reeds had discovered was applicable to systems that were in current use by particular governments, and that even though it was hard to imagine that these people would find the paper and relate it to their own operations (which used commercially-available crypto machines), still... perhaps we should exercise discretion? It was certainly legal to publish, but publication might cause difficulties for some people in the agency.

So, even though this has nothing to do with the UK and colossus/enigma/lorenz directly, it still is a similar story.

Meet Plan 9 and Inferno.

A few points:

1) I did not claim that Dennis Ritchie wrote BCPL. I claimed he wrote "the compiler for" BCPL.

2) I was overreaching when I made the statement. In his online biography, Ritchie wrote, "I helped with a compiler for the BCPL language on the Multics machine (GE 645) and on the GE 635 under the GECOS system." source

So essentially I was in error. Which brings me to point 3:

3) After claiming that the Freemasons were secretly controlling the compiler market, that Linus wrote Linux using a photocopier, and that the "how do you compile the compiler" question can only be solved by time travel, why would you jump on me for THIS error?

No, really. I want to know.

Wasn't AT&T Unix originally an open-sourced type UNIX where AT&T suddenly claimed the copyright to all submissions, and closed it up?

Um, no. You are very confused. So confused I am not equipped to guess which possible mis-perceptions you are referring to. Unix, AT&T and otherwise, was born in 1969 at Bell Labs. Google around a bit or start here.

*IX is pretty good. There aren't a whole lot of obvious changes I'd like to see.

Spelling creat with a "e" :-)

And umount with an n... (Plan 9 has unmount. Don't know about create though. It also lacks the root of string overflows, /str[^n].*/.)

* I've always wondered why network interfaces (at least under Linux, not sure if this is the same under other OSes) are not files like almost everything else in the UNIX world.

In Plan 9... the whole network interface and system is done as files, not merely the channel. (For at least the TCP part)

1. Open /net/tcp/clone (Keep the file handle, call it f_ctl) You'll end up with /net/n/ctl when you open it.
2. Write 'connect 192.168.1.1 23' into f_ctl.
3. If there is no error from the write, then read from f_ctl a number. Call it tcp_n.
4. Open "/net/" + tcp_n + "/data". (Call the file handle f_data)
5. Use f_data like a socket/pipe.

Lo and behold, you have a telnet connection to 192.168.1.1:23. You can write a whole server in a shell script without needing a wrapper.

Relevant man pages:
ether (3)
ip (3)

Anyway, when I have some free time, I will implement this. It should be quite easy to override the system calls using LD_PRELOAD.

Statically compiled binaries may not respect LD_PRELOAD and ignore your overrides, calling their static copy of libc directly.

*IX is pretty good. There aren't a whole lot of obvious changes I'd like to see.

Spelling creat with a "e" :-)

And umount with an n... (Plan 9 has unmount. Don't know about create though. It also lacks the root of string overflows, /str[^n].*/.)

* I've always wondered why network interfaces (at least under Linux, not sure if this is the same under other OSes) are not files like almost everything else in the UNIX world.

In Plan 9... the whole network interface and system is done as files, not merely the channel. (For at least the TCP part)

1. Open /net/tcp/clone (Keep the file handle, call it f_ctl) You'll end up with /net/n/ctl when you open it.
2. Write 'connect 192.168.1.1 23' into f_ctl.
3. If there is no error from the write, then read from f_ctl a number. Call it tcp_n.
4. Open "/net/" + tcp_n + "/data". (Call the file handle f_data)
5. Use f_data like a socket/pipe.

Lo and behold, you have a telnet connection to 192.168.1.1:23. You can write a whole server in a shell script without needing a wrapper.

Relevant man pages:
ether (3)
ip (3)

Anyway, when I have some free time, I will implement this. It should be quite easy to override the system calls using LD_PRELOAD.

Statically compiled binaries may not respect LD_PRELOAD and ignore your overrides, calling their static copy of libc directly.

There is still such a system being developed at Bell Labs. It's called Plan 9.

If you look at some of the docs, there seem to be a bunch of Bell Labs folks contributing (perhaps even principal developers)... including a doc by Brian Kernighan and lo and behold, Dennis Ritchie, the authors of one of the canonical C books ("The C Programming Language" -- more affectionately known as "K&R".)

Could be interesting stuff, especially the Limbo "C-like, concurrent" programming language (though the syntax seems like an ugly version of Python with some bizarre odds and ends tacked on like a <- operator for "channels").

-fren

There's a well known intro paper on wavelets here: Building your own wavelets at home (Wim Sweldens and Peter Schröder, ACM SIGGRAPH 1996)

More here.

WINE will have truly succeeded, not when everyone switches from Windows to Linux, but when software developers begin to:

1. Code their Windows apps in a way which makes it easy to run them on WINE
2. test / support WINE as a platform

If this happens, XAML and all future Microsoft dominance is doomed. What we will end up with is the common set of easy, sensible Win32 APIs usable across multiple implementations, and the crufty, proprietary, unnecessary crap being ignored.

Doesn't anyone remember the other proprietary OS this happened to?

I should also mention that one *big* problem with backporting such a system is the division between user and kernel space.

Unix is broken by design. The inventors themselves say so. They redesigned it to make hard things easy and plan9 was born.

Durable != optimal

I don't want that crap, and I don't want Gnome's crap either.

I want a web browser, if I wanted some kind of megalomaniac "application development platform" I will use Python, thank you very much.

And as long as they don't give me access to the source under an open source license I wont touch it. I have been burned once(Windows), twice(Java), I'm not going to get burned a third time, if you want me to rely on your software you better give me the source and let me fix it(or let others fix it).

As Al Viro, one of the very few reasonable Linux kernel developers, said:

All software sucks, be it open-source [or] proprietary. The only question is
what can be done with particular instance of suckage, and that's where having
the source matters.
-- viro [http://www.ussg.iu.edu/hypermail/linux/kernel/040 4.3/1344.html]

It's sad that we have to get to this, but in the current software industry having access to the source under a open source license is the only warranty that you are not going to be royally screwed, I don't want to be at the mercy of the economic targets of some random company, I already have enough trouble taking care of _my_ business.

Life is too short to run proprietary software.
-- Bdale Garbee

And as for Gnome, I will quote viro wise words again:

Yeah... "Infinitely extendable API" and all such. Roughly translated
as "we can't live without API bloat". Frankly, judging by the GNOME
codebase people who designed the thing[GNOME] are culturally incompatible
with UNIX.

And yea, that is you, my dear Miguel, you have as little clue as RMS of what Unix is all about, I advice you that when you get tired of all that .NOT gratuitous complexity and over-designed crap you take a look at the only sane OS left: Plan 9; and if you are tired of doing "memory management", why don't you use Limbo (The Limbo Programming Language by Dennis M. Ritchie)?

uriel

Plan 9 is downloadable under an open source license. http://plan9.bell-labs.com/plan9dist/

Here's the protocol

http://plan9.bell-labs.com/sys/man/5/INDEX.html

one supplies an offset and count and the server returns whatever data it feels like.

So yes, you are free to play games with the units be it bytes or timecode.

one issues :
size[4] Tread tag[2] fid[4] offset[8] count[4]

and gets returned
size[4] Rread tag[2] count[4] data[count]

tag is an ID for this request, fid is an id for the file
size is the packet size, the rest is the payload.

The thing you would have to be careful of, though, is the maximum 9p packet size, which is usually set to 8k though this is negotiable.

I can imagine some system that facilitates MPEG editing by representing the MPEG as RGB24 full frames or even multiple channels for the RGB video channels or even s YUV. There's plenty of scope.

inferno also uses a 9p variant protocol, Styx, to do much the same thing. You can run Inferno as an application . Inferno as an application is a virtualized OS but aimed at embedded devices, PDAs etc.

having stuff supported at the programming level is stupid

Whatever happened to 'everything is a file'

Plan9's user level file systems are far more suitable.

One programs services to appear as file system in the process' namespace. The canonincal example of this is ftpfs which presents a remote ftp server as part of one's local file system.

By using this method, *no* programs need be compiled with knowledge of the ftp protocol and sockets nd the like. In fact it wouldn't even know it was talking with an ftp server.

All services and devices are presented like this in plan9. Most things can be achieved with cats and echos.

having stuff supported at the programming level is stupid

Whatever happened to 'everything is a file'

Plan9's user level file systems are far more suitable.

One programs services to appear as file system in the process' namespace. The canonincal example of this is ftpfs which presents a remote ftp server as part of one's local file system.

By using this method, *no* programs need be compiled with knowledge of the ftp protocol and sockets nd the like. In fact it wouldn't even know it was talking with an ftp server.

All services and devices are presented like this in plan9. Most things can be achieved with cats and echos.

see this link to ACID whitepaper

also see this portion of the Inferno manual.

and this entry on citeseer.

*the* AC

• Simplicity
  
• Clarity
  
• Generality
  

• Simplicity
  
• Clarity
  
• Generality
  

• Simplicity
  
• Clarity
  
• Generality
  

• Simplicity
  
• Clarity
  
• Generality
  

• Simplicity
  
• Clarity
  
• Generality
  

• Simplicity
  
• Clarity
  
• Generality
  

Dennis uses Aleph? Perhaps you are thinking of the old Alef language from Plan9, but that is dead! ComputerHistory.org says it is his favorite language, It was removed for the 3rd release of Plan 9, which was about 4 years ago, and replaced by a new threading library for C.

affects everyone and everything

for some values of everyone and everything

I'll bet the first person to reply $10 that plan9 isn't affected.

pah. call that persecution.

try finding a plan9 exploit.

and this one doesn't count. It's a hoax.

Sorry, here's the link.

The clear successor for C is Limbo.

Limbo was developed in Bell Labs by the the same people that created Unix, C, and Plan 9, and someone once described it as "the language the creators of C would have come up with if they had been give and enormous amount of time to fix and improve C", that is exactly what Limbo is.

Dennis M. Ritchie: The Limbo Programming Language
Brian W. Kernighan: A Descent into Limbo

Together with Inferno, Limbo forms the best platform for distributed applications.

Inferno and Limbo were recently released under an open source license and you can download them here:

http://cgi.www.vitanuova.com/cgi-bin/www.vitanuova .com/idown4e.pl

Inferno/Limbo are the only hope for some sanity in the software industry!

Best wishes

uriel

where I come from we use utf8 so the domain of available variable names is a bit more than 53.

you mean like this one

If you really want a network OS why not use one