i'm no expert, but surely the reason that
it took a while to cook the chicken in the lava
was because of that hole they'd left to let
the steam escape. the crucial observation
is that the chicken was moist afterwards,
so presumably the level of moisture is high
enough that the moisture limits the temperature
of the chicken to the usual 100 degrees C.
if they'd closed the hole, i imagine the chicken
would cook much faster!
where i work, we use plan 9 as a development
environment - no NAT necessary. to get through
to the outside world, you import the network
interface from a gateway machine and use that.
however, if an intruder wishes to do that, they
must first break the strong authentication used
by the import protocol...
so much of today's lax security is due to legacy design, not inherent difficulty.
this is worth remembering.
i'll definitely second that! i've been there twice now, once on a climbing trip 'cos there's some superb rock climbing on the sea cliffs just north of doolin; and once
with my girlfriend and a fiddle, spending lots of time
playing in the trad. music sessions there. really
friendly people especially considering the number of
tourists that must pass through.
a fantastic place. as for accommodation, the first time
i camped (windy and wet!), and the second stayed
at the Rainbow Hostel, very friendly, and no problem
with coming back in at god knows what hour of the morning!
i can't say i saw anything resembling a computer
when i was there though, so i can't speak for the
bandwidth!
inferno was designed for exactly this kind of thing. it provides secure connectivity between heterogeneous
boxes across heterogeneous networks.
the security architecture is highly modular (i.e. once
you have a reliable data connection, you can securely
access any sort of resources provided by an inferno
instance at the other end). that includes all kinds of devices as well as files.
the connectivity and security are as versatile (or more
so) as unix pipes; also you can write programs for it that
run without change (really!) on any supported platform
('cos it provides an OS level view of everything rather than trying to shoehorn itself into the parent environment like java).
the security model is public-key based and because it's end to end, you don't need to worry at all about little things like 802.11 insecurities...
plus it's all small, clean and beautiful as befits something coming from CSRG at bell labs.
as a basis for an approach i like what plan 9 does. the mail is made available to clients as a filesystem (provided by a user level program). each mail message gets its own directory; each mime attachment gets its own subdirectory within that message (and recursively, as MIME is recursive).
here's a little transcript:
% cd/mail/fs/mbox
% lc
Directories:
1 113 128 142 157 171 186 20 214 229 243 258 272 287 300 315 33 344 359 373 388 401 416 430 445 46 474 56 70 85
[...]
% cd 318
% lc
Files:
bcc date filename info messageid rawbody sender type
body digest from inreplyto mimeheader rawheader subject unixheader
cc disposition header lines raw replyto to
Directories:
1 2 3
% head raw
Return-Path:
Received: from punt-1.mail.demon.net by mailstore for rog@vitanuova.com
id 1021665470:10:17045:138; Fri, 17 May 2002 19:57:50 GMT
Received: from psuvax1.cse.psu.edu ([130.203.4.6]) by punt-1.mail.demon.net
id aa1016828; 17 May 2002 19:57 GMT
Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.6.6])
by mail.cse.psu.edu (CSE Mail Server) with ESMTP
id 27DA4199BE; Fri, 17 May 2002 15:57:13 -0400 (EDT)
Delivered-To: 9fans@cse.psu.edu
Received: from acl.lanl.gov (plan9.acl.lanl.gov [128.165.147.177])
% head body
This is a multi-part message in MIME format.
--upas-mbyuptynpdsmbjuyeermihdgur
Content-Disposition: inline
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Hi,
If you seek excitement and thrills you need to look no further than
Plan9 -- it gives you everything and then some, but in a good way (or
% cd 2
% lc
Files:
bcc date filename info messageid rawbody sender type
body digest from inreplyto mimeheader rawheader subject unixheader
cc disposition header lines raw replyto to
% cat mimeheader
Content-Type: image/jpeg
Content-Disposition: attachment; filename=iostats.jpg
Content-Transfer-Encoding: base64
% page body
reading through graphics...
%
"raw" contains the raw data that makes up the message. "body" contains the data after the encoding formats have been applied (hence in that case/mail/fs/mbox/318/2/body is a jpeg file, viewable directly by any usual jpeg viewer).
the beauty of this scheme is that it hides the underlying storage scheme from the mail clients. if i wish to change things so that the underlying storage
format is many files [currently it uses a traditional mbox format], none of the mail client programs have to change.
plus i can use grep, diff, shell scripts, etc directly on the messages in my mailbox. procmail eat your heart out.
ha ha ha ha!
HA HA HA HA!
ROFL.
have you actually read any of the (many)
MIME RFCs?
there are so many traps and pitfalls lurking there
that to say that MIME is easy to decode is just untrue.
for the record, inferno is free (free download here or here) and the core source code is available (costs $300 and allows commercial development).
most of the source code (applications, libraries, etc) is free and open source.
i believe this compares favourably with Linux (many embedded linuxen have proprietary bits) PalmOS (where's the source code to that?), and many other embedded systems such as QNX and VXworks. not to mention being the coolest OS on the planet.
Why? Its so incredibly clean, so much more so than any language I have seen (C++, etc).
compared to C++ you're right, but java really isn't the clean language it's hyped up to be.
for a nice clean language that fits in the embedded niche, you should check out Limbo, which is a genuinely clean language (designed by the same group that designed C).
the crucial thing about Limbo, though, is that, unlike Java, it doesn't try to solve all portability problems in the language itself. The Inferno OS effortlessly solves all the problems that Java struggles over. It runs fast, packing lots of functionality into a small footprint (1MB RAM is sufficient to run significant GUI apps), and provides some extremely powerful primitives for composing distributed applications.
we had a little distributed app that a colleague had knocked up over a couple of days (two files, 800 lines of code total). it implemented a "shared piece of paper" - i.e. all users see anything that anyone draws on the app. talking to someone that had tried to do a similar thing in Java on a PalmOS based device, they were amazed - they'd taken months to do the same thing, and it was slow, big, and didn't provide as much functionality.
the real plus side is just how beautiful the environment is to program in. it gives you power and doesn't make you pay for it via huge and convoluted API interfaces. (and that's why it's fast and small too).
i was looking through last year's high scores
and found myself really wanting to be
able to see more than just the score.
e.g. that character that ascended with only
49000 points: how did they do it? what
was their inventory like at the end?
same goes for all the others: it would be
great to be able to see them in action.
surely in these days of huge disks, it would
be dead easy to log all the tournament
games (preferably with timing information),
so you could see action replays of particularly
spectacular nethack action scenes from the
top scorer, etc...
well, here you go. this is where the javascript code
lives (you'll find it easier going if you have a javascript beautifier
or the patience to tease the code apart a little).
the page we originally found it on was here.
it looks like www.websidestory.com
is the responsible party. i wonder how many sites they've fitted out
like this...
at least the code doesn't work on our browser!
can anyone out there work out exactly what information
the script is divulging?
this issue is interesting: a colleague at work was today
looking for a bug in some Javascript (we maintain
our own web browser), and after delving down
through the deliberately obfuscated javascript
code, it became obvious what it was trying to do:
it went through all links in the document, attaching
a javascript "front-end" to each link that did an http GET request
informing the remote site what had been clicked on,
before actually following the link. the technique
used seemed fairly dodgy (the request was purporting
to be for a non-displayed image), but it's interesting
to see what a fairly reputable site is prepared
to do in order to get as much information off you as possible (without your knowledge).
how reasonable is that? i don't like it, but is that sort
of subterfuge the kind of thing we'd like to stop too?
[PS. apologies if this appears twice - it looked like/.
had rejected the previous ones; and then the whole
server seemed to crash: what was going on there then?]
Yuck, more like. Have you actually had a look at the spec? It contains hundreds of pages of superfluous crap. As seems to be usual for standards these days, it goes way over the top, specifying all layers from the bottom to the top, where it would actually be much better limiting itself to specifying a simple data interchange format, and letting the network people do the network stuff.
maybe it's a good thing (long term) that he's not being released. at least then some people might see just what a ridiculous thing this act is... and some courts might have a chance to blow the DMCA out of the water.
actually, the spelling is the thing most obviously at fault:
compliment: an expression of praise of admiration
complement: a useful or appropriate addition to
well, amazon and AOL might praise each other all day long, but i don't think that's what was meant in the original article. i agree with mr. anonymous, above: the slashdot contributors should learn to spell.
i'm writing this (just for the hell of it) inside the Charon web browser under inferno on an Ipaq. i'm running a couple of shell windows & i've browsed around this thread, and the memory highwatermark reads approx 6MB.
low memory usage isn't the coolest thing about it, though... currently i'm not using any local flash storage; everything is being dragged across via the wavelan card. that includes not only files, but even the network interface !
everything (apart from the itsy bitsy screen) is exactly the same as any other inferno installation... and even though i haven't turned on JIT compilation, it's highly responsive and nicely nippy.
forget java, which is fundamentally memory hungry and bloated... inferno makes it incredibly easy to do things which are hard (or impossible) under other platforms.
now there's just the question of how best to use these funny little devices. typing on this wee sw kbd ain't the easiest, long term! .
Unless you have REALLY taught OO concepts to death, many with find the OO paradigm, and java very uncomfortable
that is because the concepts are very uncomfortable! they do not fit very well with many types of programming. object inheritance is a kind of anthropomorphisation of data ("a square is kind of like a triangle but with an extra point"). I look at all the blather that people spout about OO programming, and I look at the actual programs produced, and I think the truth is self evident.
the only problem is that so many people have invested so much rhetoric in the OO concept that they will defend it to the death, despite its manifest failure.
I taught electronics undergrads C as their first language for some years. When I left, they were moving to Java. I was glad I had left! Like some others here, I'm not convinced that the actual language itself matters, just that it allows you to demonstrate, in a clear way, the programming concepts you're trying to get across.
Personally, I don't believe that Java is the right way to go in that respect (although there are worse languages: my old comp sci dept started to teach Ada as a first language after I left...). Two main reasons:
Inheritance-based OO programming is a naturally obfuscated way of writing code, and is hard even for experts to get right. This page holds, amongst other things, a couple of paragraphs I wrote giving some of the reasons why.
The Java class libraries, partly for the above reasons, are a huge, tangled mess, and extremely hard for a beginner to come to terms with.
My personal choice for a first language to teach would be Limbo, a beautiful language, designed by some of the original designers of C (who've come a long way since then!). Amongst other things, it:
encourages simple, understandable code. Reuse is through encapsulation rather than inheritance.
has a powerful set of primitive data-types with natural and useful semantics.
runs on many platforms under the Inferno OS, e.g. Windows and Linux.
is completely type-safe (unlike Java)
has a simple but powerful set of libraries which can be understood, and are useful, in isolation from each other.
The language primitives make it quite feasible to teach different aspects of programming without moving to different languages:
Lisp-style lists are nice for teaching recursion ("car" and "cdr" become the more natural "hd" and "tl")
Proper by-value strings (unlike Java's) make string handling sinple and natural.
Interprocess communication is supported in Limbo by first-class channels, enabling threading and concurrency to be explored without constantly struggling against thread primitives and associated pitfalls which belong to the 1970s.
Overall, the syntax is extremely clean, but very expressive (although still recognisably derived from C). It has hardly any "gotchas", and is generally programmed in a simple, direct style, ideal for beginners (and advanced programmers who want to write maintainable code, for that matter). Moreover, it's very sparse on resources.
I'd love to teach it as a first language. No more "ahh yes, that array just turned into a pointer because you looked at it funny"... oh happy memories...
that's exactly what a large portion of the referenced paper is concerned with: the changes in the privacy, ownership and control of books that are likely to be inevitable companions to the rise of the e-book.
the author came out on a positive note, but only just...
[having just got to the end of the paper having been snatching excerpts from it all day between bits of program design. sometimes i wish there was a forced hiatus in between the posting of a/. article and people being allowed to post replies to it. (gap proportional to size of link pointed to). then one might get some interesting replies from people who'd actually read the article in question...]
Let's just face it, not everybody has even heard of Dijkstra, let alone know how to write 'proofable' programs
come on, this is perl you're talking about! the canonical "write-once, read-nowhere" language... in my experience, the quality of perl code out there currently couldn't be significantly decreased anyway!:-)
Re:Bandwidth is UNlimited on the air interface
on
Telecosm
·
· Score: 2
ok, but that's still just local bandwidth. the range of high frequency radio signals is more-or-less line of sight. so you've got a very high bandwidth to your local radio cell transceiver. but how is that connected to the rest of the world?
yup, that's right: cable (or some other point-to-point technology). so i still think my thoughts hold some weight.
and, BTW, Moore's Law doesn't theoretically go on for ever: for one thing, it's an entirely empirical law, with no actual theoretical basis; for another, it relates to the number of transistors you can fit on a chip, which tops out at one transistor per atom (a high limit, agreed, but nonetheless very finite, so bandwidth will still be fundamentally limited).
bandwidth will always be limited
on
Telecosm
·
· Score: 2
no matter how much bandwidth we get, we will always want more. this is something that will never change, unless someone rewrites the laws of the universe. the reason is that it is always going to be easier to communicate with an entity closer to you than further away.
fiber links may act as "information wormholes", subverting this rule for the parties at each end of the link, but you can't run fiber links from everywhere to everywhere else. therefore links will inevitably turn into bottlenecks.
i think that people are still gravely underestimating the amount of bandwidth that we can use. think about distributed computing. for example, imagine a hypothetical future realtime computer simulation of a human brain: if you've got two of them, communication can take place just like it does for us (a telephone line!); but try splitting the simulation into its two hemispheres, each running on a different computer. how much bandwidth will this require? what about splitting it into four?!
ok, you might be able to do it for one such distributed calculation, but what if everyone is trying to do it? a conservative (read naive) estimate gives 10 terabits/s required... for one such calculation. that's more than the predicted maximum bandwidth of a single fiber for the foreseeable future. ok, it's maybe a contrived example, but what about peer-to-peer 3D virtual worlds? there are a billion possible computing tasks requiring that much bandwidth...
there will always be a cost advantage to physical proximity.
high bandwidth over long distances will always command premium rates.
I wish the GUI was "beatiful" (sic) instead of the source.:P (It can run any other WM, right?)
beauty is in the eye of the beholder!
i agree it doesn't look like conventional GUIs that you see everywhere else, but then again the point was to rethink things without prejudice.
you'll notice from that screenshot that there's very little lost screen real-estate. no arrays of cryptic icons, no titlebars, no buttons, no text entry boxes, etc. that's one design goal: screen space is precious, so use it for information not crap.
also, it can't run any other WM, as it doesn't use the abortion that is X windows. this allows the window manager to start up in a fraction of a second, and take about 1/10th of the memory of window managers under other systems. most applications start up faster than you can notice.
no, it's not an OS for weenies that want to point-and-click on a few predetermined actions all day, a la Microsoft Word. it's small, incredibly powerful, and a joy to develop for and use on a day-to-day basis.
BTW, according to the license you have to agree to before you can download Plan9, you cannot export Plan9 out of the US without a license!
not true. you have to comply with the US export regulations (as does the export of every other piece of software), and as it contains some crypto software, you aren't allowed to export it to one of the "7 terrorist nations" or somesuch crap.
this is US government's doing, not lucent's (although it has to be said the lucent lawyers do seem to err on the "safe not sorry" side at times...)
Bell Labs considers any changes you make to the system their intellectual property
actually, that's not true. what the license does say is that if you distribute the system with modifications, you must make the source code available (on request) to lucent (the intention is that they can make such modifications available in the general distribution).
this is no worse than the GPL, which stipulates that if you distribute the system, you must make the source available too.
Slashdot Mirror
if they'd closed the hole, i imagine the chicken would cook much faster!
so much of today's lax security is due to legacy design, not inherent difficulty. this is worth remembering.
a fantastic place. as for accommodation, the first time i camped (windy and wet!), and the second stayed at the Rainbow Hostel, very friendly, and no problem with coming back in at god knows what hour of the morning!
i can't say i saw anything resembling a computer when i was there though, so i can't speak for the bandwidth!
the connectivity and security are as versatile (or more so) as unix pipes; also you can write programs for it that run without change (really!) on any supported platform ('cos it provides an OS level view of everything rather than trying to shoehorn itself into the parent environment like java).
the security model is public-key based and because it's end to end, you don't need to worry at all about little things like 802.11 insecurities...
plus it's all small, clean and beautiful as befits something coming from CSRG at bell labs.
here's a little transcript:
% cd /mail/fs/mbox
/mail/fs/mbox/318/2/body is a jpeg file, viewable directly by any usual jpeg viewer).
% lc
Directories:
1 113 128 142 157 171 186 20 214 229 243 258 272 287 300 315 33 344 359 373 388 401 416 430 445 46 474 56 70 85
[...]
% cd 318
% lc
Files:
bcc date filename info messageid rawbody sender type body digest from inreplyto mimeheader rawheader subject unixheader cc disposition header lines raw replyto to
Directories:
1 2 3
% head raw
Return-Path:
Received: from punt-1.mail.demon.net by mailstore for rog@vitanuova.com
id 1021665470:10:17045:138; Fri, 17 May 2002 19:57:50 GMT
Received: from psuvax1.cse.psu.edu ([130.203.4.6]) by punt-1.mail.demon.net
id aa1016828; 17 May 2002 19:57 GMT
Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.6.6])
by mail.cse.psu.edu (CSE Mail Server) with ESMTP
id 27DA4199BE; Fri, 17 May 2002 15:57:13 -0400 (EDT)
Delivered-To: 9fans@cse.psu.edu
Received: from acl.lanl.gov (plan9.acl.lanl.gov [128.165.147.177])
% head body
This is a multi-part message in MIME format.
--upas-mbyuptynpdsmbjuyeermihdgur
Content-Disposition: inline
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Hi,
If you seek excitement and thrills you need to look no further than
Plan9 -- it gives you everything and then some, but in a good way (or
% cd 2
% lc
Files:
bcc date filename info messageid rawbody sender type
body digest from inreplyto mimeheader rawheader subject unixheader
cc disposition header lines raw replyto to
% cat mimeheader
Content-Type: image/jpeg
Content-Disposition: attachment; filename=iostats.jpg
Content-Transfer-Encoding: base64
% page body
reading through graphics...
%
"raw" contains the raw data that makes up the message. "body" contains the data after the encoding formats have been applied (hence in that case
the beauty of this scheme is that it hides the underlying storage scheme from the mail clients. if i wish to change things so that the underlying storage format is many files [currently it uses a traditional mbox format], none of the mail client programs have to change.
plus i can use grep, diff, shell scripts, etc directly on the messages in my mailbox. procmail eat your heart out.
ha ha ha ha!
HA HA HA HA!
ROFL.
have you actually read any of the (many) MIME RFCs? there are so many traps and pitfalls lurking there that to say that MIME is easy to decode is just untrue.
download
here
or here)
and
the core source
code is available (costs $300 and allows
commercial development).
most of the source code (applications, libraries, etc)
is free and open source.
i believe this compares favourably with Linux (many
embedded linuxen have proprietary bits) PalmOS
(where's the source code to that?), and many other
embedded systems such as QNX and VXworks.
not to mention being the coolest OS on the planet.
have seen (C++, etc).
compared to C++ you're right, but java really isn't
the clean language it's hyped up to be.
for a nice clean language that fits in the embedded niche,
you should check out Limbo, which
is a genuinely clean language (designed by the same
group that designed C).
the crucial thing about Limbo, though, is that, unlike Java,
it doesn't try to solve all portability problems in the language
itself. The Inferno OS effortlessly solves all
the problems that Java struggles over. It runs fast, packing
lots of functionality into a small footprint (1MB RAM is sufficient
to run significant GUI apps), and provides some extremely
powerful primitives for composing distributed applications.
we had a little distributed app that a colleague had
knocked up over a couple of days (two files, 800 lines of code total).
it implemented a "shared piece of paper" - i.e. all users
see anything that anyone draws on the app.
talking to someone that had tried to do a similar thing in
Java on a PalmOS based device, they were amazed - they'd
taken months to do the same thing, and it was slow, big,
and didn't provide as much functionality.
the real plus side is just how beautiful the environment
is to program in. it gives you power and doesn't make you
pay for it via huge and convoluted API interfaces.
(and that's why it's fast and small too).
e.g. that character that ascended with only 49000 points: how did they do it? what was their inventory like at the end?
same goes for all the others: it would be great to be able to see them in action.
surely in these days of huge disks, it would be dead easy to log all the tournament games (preferably with timing information), so you could see action replays of particularly spectacular nethack action scenes from the top scorer, etc...
it looks like www.websidestory.com is the responsible party. i wonder how many sites they've fitted out like this...
at least the code doesn't work on our browser! can anyone out there work out exactly what information the script is divulging?
looking for a bug in some Javascript (we maintain
our own web browser), and after delving down
through the deliberately obfuscated javascript
code, it became obvious what it was trying to do:
it went through all links in the document, attaching
a javascript "front-end" to each link that did an http GET request
informing the remote site what had been clicked on,
before actually following the link. the technique
used seemed fairly dodgy (the request was purporting
to be for a non-displayed image), but it's interesting
to see what a fairly reputable site is prepared
to do in order to get as much information off you as possible (without your knowledge).
how reasonable is that? i don't like it, but is that sort
of subterfuge the kind of thing we'd like to stop too?
[PS. apologies if this appears twice - it looked like
had rejected the previous ones; and then the whole
server seemed to crash: what was going on there then?]
Yuck, more like. Have you actually had a look at the spec? It contains hundreds of pages of superfluous crap. As seems to be usual for standards these days, it goes way over the top, specifying all layers from the bottom to the top, where it would actually be much better limiting itself to specifying a simple data interchange format, and letting the network people do the network stuff.
I'm still feeling slightly nauseous.
maybe it's a good thing (long term) that he's not being released. at least then some people might see just what a ridiculous thing this act is... and some courts might have a chance to blow the DMCA out of the water.
well, amazon and AOL might praise each other all day long, but i don't think that's what was meant in the original article. i agree with mr. anonymous, above: the slashdot contributors should learn to spell.
low memory usage isn't the coolest thing about it, though... currently i'm not using any local flash storage; everything is being dragged across via the wavelan card. that includes not only files, but even the network interface !
everything (apart from the itsy bitsy screen) is exactly the same as any other inferno installation... and even though i haven't turned on JIT compilation, it's highly responsive and nicely nippy.
forget java, which is fundamentally memory hungry and bloated... inferno makes it incredibly easy to do things which are hard (or impossible) under other platforms.
now there's just the question of how best to use these funny little devices. typing on this wee sw kbd ain't the easiest, long term! .
that is because the concepts are very uncomfortable! they do not fit very well with many types of programming. object inheritance is a kind of anthropomorphisation of data ("a square is kind of like a triangle but with an extra point"). I look at all the blather that people spout about OO programming, and I look at the actual programs produced, and I think the truth is self evident.
the only problem is that so many people have invested so much rhetoric in the OO concept that they will defend it to the death, despite its manifest failure.
sigh.
Personally, I don't believe that Java is the right way to go in that respect (although there are worse languages: my old comp sci dept started to teach Ada as a first language after I left...). Two main reasons:
My personal choice for a first language to teach would be Limbo, a beautiful language, designed by some of the original designers of C (who've come a long way since then!). Amongst other things, it:
- encourages simple, understandable code. Reuse is through encapsulation rather than inheritance.
- has a powerful set of primitive data-types with natural and useful semantics.
- runs on many platforms under the Inferno OS, e.g. Windows and Linux.
- is completely type-safe (unlike Java)
- has a simple but powerful set of libraries which can be understood, and are useful, in isolation from each other.
The language primitives make it quite feasible to teach different aspects of programming without moving to different languages:- Lisp-style lists are nice for teaching recursion ("car" and "cdr" become the more natural "hd" and "tl")
- Proper by-value strings (unlike Java's) make string handling sinple and natural.
- Interprocess communication is supported in Limbo by first-class channels, enabling threading and concurrency to be explored without constantly struggling against thread primitives and associated pitfalls which belong to the 1970s.
Overall, the syntax is extremely clean, but very expressive (although still recognisably derived from C). It has hardly any "gotchas", and is generally programmed in a simple, direct style, ideal for beginners (and advanced programmers who want to write maintainable code, for that matter). Moreover, it's very sparse on resources.I'd love to teach it as a first language. No more "ahh yes, that array just turned into a pointer because you looked at it funny"... oh happy memories...
the author came out on a positive note, but only just...
[having just got to the end of the paper having been snatching excerpts from it all day between bits of program design. sometimes i wish there was a forced hiatus in between the posting of a /. article and people being allowed to post replies to it. (gap proportional to size of link pointed to). then one might get some interesting replies from people who'd actually read the article in question...]
it might look silly, but from experience, a Petzl Zoom works wonders for nighttime vision without sacrificing hand or mouth space...
considered essential by climbers everywhere...
come on, this is perl you're talking about! the canonical "write-once, read-nowhere" language... in my experience, the quality of perl code out there currently couldn't be significantly decreased anyway! :-)
yup, that's right: cable (or some other point-to-point technology). so i still think my thoughts hold some weight.
and, BTW, Moore's Law doesn't theoretically go on for ever: for one thing, it's an entirely empirical law, with no actual theoretical basis; for another, it relates to the number of transistors you can fit on a chip, which tops out at one transistor per atom (a high limit, agreed, but nonetheless very finite, so bandwidth will still be fundamentally limited).
fiber links may act as "information wormholes", subverting this rule for the parties at each end of the link, but you can't run fiber links from everywhere to everywhere else. therefore links will inevitably turn into bottlenecks.
i think that people are still gravely underestimating the amount of bandwidth that we can use. think about distributed computing. for example, imagine a hypothetical future realtime computer simulation of a human brain: if you've got two of them, communication can take place just like it does for us (a telephone line!); but try splitting the simulation into its two hemispheres, each running on a different computer. how much bandwidth will this require? what about splitting it into four?!
ok, you might be able to do it for one such distributed calculation, but what if everyone is trying to do it? a conservative (read naive) estimate gives 10 terabits/s required... for one such calculation. that's more than the predicted maximum bandwidth of a single fiber for the foreseeable future. ok, it's maybe a contrived example, but what about peer-to-peer 3D virtual worlds? there are a billion possible computing tasks requiring that much bandwidth...
beauty is in the eye of the beholder!
i agree it doesn't look like conventional GUIs that you see everywhere else, but then again the point was to rethink things without prejudice.
you'll notice from that screenshot that there's very little lost screen real-estate. no arrays of cryptic icons, no titlebars, no buttons, no text entry boxes, etc. that's one design goal: screen space is precious, so use it for information not crap.
also, it can't run any other WM, as it doesn't use the abortion that is X windows. this allows the window manager to start up in a fraction of a second, and take about 1/10th of the memory of window managers under other systems. most applications start up faster than you can notice.
no, it's not an OS for weenies that want to point-and-click on a few predetermined actions all day, a la Microsoft Word. it's small, incredibly powerful, and a joy to develop for and use on a day-to-day basis.
not true. you have to comply with the US export regulations (as does the export of every other piece of software), and as it contains some crypto software, you aren't allowed to export it to one of the "7 terrorist nations" or somesuch crap.
this is US government's doing, not lucent's (although it has to be said the lucent lawyers do seem to err on the "safe not sorry" side at times...)
actually, that's not true. what the license does say is that if you distribute the system with modifications, you must make the source code available (on request) to lucent (the intention is that they can make such modifications available in the general distribution).
this is no worse than the GPL, which stipulates that if you distribute the system, you must make the source available too.