1) Can yiu get all the books you want?
2) What about long-term usability of the book format and long therm availability of this or a compatible reader?
These are really quesitons about the PDF format.
As to (1), well, no, but I can't do that in print, either. Basically I'm limited to things I could print on my printer, with PDFs being the simplest. That does include a large number of texts and reference materials in maths and computer science, and all the journals I read regularly. It doesn't include a large number of the books on my shelves, but many of them are out of print, so if I were looking for them anew, electronic copies would probably be likely to surface sooner than physical ones.
For long-term accessibility, (2), I see no reason to suppose that PDFs will 'die' in the sense of becoming uninterpretable; they can be rendered to any raster (digital or physical), and in the process become as durable as any data, including printed data.
The archival problem for data is basically the converse of that of the conservation of physical objects. Physical objects, by and large, are better left untouched; use degrades them. Data objects are best visited periodically, both to activate error correction mechanisms, and to ensure that it is discovered in time that data formats are beginning to be seen as 'obscure' and that recoding is in order. (Though, of course, ideally, the entire web infrastructure would be accessed by rigid, content-derived identifiers, and forward compatibility would be addressed systematically by emulators, so losing the decoder would become very unlikely indeed.)
Ooh, one throw-away line is "rabid anti-Microsoft content"? You may observe that I said just as much bad about September. But, as it happens, this is the truth: almost everyone's view of the Internet-enabled workstation originally involved a substantial element of 'serverness'. Microsoft disagreed, favouring a single-tasking, client-only model of the world. And Microsoft won, and the Internet suffered.
In the old days, FTP was peer-to-peer. Email was instant. User interfaces were network transparent. How can you imagine that Microsoft had no part in the death of that reality?
In the lab where I was working at the time, it was vaguely rude not to respond to email within, say, 60 seconds. I mean, of course, everyone there was a hyperforcussed personality type and would ignore people at their door for as long as it took to finish typing the fix/paragraph/whatever, but email response times were comparable to those for physical presence. Nowadays, you have to go and screw around in the preferences to get your poll rate up to once in 60 seconds; people seem to consider that 'reasonable' delivery lags are 15 minutes, or an hour, or a day.
Well, no shit you can't use that to arrange lunch! Even a 120 second lag (two minimum poll times with Thunderbird) between 'Indian?' and 'We're out of here!' is unacceptable as far as my metabolism is concerned.
If I am interpreting the signals from moderation (and your reply) correctly, 30% of the population here thinks I am making this up, which I can only conclude is because they do not know that Internet email is natively a push technology, and was once push all the way to the end user. That is, SMTP was an instant messaging technology, until it was effectively subverted by POP.
So of course I'm pining for the old days: I have not had a better communications environment than I had with SMTP+deliver+xface+mh-e.
Sure, there are compensating advantages to the modern world. Compile times are much shorter now! The question is, why did we give up the parts that worked well? And then there's the small matter of the thing we were actually discussing—why attitudes to email and messaging might have changed. Breaking the functionality of email would be one hell of a relevant point, don't you think? Even if (as I suspect) you have never experienced it working properly?
I suspect it's chicken-and-egg. The sensors used in digital still cameras seem to be capable of video frame rates, and the sensors used in digital video cameras have much higher native resolution than shows through the video encoding (the extra res is used for image stabilisation and digital zoom). The expensive part of TV cameras is the lenses, not the sensors, and that's not as important to the experience as the latency and resolution. So the input devices could exist. The problem is that in the mind of the manufacturers there's little point: it takes a RAID rack that consumers don't own to record even HDTV, and it takes a network connection that they don't have access to to transmit it.
This is a huge frustration to computer vision and interactive environment researchers, let me tell you! We'd have all kinds of other cool stuff if good cameras were cheap enough to buy in quantity, because now we can do general computation on GPUs, we could make some great applications.
I'm really sorry. This is going to sound like an ad.
I'm carrying an iRex iLiad. Everywhere. It's very slightly more than an ebook reader, because it has a Wacom stylus and you can write on it; then again, it is significantly more expensive because of this. But here's the thing:
It is much nicer than a physical book.
I was absolutely amazed.
Here's why:
First, it has more usable display area than a book. Why? Because although a quarter of the face is case surround, there is no facing page. This makes a huge difference when reading on the bus, or walking down the street, or while drinking a cup of coffee.
Second, it may not be lighter than one book, but it is certainly lighter than three. So now, in a single device I can hang from my belt when I don't mind looking like a dork but want my hands free (which is usually, I'm afraid), I can have a light novel, a heavy novel, something of historical interest, a programming language manual, the reference materials for whatever I'm working on, three technical journals, my entire archive of research papers, my handwritten notes from my chinese class, my meeting notes, my doodles, and my RSS feeds. This is a win, even if I'm now mostly reading classics while I wait for the publishing industry to get its head out and start charging only the software costs for new releases.
Third, and this still weirds me out, in one important way, epaper outperforms contemporary physical paper. It is greyer. "WTF?" I hear you say, "don't you want maximum contrast?" But the answer appears to be that modern paper is made slightly fluorescent; certainly it is immensely white. In direct sunlight, it can be painful, and is certainly hard to read. The iLiad display is disappointing in situations where your mum would have yelled "turn on the light! You'll ruin your eyes!" but in good light it is great and outdoors it is much better than great.
Don't you see? I can now be a functional researcher in the park. With a coffee in one hand. And my book bag increased in capacity by several orders of magnitude and reduced in weight to less than a pound. (Well, except that I live in Canada and its is f***ing winter now and will be for six more months....)
I really hate to sound like a fanboi, but for me, a piece of the long-promised future recently arrived by DHL, let me tell you.
"True community backlash"?!? This is... this is... I don't know, I was brought up with ideas like "due process of law", myself. The duty of the community, and please excuse my religious background if you can, is to love their neighbours. Punishment is just not the domain of the individual, in a civilised society.
So, I grant, it should not be necessary to conceal anyone's identity, because everyone should be responsible and generous adults, suitably measured in their responses. But unfortunately, we are forced to strive for anonymity of the innocent and the guilty alike, because we have to deal with dangerous asshats who believe in things like "true community backlash."
In the old days, email actually worked. It was delivered to your box, and comsat was there to biff you when it arrived. I even had my beloved xface running at the edge of my screen so I could see the incoming and catch the ones from the five people I cared about. And in that environment, we surely did use email to arrange lunch; it was quicker than shouting down the hall.
Then Microsoft figured out that the Internet wasn't going to go away. And suddenly it was all DHCP and POP and all the applications that used to blow started to suck—sorry, those that used to push started to pull—and the Internet stopped feeling like the Internet and turned into what we have today, a kind of UUCP on steroids, where communication doesn't happen until the next scheduled contact time, because an IP number no longer successfully identifies a node and everyone lives in fear, cowering behind firewalls and running no daemons.
And by now email is little better than snail mail, and the interfaces are worse (no xface or deliver scripts in Windows!) and it sucks, and of course people are looking for alternatives so that they can arrange lunch and communicate selectively with the people they care about.
So, I know I'm an old fart by now, but in the old days, before Microsoft Rule and the Eternal September, the technology used to work. I'm not making this up....
Have you considered the cost of doing this by 'trial and error'? You need a lot of people, it takes a lot of time, a lot of materials, and you have to expend immense political capital even to motivate one attempt. Certainly designs evolve over time, but serious engineering thought clearly went into the original undertakings. I can't imagine how you can think otherwise.
Then again, perhaps you consider any application of the empirical method to be 'trial and error'—in which case what we do today is no different, since the numbers we plug into the models do arise from measurement.
Ah, wait a minute, I see. You feel that it is relevant that a two year old can build a six inch beam bridge. Suuuuuure. A six inch beam bridge holding up a plastic penguin in the living room is just exactly like a 150 foot suspension bridge carrying pack animals across a canyon. All the same intuitions will apply! Scaling issues? What scaling issues? But even in Wile E. Coyote's happy death-free world you are mistaken.
Seriously, give some honest thought sometime to how you would build so much as a Stonehenge without modern technology. (And, yes, I know that a six your old can make something a similar shape with playing cards....)
You go over the 1G mark just by doing uncompressed HDTV, and uncompressed is good; for teleconferencing applications, codec latency is the killer, since your brain is hardwired with estimates of other people's response times. Now, you may think that HDTV is good quality, but if the future offers me 64Mpixel HDR images in stereo (or better, with full depth representation) at 100fps, I for one am not going to complain. Multiply it out; that's approaching the terabit per second, and I didn't even have to choose any outrageous numbers—2*8k*8k*3*16*100 is pretty conservative for a convincing virtual French window. Contemporary video, even HDTV, is not enough like being there, as you come to realise once you've had a chance to play with high-end systems (my stuff: http://ultravideo.mcgill.ca/activities.html; my friends': http://www.hp.com/halo; both a few years old by now).
So, yeah, what you really want the terabit network to your home for—is chatting with your mum.
I wish I could show you even current research teleconferencing systems in operation... and they suck compared to what I'd like to be doing.
(I'm not, by the way, suggesting that there are no useful low-latency techniques providing moderate compression for when you don't have gigabandwidth—of course there are. I'm just pointing out that these numbers are not unimaginable, and that if the pipe were provided, there would indeed be end-user applications for it.)
So you need 8 Mbit or so superjumbograms. In principle, not a problem, though some header fields need to be widened. The issue becomes one of memory bandwidth, instead: that's a fearsome hose, by today's standards.
Yeah, I suspected as much. At McGill, we used to do the Robocup thing, with the Aibos, on that kind of basis. Less gasoline and steel, but still lots of fun and confusion.
As a programmer I'm inclined to agree with you, but as someone who has been involved in the 'academic mega-demo' business myself, I have great sympathy for these guys. In my case I didn't get burned, but my boss got on the plane to go to the conference where he did a big showcase demo of my work only four hours after it ran for the first time. I think I got in another twelve hours of testing before showtime, basically while he was in transit. The demo itself involved the code running constantly for an hour, twice, in front of a large audience, on national TV no less, with no margin for error.
Does this mean I am a moron?
Nope, it means that I had absolutely no say in the schedule.
Since it worked, I was hailed as the messiah.
One part engineering, three parts sweat and six parts pure dumb luck, is more like my analysis.
See, what happens is, someone else sets the date. The real go/no go line is several months in advance of this date. The go decision is made (usually by management, often without detailed consultation with the programmers), the day arrives, and it kind of works, but you're not really ready. Not quite. Your choice: pull out and definitely have egg on your face, or go for it and maybe have egg.
So you roll the dice.
This was not one of those space shuttle situations where someone was going to die; the contest organisers knew that a ton of self-directed research-grade steel is a dangerous thing, and took the necessary precautions. So the decision to try it anyway was correct.
Maybe, as programmers, they knew what they were doing; maybe they did not. We are simply not in a position to judge. What we have seen here is simply that a public trial is a public test, and a test is a test is a test.
I must apologise in advance if this is a bit of a rant. I have a graduate degree in, well, programming language design, and I find some things close to my field just very upsetting. You wrote:
"...let's be honest, it's not like Java (and other GC languages) haven't been presented as if memory leaks were a thing of the past.
"As a matter of fact, some people will probably still claim that it's technically not a memory leak, but instead an object life-span issue.
"What surprises me is that outspoken proponents of managed languages use the garbage collection so often as a good thing, as if now you can be a sloppier programmer and get away with it.
"In reality you have to identify/control the lifespan of objects anyway, so I personally never understood what the big deal is about freeing memory manually. Not to mention that memory leaks in say, C++ code, really aren't that hard to find. The tools have become pretty freakin decent."
Perhaps you write very C++-adapted, boilerplate code. The reason garbage collection is essential in a programming language is that without it (a) you cannot provide a safe implementation of first-class functions, since they implicitly grant indefinite lifespan to arbitrary objects; and (b) you cannot build an abstract data type, whose implementation is hidden from the user, since no matter what other features the language may have, you can always tell whether the type a library has handed you is an automatically managed 'atomic' object, or a 'reference type.'
But why get so upset about weird advanced programming techniques not coming out quite right?
Because the kicker is, that to those of us who grew up with garbage collected languages, first class functions and abstract data types are elementary programming techniques. They are the bricks and mortar of which everything else is made. "Data structures + Algorithms," you see. Sure, C++ programmers consider it rocket science and discuss ad nauseum their clever smart pointer techniques and their baroque fifty-line function object implementations (or, if they advocate Boost, their two line function object implementation that requires a five thousand line header file and employs a completely different syntax from everything else they do). That's because they're now used to getting through life with no arms and artificial legs.
The sense in which garbage collected languages make memory leaks a thing of the past is this: that if you received a non-C++-adapted education, focussed on data structures and algorithms and not the fifty-three (or five thousand and six - they make money, let's invent more) Programming Patterns that help you evade the design flaws of the One True Language, and so you are in the habit of thinking and coding using callbacks, strategy functions, abstract types, state encapsulators - all those basic things that (unless the goal is avoiding the shortcomings of C++) are taught in school, and, indeed, all those things that both functional programming and object oriented programming were invented to make notationally direct, then you can just go ahead and code what you think, and you won't be bitten on the bum. The abstract model of computation comes reasonably close to matching the reality. Without it, you're still tracing through the execution in your mind at every step, because relying on the abstraction itself will get you burned.
Yes, a competent programmer can adapt. Yes, a competent programmer can think at the level of assembly language and either work out exactly the lifetime of the data, or do a second explicit computation, woven in with the main one, to determine it dynamically. A competent programmer can also deal with a language having divergent notations for data, expressions, statements, type expressions, templates, and type expressions within templates; or to phase of the moon dependent name resolution (templates again!); or to notational 'abstractions' requiring manual instantiation in real implementati
If I understand correctly, your argument is that because you (a) paid money, (b) are physically capable, and (c) are not dismayed by penalties imposed on other people, you have a moral and ethical right to proceed as you will. But this is clearly broken reasoning: all the same elements appear in taking out a contract to have someone killed, and I sincerely hope that you do not believe this gives you a moral and ethical basis to kill someone.
'Rights', it is true, are not inherent things; they are ideas developed and promulgated by a society. Various rights of ownership have been extended in our society: ownership of objects, and ownership of expressions of ideas. This might be sensible or it might be daft, but this thing has been done, as a subgame of the broader game of the rule of law, the thing that gives you a reasonable expectation of dying in your sleep.
The RIAA issue is one of cake-and-eat-it-too: if the RIAA wants the benefits of the law, in both letter and spirit, it should abide by the law, in both letter and spirit. The law does not, and indeed (for slightly subtle mathematical reasons of stability, if nothing else) should not, say that the RIAA must abide by one law to receive the benefits of another; but morally and ethically it ought to do so, and practically it cannot but expect that the law will be used against it as much as it uses it in its own favour.
Similarly, if you do not want people to break into your house and steal your shit and rape your cat and eat your crayons, then, morally and ethically, you, too, should abide by this quasi-arbitrary ownership game. If you don't like it, or so goes the theory, you vote for someone who isn't a complete tool next time you are given the chance, and with luck they will help see to it that the law is changed.
A lesson that many people, and many corporations, and many countries, need to learn is this: that to keep the moral high ground, you must first have the moral high ground. However personally inconvenient that may be.
Wanting the bad guys to lose is a reasonable stance, at least if you are honestly willing to learn the truth; but it remains so only until you become one of the bad guys yourself.
Intel wins in the market partly because it rides on Microsoft's coat tails (why Microsoft wins in the market is another long story, of course), and partly because it has fabrication technology that is actually sufficiently better than the competition to dominate most negative effects of architectural decisions. That in turn is because of economies of scale, and I understand was originally bootstrapped through their memory business, rather than by CPUs as such. And if it wins so utterly in the market, then it is very hard indeed not to be dragged along. Intel itself actively suffers from this; non-x86 Intel offerings have rarely fared as well as Intel hoped.
So yes, of course, compilation is an inherently hard problem. But that doesn't make x86 a good approach, any more than the fact that we don't yet have a complete understanding of the fundamentals of physics justifies a return to a cosmology of crystal spheres. Whatever the right technical solution is, we can be certain that it isn't x86. The Intel architecture dominates for other reasons entirely.
Used to live in Germany. Didn't always have Unicode. It's actually the official thing to do in that situation. But I still find mousing the thing off the character picker ridiculous. I don't know why we don't have a universal unicode input method on these things - it's not as if we're short of shift keys nowadays (even as an Emacs junkie and a believer in dedicating a shift state to the window manager, I would still happily sacrifice right-Alt and that stupid menu key to the cause - if I could get something for them that I wanted to use).
My Ubuntu laptop has three users: me, work, study. When I fire it up, I pick a user. That way, when I'm studying work and personal stuff don't distract me. Likewise when I work: study and life are not in my way. Only when I fire up the "me" user do I play, and I don't let work or studies weigh my mind down in that user. On the rare occasion that I need to access another user when I'm doing something, KDE has a great switch user function that lets me open another user on another graphical virtual terminal (CTRL-ALT-F8).
Yes, I agree with you. And I also agree that the current trend in VMs for everything is quite broken; they are useful for development, but for security and system stability, they are just picking up the slack for failed operating systems, because process isolation was supposed to be a core part of the definition of 'operating system' (I sometimes worry that nobody who went to school is still alive...).
However, the corporate world can be pretty hostile, both in terms of fights over 'intellectual property' and in terms of BOsFH who can get really controlling about hardware. Whence my otherwise completely overblown concern about segregating the personal and work categories in a mutually suspicious and ideally auditable manner.
I'm afraid I find this a little hard to interpret. It's a traditional thing to have flamewars about the 'point' of RISC (simply because - we're back in history here - the argument of H&P was 'measure twice, cut once' and RISC - an object, a project and a design schema - was just an application of that philosophy at a particular point in the technology curve), but the idea of RISC was most specifically to tune the visible ISA to the needs of a compiler back end (along with the execution engine, technological constraints, etc.) because the virtualisation layer that translates the source language into execution steps is better done in software than in hardware. Why? Because (a) in the modern world the source code is in a high level language and not in assembler, so optimising for assembler has no point; (b) the translation does not change once the source code and the target processor are fixed, and so can be done statically (just in time compilers actually make this false, as written; with the right hardware support they should substantially outperform static compilers on many tasks. But they actually strengthen my argument in the end, because they are more sensitive to unnnecessary ISA complexity than classical compilers, since they themselves need to be faster and lower complexity pieces of software); and (c) because the amount of end-user computation they do per gate per cycle approaches zero.
You say, well, but the clever thing about x86 is that behind the hardware translator there is a RISC core. Well, yeah, and you can think of classical microcoded machines that way, too, and it would be a darling method to implement a VAX, as well. The point is, rather, that it is not in any sense a RISC until that translation layer, redoing on every execution a nearly static translation, is moved into software, because that was the point.
You know, the x86 even has protected code segments. They could put a binary translator in firmware, have an entirely new ISA without a legacy decoder at all, and still be binary compatible. I find it really hard to understand why things are still being done with explicit layers in hardware. Of course, and relatedly, I also find it hard to understand why Intel don't give their compilers away for free, since they are a hardware company and the compilers are, let's face it, just the device drivers for their product....
Yes, bathtubbable is an important attribute that I forgot. I don't think I want rollable; I would never do that to a magazine, and I would never do that to a computer. As to the 4TB of storage, I think having a proper DFS makes that unnecessary.
Extremely good grammar Nazi. I was spelling it in German. The two little dots above the u can be rendered as a following e when diacritics are not available. Go and look it up.
The size of a magazine, sixteen hour battery life, five second suspend/resume, and a disconnected-mode DFS that actually works. One with on-disk encryption. The laptop should not want or need an identity distinct from its home network. And, ah, yeah, a hypervisor so that my 'home' and 'work' laptops can be the same physical object without causing any issues of system or data management propriety. That's all I ask.
x86 has a hella complex instruction set, and it's decoded in hardware, not software. On a computer. So: it's a CISC. A matter of English, sorry, not religion. Sure the execution method is not the ancient textbook in-order single-level fully microcoded strategy - but it wasn't on a VAX, either, so you can't weasel out of it that way.;)
Of course, the problem isn't with being a CISC, anyway. Complex instruction sets can save on external fetch bandwidth, and they can be fun, too! It was true 25 years ago, and it's still true now. CISC was never criticised as inherently bad, just as a poor engineering tradeoff, or perhaps a philosophy resulting in such poor tradeoffs.
The real point is twofold, and this: first, that the resources, however small, expended on emulating (no longer very thoroughly) the ancient 8086 are clearly ill-spent. While this may have come about incrementally, it could all by now be done in software for less. And second, while don't write assembly code any more, we do still need machines as compiler targets; and a compiler either wants an ISA that is simple enough to model in detail (the classic RISC theory) and/or orthogonal enough to exploit thoroughly (the CISC theory). Intel (and AMD, too, of course; the 64 bit mode is baffling in its baroque design) gives us neither; x86 is simply not a plausible compiler target. It never was, and it's getting worse and worse. And that is precisely why new instructions are not taken up rapidly: we can't just add three lines to the table in the compiler and have it work, as we should be able to do; we can't just automatically generate and ship fat binaries that exploit new capabilities where they provide for faster code, as must be possible for these instruction set increments to be worthwhile.
Consider, for example, a hypothetical machine in which there are a number of identical, wide registers, each of which can be split into lanes of any power of two width; and an orthogonal set of cleanly encoded instructions that apply to those registers. CISCy, yes, but also a nice target that we can write a clean, flexible, extensible compiler back end for. Why can't we have that, instead? (Even as a frikkin' mode if back compatibility is all and silicon is free, as you appear to argue!)
It shouldn't be a question of arguing how hard it is or isn't for the Intel engineers to add new clever cruft to the old dumb cruft, but one of what it takes to deploy a feature end-to-end, from high level language source to operations executed, and how to streamline that process.
So, sure, give us successive extensions to the general-purpose hardware, but give them to us in a form that can actually be used, not merely as techno-marketroids' checklist features!
Slashdot Mirror
These are really quesitons about the PDF format.
As to (1), well, no, but I can't do that in print, either. Basically I'm limited to things I could print on my printer, with PDFs being the simplest. That does include a large number of texts and reference materials in maths and computer science, and all the journals I read regularly. It doesn't include a large number of the books on my shelves, but many of them are out of print, so if I were looking for them anew, electronic copies would probably be likely to surface sooner than physical ones.
For long-term accessibility, (2), I see no reason to suppose that PDFs will 'die' in the sense of becoming uninterpretable; they can be rendered to any raster (digital or physical), and in the process become as durable as any data, including printed data.
The archival problem for data is basically the converse of that of the conservation of physical objects. Physical objects, by and large, are better left untouched; use degrades them. Data objects are best visited periodically, both to activate error correction mechanisms, and to ensure that it is discovered in time that data formats are beginning to be seen as 'obscure' and that recoding is in order. (Though, of course, ideally, the entire web infrastructure would be accessed by rigid, content-derived identifiers, and forward compatibility would be addressed systematically by emulators, so losing the decoder would become very unlikely indeed.)
Ooh, one throw-away line is "rabid anti-Microsoft content"? You may observe that I said just as much bad about September. But, as it happens, this is the truth: almost everyone's view of the Internet-enabled workstation originally involved a substantial element of 'serverness'. Microsoft disagreed, favouring a single-tasking, client-only model of the world. And Microsoft won, and the Internet suffered.
In the old days, FTP was peer-to-peer. Email was instant. User interfaces were network transparent. How can you imagine that Microsoft had no part in the death of that reality?
!. !, good sir-or-madam. !.
In the lab where I was working at the time, it was vaguely rude not to respond to email within, say, 60 seconds. I mean, of course, everyone there was a hyperforcussed personality type and would ignore people at their door for as long as it took to finish typing the fix/paragraph/whatever, but email response times were comparable to those for physical presence. Nowadays, you have to go and screw around in the preferences to get your poll rate up to once in 60 seconds; people seem to consider that 'reasonable' delivery lags are 15 minutes, or an hour, or a day.
Well, no shit you can't use that to arrange lunch! Even a 120 second lag (two minimum poll times with Thunderbird) between 'Indian?' and 'We're out of here!' is unacceptable as far as my metabolism is concerned.
If I am interpreting the signals from moderation (and your reply) correctly, 30% of the population here thinks I am making this up, which I can only conclude is because they do not know that Internet email is natively a push technology, and was once push all the way to the end user. That is, SMTP was an instant messaging technology, until it was effectively subverted by POP.
So of course I'm pining for the old days: I have not had a better communications environment than I had with SMTP+deliver+xface+mh-e.
Sure, there are compensating advantages to the modern world. Compile times are much shorter now! The question is, why did we give up the parts that worked well? And then there's the small matter of the thing we were actually discussing—why attitudes to email and messaging might have changed. Breaking the functionality of email would be one hell of a relevant point, don't you think? Even if (as I suspect) you have never experienced it working properly?
I suspect it's chicken-and-egg. The sensors used in digital still cameras seem to be capable of video frame rates, and the sensors used in digital video cameras have much higher native resolution than shows through the video encoding (the extra res is used for image stabilisation and digital zoom). The expensive part of TV cameras is the lenses, not the sensors, and that's not as important to the experience as the latency and resolution. So the input devices could exist. The problem is that in the mind of the manufacturers there's little point: it takes a RAID rack that consumers don't own to record even HDTV, and it takes a network connection that they don't have access to to transmit it.
This is a huge frustration to computer vision and interactive environment researchers, let me tell you! We'd have all kinds of other cool stuff if good cameras were cheap enough to buy in quantity, because now we can do general computation on GPUs, we could make some great applications.
Chicken and egg, chicken and egg.
I'm really sorry. This is going to sound like an ad.
I'm carrying an iRex iLiad. Everywhere. It's very slightly more than an ebook reader, because it has a Wacom stylus and you can write on it; then again, it is significantly more expensive because of this. But here's the thing:
It is much nicer than a physical book.
I was absolutely amazed.
Here's why:
First, it has more usable display area than a book. Why? Because although a quarter of the face is case surround, there is no facing page. This makes a huge difference when reading on the bus, or walking down the street, or while drinking a cup of coffee.
Second, it may not be lighter than one book, but it is certainly lighter than three. So now, in a single device I can hang from my belt when I don't mind looking like a dork but want my hands free (which is usually, I'm afraid), I can have a light novel, a heavy novel, something of historical interest, a programming language manual, the reference materials for whatever I'm working on, three technical journals, my entire archive of research papers, my handwritten notes from my chinese class, my meeting notes, my doodles, and my RSS feeds. This is a win, even if I'm now mostly reading classics while I wait for the publishing industry to get its head out and start charging only the software costs for new releases.
Third, and this still weirds me out, in one important way, epaper outperforms contemporary physical paper. It is greyer. "WTF?" I hear you say, "don't you want maximum contrast?" But the answer appears to be that modern paper is made slightly fluorescent; certainly it is immensely white. In direct sunlight, it can be painful, and is certainly hard to read. The iLiad display is disappointing in situations where your mum would have yelled "turn on the light! You'll ruin your eyes!" but in good light it is great and outdoors it is much better than great.
Don't you see? I can now be a functional researcher in the park. With a coffee in one hand. And my book bag increased in capacity by several orders of magnitude and reduced in weight to less than a pound. (Well, except that I live in Canada and its is f***ing winter now and will be for six more months....)
I really hate to sound like a fanboi, but for me, a piece of the long-promised future recently arrived by DHL, let me tell you.
"True community backlash"?!? This is ... this is ... I don't know, I was brought up with ideas like "due process of law", myself. The duty of the community, and please excuse my religious background if you can, is to love their neighbours. Punishment is just not the domain of the individual, in a civilised society.
So, I grant, it should not be necessary to conceal anyone's identity, because everyone should be responsible and generous adults, suitably measured in their responses. But unfortunately, we are forced to strive for anonymity of the innocent and the guilty alike, because we have to deal with dangerous asshats who believe in things like "true community backlash."
In the old days, email actually worked. It was delivered to your box, and comsat was there to biff you when it arrived. I even had my beloved xface running at the edge of my screen so I could see the incoming and catch the ones from the five people I cared about. And in that environment, we surely did use email to arrange lunch; it was quicker than shouting down the hall.
Then Microsoft figured out that the Internet wasn't going to go away. And suddenly it was all DHCP and POP and all the applications that used to blow started to suck—sorry, those that used to push started to pull—and the Internet stopped feeling like the Internet and turned into what we have today, a kind of UUCP on steroids, where communication doesn't happen until the next scheduled contact time, because an IP number no longer successfully identifies a node and everyone lives in fear, cowering behind firewalls and running no daemons.
And by now email is little better than snail mail, and the interfaces are worse (no xface or deliver scripts in Windows!) and it sucks, and of course people are looking for alternatives so that they can arrange lunch and communicate selectively with the people they care about.
So, I know I'm an old fart by now, but in the old days, before Microsoft Rule and the Eternal September, the technology used to work. I'm not making this up....
Have you considered the cost of doing this by 'trial and error'? You need a lot of people, it takes a lot of time, a lot of materials, and you have to expend immense political capital even to motivate one attempt. Certainly designs evolve over time, but serious engineering thought clearly went into the original undertakings. I can't imagine how you can think otherwise.
Then again, perhaps you consider any application of the empirical method to be 'trial and error'—in which case what we do today is no different, since the numbers we plug into the models do arise from measurement.
Ah, wait a minute, I see. You feel that it is relevant that a two year old can build a six inch beam bridge. Suuuuuure. A six inch beam bridge holding up a plastic penguin in the living room is just exactly like a 150 foot suspension bridge carrying pack animals across a canyon. All the same intuitions will apply! Scaling issues? What scaling issues? But even in Wile E. Coyote's happy death-free world you are mistaken.
Seriously, give some honest thought sometime to how you would build so much as a Stonehenge without modern technology. (And, yes, I know that a six your old can make something a similar shape with playing cards....)
You go over the 1G mark just by doing uncompressed HDTV, and uncompressed is good; for teleconferencing applications, codec latency is the killer, since your brain is hardwired with estimates of other people's response times. Now, you may think that HDTV is good quality, but if the future offers me 64Mpixel HDR images in stereo (or better, with full depth representation) at 100fps, I for one am not going to complain. Multiply it out; that's approaching the terabit per second, and I didn't even have to choose any outrageous numbers—2*8k*8k*3*16*100 is pretty conservative for a convincing virtual French window. Contemporary video, even HDTV, is not enough like being there, as you come to realise once you've had a chance to play with high-end systems (my stuff: http://ultravideo.mcgill.ca/activities.html; my friends': http://www.hp.com/halo; both a few years old by now).
So, yeah, what you really want the terabit network to your home for—is chatting with your mum.
I wish I could show you even current research teleconferencing systems in operation... and they suck compared to what I'd like to be doing.
(I'm not, by the way, suggesting that there are no useful low-latency techniques providing moderate compression for when you don't have gigabandwidth—of course there are. I'm just pointing out that these numbers are not unimaginable, and that if the pipe were provided, there would indeed be end-user applications for it.)
So you need 8 Mbit or so superjumbograms. In principle, not a problem, though some header fields need to be widened. The issue becomes one of memory bandwidth, instead: that's a fearsome hose, by today's standards.
Yeah, I suspected as much. At McGill, we used to do the Robocup thing, with the Aibos, on that kind of basis. Less gasoline and steel, but still lots of fun and confusion.
As a programmer I'm inclined to agree with you, but as someone who has been involved in the 'academic mega-demo' business myself, I have great sympathy for these guys. In my case I didn't get burned, but my boss got on the plane to go to the conference where he did a big showcase demo of my work only four hours after it ran for the first time. I think I got in another twelve hours of testing before showtime, basically while he was in transit. The demo itself involved the code running constantly for an hour, twice, in front of a large audience, on national TV no less, with no margin for error.
Does this mean I am a moron?
Nope, it means that I had absolutely no say in the schedule.
Since it worked, I was hailed as the messiah.
One part engineering, three parts sweat and six parts pure dumb luck, is more like my analysis.
See, what happens is, someone else sets the date. The real go/no go line is several months in advance of this date. The go decision is made (usually by management, often without detailed consultation with the programmers), the day arrives, and it kind of works, but you're not really ready. Not quite. Your choice: pull out and definitely have egg on your face, or go for it and maybe have egg.
So you roll the dice.
This was not one of those space shuttle situations where someone was going to die; the contest organisers knew that a ton of self-directed research-grade steel is a dangerous thing, and took the necessary precautions. So the decision to try it anyway was correct.
Maybe, as programmers, they knew what they were doing; maybe they did not. We are simply not in a position to judge. What we have seen here is simply that a public trial is a public test, and a test is a test is a test.
I must apologise in advance if this is a bit of a rant. I have a graduate degree in, well, programming language design, and I find some things close to my field just very upsetting. You wrote:
Perhaps you write very C++-adapted, boilerplate code. The reason garbage collection is essential in a programming language is that without it (a) you cannot provide a safe implementation of first-class functions, since they implicitly grant indefinite lifespan to arbitrary objects; and (b) you cannot build an abstract data type, whose implementation is hidden from the user, since no matter what other features the language may have, you can always tell whether the type a library has handed you is an automatically managed 'atomic' object, or a 'reference type.'
But why get so upset about weird advanced programming techniques not coming out quite right?
Because the kicker is, that to those of us who grew up with garbage collected languages, first class functions and abstract data types are elementary programming techniques. They are the bricks and mortar of which everything else is made. "Data structures + Algorithms," you see. Sure, C++ programmers consider it rocket science and discuss ad nauseum their clever smart pointer techniques and their baroque fifty-line function object implementations (or, if they advocate Boost, their two line function object implementation that requires a five thousand line header file and employs a completely different syntax from everything else they do). That's because they're now used to getting through life with no arms and artificial legs.
The sense in which garbage collected languages make memory leaks a thing of the past is this: that if you received a non-C++-adapted education, focussed on data structures and algorithms and not the fifty-three (or five thousand and six - they make money, let's invent more) Programming Patterns that help you evade the design flaws of the One True Language, and so you are in the habit of thinking and coding using callbacks, strategy functions, abstract types, state encapsulators - all those basic things that (unless the goal is avoiding the shortcomings of C++) are taught in school, and, indeed, all those things that both functional programming and object oriented programming were invented to make notationally direct, then you can just go ahead and code what you think, and you won't be bitten on the bum. The abstract model of computation comes reasonably close to matching the reality. Without it, you're still tracing through the execution in your mind at every step, because relying on the abstraction itself will get you burned.
Yes, a competent programmer can adapt. Yes, a competent programmer can think at the level of assembly language and either work out exactly the lifetime of the data, or do a second explicit computation, woven in with the main one, to determine it dynamically. A competent programmer can also deal with a language having divergent notations for data, expressions, statements, type expressions, templates, and type expressions within templates; or to phase of the moon dependent name resolution (templates again!); or to notational 'abstractions' requiring manual instantiation in real implementati
If I understand correctly, your argument is that because you (a) paid money, (b) are physically capable, and (c) are not dismayed by penalties imposed on other people, you have a moral and ethical right to proceed as you will. But this is clearly broken reasoning: all the same elements appear in taking out a contract to have someone killed, and I sincerely hope that you do not believe this gives you a moral and ethical basis to kill someone.
'Rights', it is true, are not inherent things; they are ideas developed and promulgated by a society. Various rights of ownership have been extended in our society: ownership of objects, and ownership of expressions of ideas. This might be sensible or it might be daft, but this thing has been done, as a subgame of the broader game of the rule of law, the thing that gives you a reasonable expectation of dying in your sleep.
The RIAA issue is one of cake-and-eat-it-too: if the RIAA wants the benefits of the law, in both letter and spirit, it should abide by the law, in both letter and spirit. The law does not, and indeed (for slightly subtle mathematical reasons of stability, if nothing else) should not, say that the RIAA must abide by one law to receive the benefits of another; but morally and ethically it ought to do so, and practically it cannot but expect that the law will be used against it as much as it uses it in its own favour.
Similarly, if you do not want people to break into your house and steal your shit and rape your cat and eat your crayons, then, morally and ethically, you, too, should abide by this quasi-arbitrary ownership game. If you don't like it, or so goes the theory, you vote for someone who isn't a complete tool next time you are given the chance, and with luck they will help see to it that the law is changed.
A lesson that many people, and many corporations, and many countries, need to learn is this: that to keep the moral high ground, you must first have the moral high ground. However personally inconvenient that may be.
Wanting the bad guys to lose is a reasonable stance, at least if you are honestly willing to learn the truth; but it remains so only until you become one of the bad guys yourself.
Intel wins in the market partly because it rides on Microsoft's coat tails (why Microsoft wins in the market is another long story, of course), and partly because it has fabrication technology that is actually sufficiently better than the competition to dominate most negative effects of architectural decisions. That in turn is because of economies of scale, and I understand was originally bootstrapped through their memory business, rather than by CPUs as such. And if it wins so utterly in the market, then it is very hard indeed not to be dragged along. Intel itself actively suffers from this; non-x86 Intel offerings have rarely fared as well as Intel hoped.
So yes, of course, compilation is an inherently hard problem. But that doesn't make x86 a good approach, any more than the fact that we don't yet have a complete understanding of the fundamentals of physics justifies a return to a cosmology of crystal spheres. Whatever the right technical solution is, we can be certain that it isn't x86. The Intel architecture dominates for other reasons entirely.
The 1982 what? It's, um, a toilet contest? :)
Ah, you must have one of those huge keyboards with a numeric keypad - and a chart of obscure numeric codes on the wall! ;)
Used to live in Germany. Didn't always have Unicode. It's actually the official thing to do in that situation. But I still find mousing the thing off the character picker ridiculous. I don't know why we don't have a universal unicode input method on these things - it's not as if we're short of shift keys nowadays (even as an Emacs junkie and a believer in dedicating a shift state to the window manager, I would still happily sacrifice right-Alt and that stupid menu key to the cause - if I could get something for them that I wanted to use).
Yes, I agree with you. And I also agree that the current trend in VMs for everything is quite broken; they are useful for development, but for security and system stability, they are just picking up the slack for failed operating systems, because process isolation was supposed to be a core part of the definition of 'operating system' (I sometimes worry that nobody who went to school is still alive...).
However, the corporate world can be pretty hostile, both in terms of fights over 'intellectual property' and in terms of BOsFH who can get really controlling about hardware. Whence my otherwise completely overblown concern about segregating the personal and work categories in a mutually suspicious and ideally auditable manner.
I'm afraid I find this a little hard to interpret. It's a traditional thing to have flamewars about the 'point' of RISC (simply because - we're back in history here - the argument of H&P was 'measure twice, cut once' and RISC - an object, a project and a design schema - was just an application of that philosophy at a particular point in the technology curve), but the idea of RISC was most specifically to tune the visible ISA to the needs of a compiler back end (along with the execution engine, technological constraints, etc.) because the virtualisation layer that translates the source language into execution steps is better done in software than in hardware. Why? Because (a) in the modern world the source code is in a high level language and not in assembler, so optimising for assembler has no point; (b) the translation does not change once the source code and the target processor are fixed, and so can be done statically (just in time compilers actually make this false, as written; with the right hardware support they should substantially outperform static compilers on many tasks. But they actually strengthen my argument in the end, because they are more sensitive to unnnecessary ISA complexity than classical compilers, since they themselves need to be faster and lower complexity pieces of software); and (c) because the amount of end-user computation they do per gate per cycle approaches zero.
You say, well, but the clever thing about x86 is that behind the hardware translator there is a RISC core. Well, yeah, and you can think of classical microcoded machines that way, too, and it would be a darling method to implement a VAX, as well. The point is, rather, that it is not in any sense a RISC until that translation layer, redoing on every execution a nearly static translation, is moved into software, because that was the point.
You know, the x86 even has protected code segments. They could put a binary translator in firmware, have an entirely new ISA without a legacy decoder at all, and still be binary compatible. I find it really hard to understand why things are still being done with explicit layers in hardware. Of course, and relatedly, I also find it hard to understand why Intel don't give their compilers away for free, since they are a hardware company and the compilers are, let's face it, just the device drivers for their product....
Yes, bathtubbable is an important attribute that I forgot. I don't think I want rollable; I would never do that to a magazine, and I would never do that to a computer. As to the 4TB of storage, I think having a proper DFS makes that unnecessary.
Extremely good grammar Nazi. I was spelling it in German. The two little dots above the u can be rendered as a following e when diacritics are not available. Go and look it up.
The size of a magazine, sixteen hour battery life, five second suspend/resume, and a disconnected-mode DFS that actually works. One with on-disk encryption. The laptop should not want or need an identity distinct from its home network. And, ah, yeah, a hypervisor so that my 'home' and 'work' laptops can be the same physical object without causing any issues of system or data management propriety. That's all I ask.
x86 has a hella complex instruction set, and it's decoded in hardware, not software. On a computer. So: it's a CISC. A matter of English, sorry, not religion. Sure the execution method is not the ancient textbook in-order single-level fully microcoded strategy - but it wasn't on a VAX, either, so you can't weasel out of it that way. ;)
Of course, the problem isn't with being a CISC, anyway. Complex instruction sets can save on external fetch bandwidth, and they can be fun, too! It was true 25 years ago, and it's still true now. CISC was never criticised as inherently bad, just as a poor engineering tradeoff, or perhaps a philosophy resulting in such poor tradeoffs.
The real point is twofold, and this: first, that the resources, however small, expended on emulating (no longer very thoroughly) the ancient 8086 are clearly ill-spent. While this may have come about incrementally, it could all by now be done in software for less. And second, while don't write assembly code any more, we do still need machines as compiler targets; and a compiler either wants an ISA that is simple enough to model in detail (the classic RISC theory) and/or orthogonal enough to exploit thoroughly (the CISC theory). Intel (and AMD, too, of course; the 64 bit mode is baffling in its baroque design) gives us neither; x86 is simply not a plausible compiler target. It never was, and it's getting worse and worse. And that is precisely why new instructions are not taken up rapidly: we can't just add three lines to the table in the compiler and have it work, as we should be able to do; we can't just automatically generate and ship fat binaries that exploit new capabilities where they provide for faster code, as must be possible for these instruction set increments to be worthwhile.
Consider, for example, a hypothetical machine in which there are a number of identical, wide registers, each of which can be split into lanes of any power of two width; and an orthogonal set of cleanly encoded instructions that apply to those registers. CISCy, yes, but also a nice target that we can write a clean, flexible, extensible compiler back end for. Why can't we have that, instead? (Even as a frikkin' mode if back compatibility is all and silicon is free, as you appear to argue!)
It shouldn't be a question of arguing how hard it is or isn't for the Intel engineers to add new clever cruft to the old dumb cruft, but one of what it takes to deploy a feature end-to-end, from high level language source to operations executed, and how to streamline that process.
So, sure, give us successive extensions to the general-purpose hardware, but give them to us in a form that can actually be used, not merely as techno-marketroids' checklist features!