This article, though well-written, bothers me in several ways.
The technology described in the article is really a display technology. Why should it be limited to so-called e-books? If it can update at a reasonable rate, it ought to replace both CRT and notebook monitors. Long before we can afford several hundred pages of this stuff bound together, I should be able to get a 100dpi 48" x 36" display tacked to the wall of my cube, which is vastly more interesting to me than an e-book. Even if the refresh rate is poor, I could still use it show dynamic load stats for our servers or something.
Why make dedicated e-books when we can make general-purpose portable computers with great displays? Why should you carry a pda with a low-res display and an e-book with a hi-res display? The whole thing is predicated on people being stupid and only accepting objects which have an analog in the past. People aren't that stupid, and they'll prefer the general-purpose device, given a choice.
The author glossed over the social implications of the e-book movement. It is a naked power grab by the intellectual property aristocracy, and the chilling social implications completely dwarf any question of convenience or nostalgia.
The questions are "just endless," Sheridon acknowledges. "But I think this in the end will bring down the cost of books so much that it will make it possible for more people to have their own personal libraries." Without the costs of printing and distributing, book prices could fall without loss of income to writers and editors.
This is a very naive idea. Did the price of recorded music fall when the cost of production fell?
Because an entire book reduces to a scatter of iron oxide particles on a computer hard drive, no text need ever go out of print-it can always sit there, whirling on the hard drive, until needed by the reader.
I'll be very surprised if the publishers allow this to happen. Rather, I'd expect some type of expiration mechanism, even if it's the de facto barrier of being unable to copy the data to a new drive. The author is again glossing over the key issue of who controls the information.
Scientific texts could be continually altered to keep pace with research.
OK, this author is hopelessly naive. Anyone who can mention such a capability without seeing that the potential for abuse vastly outweighs the benefits is more optimistic than me.
Re:The natural evolution of this...
on
License to Sit
·
· Score: 1
your average European bathroom is nowhere near as nice as an average US/Canadian bathroom.
I think the US will fall behind Canada soon. The US has banned decently sized toilet tanks, allegedly for environmental reasons. Americans have been buying them in Canada and trying with mixed results to bring them across the border. In some cases, customs has turned them back.
Oh, I was assuming that someone is trying to host prohibited content within Germany. I guess you're assuming that it's hosted outside Germany, in which case anonymyzing proxies would actually bypass the system.
I really miss ACAD. It was my first experience of a really good UI. Later when I learned Unix, I felt some similarity in bash. It may be subjective, but I think CAD drafters have gotten worse and worse through the years. Partly because the older generation of CAD drafters had real board drafting experience. But also partly through the GUIfication of ACAD. I've seen insanely slow drafters who only use the GUI.
That's not the same. That's making the human look up data when the computer could do it. Do you disapprove of tab completion in general? All the info it gives you is available with ls. On second thought, ls has so many options that the tab completion would look a bit like a man page. Maybe the shell should just give the option letters together with the GNU long names as a mnemonic.
I like the idea. I'd like the ability to build up 'selection sets' ala AutoCAD. Although I guess you could do it now with X: SSET="$SSET (moves mouse over filename, doubleclicks, middleclicks)" Also, what if you hovered the mouse over a piece of text (like a filename) and different key brought up different imagemaps? Like if I hit ctrl-A while hovering over a filename, a 3x4 grid permission bits appears centered over the filename. I can click to change them. When I move the mouse away, the grid disappears. But please don't break copy-and-paste or the ctrl-button3 menu.
Re:BillG forgot the "Evil Overlord Rules of Thumb"
on
Pride Before The Fall
·
· Score: 2
And from that page: 24. I will maintain a realistic assessment of my strengths and weaknesses. Even though this takes some of the fun out of the job, at least I will never utter the line "No, this cannot be! I AM INVINCIBLE!!!" (After that, death is usually instantaneous.) This seems strangely relevant.
Can you say 'Internet Obfuscated Fab Contest'? "Ooh, that's a nice trigger guard for my paintball gun. I'll render it!" 10 minutes later, a rabid flesh-eating robot shaped like a paintball-gun-triggerguard emerges...
Well, much of the power and generality you're praising comes from the fact that every process has three file descriptors, STDIN, STDOUT and STDERR with standardized meanings. Now imagine if we add a fourth file descriptor to the Unix paradigm: STDINFO. A program could optionally print messages to STDINFO in a standardized format (we'd need an RFC) which could be parsed by numerous tools. For example tar might print to STDINFO "percent_complete=34". A GUI might use this to power a progress bar. However those of us who aren't into GUI's would find lots of cool uses for this info. How cool would it be to type ps -<something> and have most of the processes show certain metrics, like how many lines of input they've processed and how many errors they've encountered? Or imagine typing "tar -xvf huge.tar 3|grep'percent_complete=5[0-9]'>&1". In other words, let me know when it's half done. I think this would rock. And adding a few printf's to tar wouldn't be much bloat.
mv: when moving multiple files, last argument must be a directory
If there are no.html files in the directory, the shell won't expand *.html - it will pass it as a literal to mv. Mv sees that 1) it has more than 2 arguments and 2) the last arg is not a directory so it exits with an error message. If there's one.html in the directory, the shell will pass this to mv as the last arg, and again mv will error out because it's not a directory. If there are multiple.html files, the shell will expand *.html to this list and the last file in the list will be seen as the target directory, with the same results as above.
I agree, but imagine if tar provided its status info to the OS through a more generalized interface, so it was stored in the process table. Some people would run a GUI that exploits this - you wouldn't. But if you're curious about how far that backgrounded tar got, you might type 'status --complete $PID' and get back '32%' or something. This would be a much cleaner solution than having tar attempt to drive a GUI directly.
Well that's cool, but is there any particular reason it needs to be graphical? Imagine a smart shell: I type 'ls -' and it shows me all the options to ls. There should be another keystroke, so that if I type 'ls -alR' it would explain what those options do, then return my command line in the same state for further editing.
But what if the program merely output escape codes which were interpreted by the terminal emulator (like xterm) to render the widgets? Cat might go from 10 lines to 11. Better yet, imagine if the API for this was generalized to 'provide info about program's current state' rather than just 'provide GUI widgets'. Imagine writing a shell pipeline to "kill all tar's that are more than 1 hr old and less than 15% done". Anyhow, the makefiles could compile and install two binaries: one without the enhancements, in the normal place, and one with, in/usr/local/gui/bin or something. Then you'd set your PATH to use/not use. As for windows popping up like mad, I'd rather the terminal emulator render the widgets in its own window. It could limit the number of widgets or the % of area used by them. Put the control in the terminal emulator, not in tar, cat etc.
For example, if I run tar inside X, then tar ought to pop up a completion bar.
One way to implement such things would be to write a replacement for xterm and define a new terminal type. Just as xterm has escape codes to set the foreground and background colors, the new termi nal could have additional escape codes to create or update certain display widgets. I'd rather such widgets were part of the terminal window than poppped as separate windows, which sounds somewhat uncontrollable. You'd also need a good scheme to kill the widgets if the process that requested them dies . If done this way, the gui enhancement would still work well over a 300 baud modem. If you're using a terminal that doesn't support these capabilities, the termcap database wouldn't return any codes for them, and everything would work as it used to. I used to use AutoCAD heavily, and I liked its interface, which was something like a Unix shell with the ability to mix mouse clicks with words, and to see the results of commands after you typed them. Imagine if you type 'ln -s/etc/foo.cfg.foorc' and you see a red line appear in a GUI reflecting the symlink. I think the most useful aspect of the GUI is visualization, and this is not used much by either Windows or X.
Why do you think an anonymous proxy would be any use against such a system? Alice send an http request to Bob. (Alice and Bob are hosts). Bob sends Alice the requested data. Mallet, the censor, notices that the data is 'illegal' and adds Bob's IP to the blacklist. Now Carol sends an http request to Bob. The routers drop her request. Even if it got through, the routers would drop Bob's response. So Carol proxies her request through Peter, an anonymizing proxy. Peter sends an http request to Bob. The request never makes it, because the routers are dropping all packets to Bob. Anonymous proxies won't help at all.
There's no way to censor Gnutella, and the like, regardless, as their isn't a central server to ban.
Imagine that the first time a Gnutella node delivers unathorized content, the IP address of the Gnutella node is added to a nationwide blacklist. No cooperating router will handle packets from that IP address. If the node has a static IP, the node owner has a problem. His box is effectively off the internet. If the node has a dynamic IP, the ISP has a problem. One of their dynamic IP's is dead. To get it 're-activated', they'll terminate the offending account.
Let's just make a little addendum to the treaty of Versailles that says we own the Internet and call it a day.
The treaty of Versailles was a huge mistake. By humiliating Germany, it paved the way for Hitler. That's why after WWII the US helped rebuild Germany and Japan. Anyhow, the only hope for the Internet lies in the disagreement between nations about what should be censored. Every country on this planet wants to censor something. So if 'we' - presumably the US - owned the Internet, we'd enforce our censorship without fear of circumvention. And every politician would add his 2c to the list of what should be censored.
Would it really have hurt them to put a "this is a parody" disclaimer at the bottom of the site?
Yes it would. It would have detracted from the fun. And why should they detract from the fun to pander to the less intelligent?
If I had a "how to kill your neighbours" site and posted (faked) pictures, do you think I should get investigated?
No, I don't. I think a criminal investigation should only be launched when there's actual evidence that a crime has been committed. In this case, a corpse or missing person.
Maybe a we should consider people reporting crimes to 911 as just 'pranks' to?
It's hardly the same. 911 is for reporting emergencies. The web is for fetching information from remote servers. No guarantees are made that the information is serious or accurate. Instead of putting a disclaimer on the web site, let's put a disclaimer in the web browsers. Dialog box: "Danger! You are entering the World Wide Web! You may be trolled or offended. Click 'Accept' to continue." I'm assuming that idiots don't use lynx.
You can be a competent or even excellent programmer without being a good cryptographer. Many of the fundamental ideas of cryptography are non-obvious to programmers.
I believe the last random number generator I wrote is still in use as one of several alternate generators in a library used by the local maths dept. modelling group.
Perfect example. It's possible (in fact common) to write a PRNG which is quite good statisticaly while being quite poor cryptographically. A large LFSR is an example. Read Schneier's
Thanks. You said exactly what I've wanted to say to those who are underestimating this task. But leaving aside engineering cleverness, the rigging work below the bridge deck must have taken a lot of courage. Working aloft, in the dark, in constant danger of arrest or falling is not everyone's cup of tea.
They caused a massive traffic congestion and rerouting of shipping lanes.
The students didn't cause traffic congestion - the CHP did. The VW was under the bridge. It had no impact, direct or indirect, on the traffic flow over the bridge. As for the rerouting of shipping lanes, I'd like to know how many vessels were actually affected. I've spent some time at Fort Point (right underneath the bridge) and never seen a single ship go by. Plenty of boats, but those aren't affected.
Don't real engineers want to avoid this?
No. Real engineers want to accomplish their goals in the fastest, most elegant and laziest way possible. There's nothing to guarrantee that the goals an engineer happens to pursue are goals you'd approve of.
In the end engineers had to cut it down and let the whole thing sink to the bottom of the bay. Doesn't that fall into "enviromental contamination"?
Nobody had to cut it down. There were any number of ways to skin that particular cat. I don't think we can blame the students for the (possibly ill-considered) actions of others.
Think of the resources the city engineers had to use to investigate and neutralize the problem.
You're reminding me of corporations that claim they 'lost millions' when their websites were defaced. You're taking a trivial event and making it sound like WWIII with PHB-speak: 'resources', 'investigate', 'neutralize'.
Why should the students pay for the 'emergency services'? There was no emergency, as any educated person could see. An empty car hanging from a bridge is not an emergency. You also imply that the prank blocked traffic. It didn't. The police blocked traffic.
I don't think the students caused any traffic trouble. The CHP caused the trouble by pointlessly blocking the road. Did they think the weight of a VW bug was going to break the bridge? If you want the CHP officers sentenced to community service, I'll second that.
I've generally found text-based mail (mutt) to be much more time-efficient than GUI mail clients. I grind through a huge amount of mail each morning, and greatly benefit from the speed with which mutt moves from message to message. However, I do miss one thing about 'rich mail' - the ability to use tables. Frequently a table expresses data best, but I'm not going to take the time to hand-build it in vi.
But if I understand correctly, toolkits compete somewhat on the basis of API. I'm passing on hearsay here, as I've never programmed for any of these toolkits. Elsewhere in this thread, someone says the Motif API is better designed and more consistent than the Gtk API. It seems like OO programmers prefer Qt to Gtk. Meanwhile, I still don't see commercial software developers spending millions to port their Unix apps from one toolkit to another. For example, I use Meeting Maker at work. It uses Motif. To the people who make the purchasing decision, the choice of toolkit is not even on the agenda. So unless MM rewrites from scratch for some reason, I don't see them changing.
Because he's diverted the energy that should have gone into man pages towards 'info'. Because he ought to know better than to break a good and widely accepted standard. Because I greatly like and respect RMS, and this decision shows him at his worst.
...it's the Distributor's problem to put a fucking working help system in place...
You definitely have a point. Linux distributors don't seem to take responsibility for their OS the way other Unix makers do. However, isn't Red Hat still losing money? Maybe for the slim margins they make they can't afford to pay much attention to each package. I wonder if the vendors could pool their resources - split up the man pages proportional to sales or something?
Slashdot Mirror
This is a very naive idea. Did the price of recorded music fall when the cost of production fell?
I'll be very surprised if the publishers allow this to happen. Rather, I'd expect some type of expiration mechanism, even if it's the de facto barrier of being unable to copy the data to a new drive. The author is again glossing over the key issue of who controls the information.
OK, this author is hopelessly naive. Anyone who can mention such a capability without seeing that the potential for abuse vastly outweighs the benefits is more optimistic than me.
I think the US will fall behind Canada soon. The US has banned decently sized toilet tanks, allegedly for environmental reasons. Americans have been buying them in Canada and trying with mixed results to bring them across the border. In some cases, customs has turned them back.
Oh, I was assuming that someone is trying to host prohibited content within Germany. I guess you're assuming that it's hosted outside Germany, in which case anonymyzing proxies would actually bypass the system.
I really miss ACAD. It was my first experience of a really good UI. Later when I learned Unix, I felt some similarity in bash.
It may be subjective, but I think CAD drafters have gotten worse and worse through the years. Partly because the older generation of CAD drafters had real board drafting experience. But also partly through the GUIfication of ACAD. I've seen insanely slow drafters who only use the GUI.
That's not the same. That's making the human look up data when the computer could do it. Do you disapprove of tab completion in general? All the info it gives you is available with ls.
On second thought, ls has so many options that the tab completion would look a bit like a man page. Maybe the shell should just give the option letters together with the GNU long names as a mnemonic.
I like the idea. I'd like the ability to build up 'selection sets' ala AutoCAD. Although I guess you could do it now with X:
SSET="$SSET (moves mouse over filename, doubleclicks, middleclicks)"
Also, what if you hovered the mouse over a piece of text (like a filename) and different key brought up different imagemaps? Like if I hit ctrl-A while hovering over a filename, a 3x4 grid permission bits appears centered over the filename. I can click to change them. When I move the mouse away, the grid disappears.
But please don't break copy-and-paste or the ctrl-button3 menu.
And from that page:
24. I will maintain a realistic assessment of my strengths and weaknesses. Even though this takes some of the fun out of the job, at least I will never utter the line "No, this cannot be! I AM INVINCIBLE!!!" (After that, death is usually instantaneous.)
This seems strangely relevant.
Can you say 'Internet Obfuscated Fab Contest'? "Ooh, that's a nice trigger guard for my paintball gun. I'll render it!"
10 minutes later, a rabid flesh-eating robot shaped like a paintball-gun-triggerguard emerges...
Well, much of the power and generality you're praising comes from the fact that every process has three file descriptors, STDIN, STDOUT and STDERR with standardized meanings. Now imagine if we add a fourth file descriptor to the Unix paradigm: STDINFO. A program could optionally print messages to STDINFO in a standardized format (we'd need an RFC) which could be parsed by numerous tools. For example tar might print to STDINFO "percent_complete=34". A GUI might use this to power a progress bar.
However those of us who aren't into GUI's would find lots of cool uses for this info. How cool would it be to type ps -<something> and have most of the processes show certain metrics, like how many lines of input they've processed and how many errors they've encountered? Or imagine typing "tar -xvf huge.tar 3|grep'percent_complete=5[0-9]'>&1". In other words, let me know when it's half done.
I think this would rock. And adding a few printf's to tar wouldn't be much bloat.
If there are no
If there's one
If there are multiple
I agree, but imagine if tar provided its status info to the OS through a more generalized interface, so it was stored in the process table. Some people would run a GUI that exploits this - you wouldn't. But if you're curious about how far that backgrounded tar got, you might type 'status --complete $PID' and get back '32%' or something. This would be a much cleaner solution than having tar attempt to drive a GUI directly.
Well that's cool, but is there any particular reason it needs to be graphical? Imagine a smart shell: I type 'ls -' and it shows me all the options to ls. There should be another keystroke, so that if I type 'ls -alR' it would explain what those options do, then return my command line in the same state for further editing.
But what if the program merely output escape codes which were interpreted by the terminal emulator (like xterm) to render the widgets? Cat might go from 10 lines to 11. Better yet, imagine if the API for this was generalized to 'provide info about program's current state' rather than just 'provide GUI widgets'. Imagine writing a shell pipeline to "kill all tar's that are more than 1 hr old and less than 15% done". /usr/local/gui/bin or something. Then you'd set your PATH to use/not use.
Anyhow, the makefiles could compile and install two binaries: one without the enhancements, in the normal place, and one with, in
As for windows popping up like mad, I'd rather the terminal emulator render the widgets in its own window. It could limit the number of widgets or the % of area used by them. Put the control in the terminal emulator, not in tar, cat etc.
One way to implement such things would be to write a replacement for xterm and define a new terminal type. Just as xterm has escape codes to set the foreground and background colors, the new termi nal could have additional escape codes to create or update certain display widgets. I'd rather such widgets were part of the terminal window than poppped as separate windows, which sounds somewhat uncontrollable. You'd also need a good scheme to kill the widgets if the process that requested them dies . If done this way, the gui enhancement would still work well over a 300 baud modem.
If you're using a terminal that doesn't support these capabilities, the termcap database wouldn't return any codes for them, and everything would work as it used to.
I used to use AutoCAD heavily, and I liked its interface, which was something like a Unix shell with the ability to mix mouse clicks with words, and to see the results of commands after you typed them. Imagine if you type 'ln -s
Why do you think an anonymous proxy would be any use against such a system? Alice send an http request to Bob. (Alice and Bob are hosts). Bob sends Alice the requested data. Mallet, the censor, notices that the data is 'illegal' and adds Bob's IP to the blacklist. Now Carol sends an http request to Bob. The routers drop her request. Even if it got through, the routers would drop Bob's response. So Carol proxies her request through Peter, an anonymizing proxy. Peter sends an http request to Bob. The request never makes it, because the routers are dropping all packets to Bob.
Anonymous proxies won't help at all.
Imagine that the first time a Gnutella node delivers unathorized content, the IP address of the Gnutella node is added to a nationwide blacklist. No cooperating router will handle packets from that IP address. If the node has a static IP, the node owner has a problem. His box is effectively off the internet. If the node has a dynamic IP, the ISP has a problem. One of their dynamic IP's is dead. To get it 're-activated', they'll terminate the offending account.
The treaty of Versailles was a huge mistake. By humiliating Germany, it paved the way for Hitler. That's why after WWII the US helped rebuild Germany and Japan. Anyhow, the only hope for the Internet lies in the disagreement between nations about what should be censored. Every country on this planet wants to censor something. So if 'we' - presumably the US - owned the Internet, we'd enforce our censorship without fear of circumvention. And every politician would add his 2c to the list of what should be censored.
Yes it would. It would have detracted from the fun. And why should they detract from the fun to pander to the less intelligent?
No, I don't. I think a criminal investigation should only be launched when there's actual evidence that a crime has been committed. In this case, a corpse or missing person.
It's hardly the same. 911 is for reporting emergencies. The web is for fetching information from remote servers. No guarantees are made that the information is serious or accurate.
Instead of putting a disclaimer on the web site, let's put a disclaimer in the web browsers. Dialog box: "Danger! You are entering the World Wide Web! You may be trolled or offended. Click 'Accept' to continue." I'm assuming that idiots don't use lynx.
Perfect example. It's possible (in fact common) to write a PRNG which is quite good statisticaly while being quite poor cryptographically. A large LFSR is an example. Read Schneier's
- Applied Cryptography
for more.Thanks. You said exactly what I've wanted to say to those who are underestimating this task.
But leaving aside engineering cleverness, the rigging work below the bridge deck must have taken a lot of courage. Working aloft, in the dark, in constant danger of arrest or falling is not everyone's cup of tea.
The students didn't cause traffic congestion - the CHP did. The VW was under the bridge. It had no impact, direct or indirect, on the traffic flow over the bridge. As for the rerouting of shipping lanes, I'd like to know how many vessels were actually affected. I've spent some time at Fort Point (right underneath the bridge) and never seen a single ship go by. Plenty of boats, but those aren't affected.
No. Real engineers want to accomplish their goals in the fastest, most elegant and laziest way possible. There's nothing to guarrantee that the goals an engineer happens to pursue are goals you'd approve of.
Nobody had to cut it down. There were any number of ways to skin that particular cat. I don't think we can blame the students for the (possibly ill-considered) actions of others.
You're reminding me of corporations that claim they 'lost millions' when their websites were defaced. You're taking a trivial event and making it sound like WWIII with PHB-speak: 'resources', 'investigate', 'neutralize'.
Why should the students pay for the 'emergency services'? There was no emergency, as any educated person could see. An empty car hanging from a bridge is not an emergency.
You also imply that the prank blocked traffic. It didn't. The police blocked traffic.
I don't think the students caused any traffic trouble. The CHP caused the trouble by pointlessly blocking the road. Did they think the weight of a VW bug was going to break the bridge? If you want the CHP officers sentenced to community service, I'll second that.
I've generally found text-based mail (mutt) to be much more time-efficient than GUI mail clients. I grind through a huge amount of mail each morning, and greatly benefit from the speed with which mutt moves from message to message.
However, I do miss one thing about 'rich mail' - the ability to use tables. Frequently a table expresses data best, but I'm not going to take the time to hand-build it in vi.
But if I understand correctly, toolkits compete somewhat on the basis of API. I'm passing on hearsay here, as I've never programmed for any of these toolkits. Elsewhere in this thread, someone says the Motif API is better designed and more consistent than the Gtk API. It seems like OO programmers prefer Qt to Gtk.
Meanwhile, I still don't see commercial software developers spending millions to port their Unix apps from one toolkit to another. For example, I use Meeting Maker at work. It uses Motif. To the people who make the purchasing decision, the choice of toolkit is not even on the agenda. So unless MM rewrites from scratch for some reason, I don't see them changing.
Because he's diverted the energy that should have gone into man pages towards 'info'. Because he ought to know better than to break a good and widely accepted standard. Because I greatly like and respect RMS, and this decision shows him at his worst.
You definitely have a point. Linux distributors don't seem to take responsibility for their OS the way other Unix makers do. However, isn't Red Hat still losing money? Maybe for the slim margins they make they can't afford to pay much attention to each package. I wonder if the vendors could pool their resources - split up the man pages proportional to sales or something?