for the most recent versions of my.zshrc and.zshenv.
Re:First "zsh rules" post!
on
Bash 3.0 Released
·
· Score: 4, Informative
Bigs ones for me:
A sane auto-completion system. That is, "cvs <tab>" gives a list of all of the commands that cvs understands. "cvs -<tab>" (same as above but tabbing after typing "-") gives a list of all of the options that cvs understands. These are good things. Now, in fairness, bash also has a command completion library. Unfortunately, it's implemented as a huge set of Bash functions. In zsh, "set|wc" returns 179 lines. In bash, "set|wc" returns 3,961 lines. The net effect is that zsh's system is noticeably faster and less polluting to the local environment.
Modules. Wrappers for TCP connections, a built-in cron thingy, and PCRE are all loadable modules to do tricky things easily.
Lots of pre-defined things. Load the "colors" and "zsh/terminfo" modules and you get defined associative arrays like $fg, which emits terminal-appropriate escape codes to set the foreground color of printed text. The command "echo ${fg[red]}red text${fg[default]}normal text" prints "red text" in red, and "normal text" in your default color.
Bash is a good shell, and I have nothing bad to say about it. However, zsh seems to have been designed from the ground up by power users and for power users. I absolutely love it and everyone that I've given a example config file to (to get them running with little hassle) has permanently switched.
First "zsh rules" post!
on
Bash 3.0 Released
·
· Score: 5, Interesting
Bash was my first shell and I used it exclusively for years. One day, I'd read enough about zsh to force myself to give it a try. Oh how I loved thee, bash, but I won't be going back.
Yep, that's about right. In fact, that's how I run a newsserver and a Freenet node inside their own virtual environments.
One non-obvious point is that the chroot directory need not be a full (or even partial) FreeBSD installation. At one time I managed to do a complete Gentoo install using FreeBSD's Linux emulation and pointed the "jail" command at that directory. Voila - a full simulated Linux environment. Other than the inability to load Linux kernel modules, it looked and acted pretty much exactly like any typical bare-metal setup.
Plug: for easy management, install my JailAdmin port. Loads of secure environment goodness!
I admit that I was the one talking about keeping the sigs private or destroying them after verification. I've been "thinking out loud" for most of this conversation, so some of my ideas haven't sounded as good to me when I've re-read them.:)
In that vein, is there any real reason not to trust Wikipedia in this situation? Anything that involves any software other than a web browser is going to put off 95% of visitors, and requiring something as complex as PGP/GPG is going to weed out 99% of those left. I think that a nice, strong crypto system would get used by you, me, and about 100 other people total. That may be enough to make it interesting, but not necessarily enough to make it worth the work.
1. That would seem like a good idea. You could check a representation of an editor's endorsements before deciding to trust them.
2. Not that this is a good solution (I'm typing as I think), but: what about having a separate "Wikipedia keyring" where the signatures on those keys correspond to a trust in that person's endorsements, and not a trust in the identity of their key? To a first approximation it seems like the models overlap quite nicely.
3. How would that work?
4. Hmm. We are supposed to be adopting the "semantic web" any day now, right?:) I suppose Wikipedia could create "<atom>" tags that representing single pieces of knowledge. On the other hand, read the discussion page behind George W. Bush's entry (too tired/lazy to link) in reference to the "Popularity" or "Public Perception" sections. There's quite a bit of debate about how to separate facts and opinion, so this may be easier in principle than in real life.
You know, it occurs to me that if you don't make the signatures available to the public, then there's no point in bothering with them at all. I mean, if you're asking people to trust Wikipedia anyway, then why not do away with the sigs altogether and just put a "Do you endorse this article? Yes/No" form on the page that the editors see?
Nah, I don't like that. Instead, I guess I'd advocate going back to the original idea of storing the sigs and making them downloadable by visitors, and make it possible for anyone to download the raw source of a page so that they can verify the sigs on their own. This would tie back in to the global PGP/GPG PKI by allowing real-world webs of trust to be used. For example, you could verify that the guy claiming to be your Physics professor on Wikipedia really is the one that you swapped keys with after class, and wouldn't have to trust Wikipedia whatsoever. A nice side effect is that it might be another incentive for regular folks (read: intelligent people who don't happen to be cipherpunks) to learn about PGP.
On the other hand, notice that you and I are the only people in this thread? Apparently we're more interested in the idea than anyone else.:)
Showing the trusted information by default seems sensible, but I suspect some people will want a "bleeding edge mode" that reverses the logic
Agreed. Once the infrastructure was in place, I'm sure that it would be simple to provide a list of "certainty options" ("trusted", "minor edits only", "unfiltered") for each visitor.
I like your idea of defining a "release" as a set of articles signed by a core committee of members who are trusted by default.
You know, this all seems imminently do-able. I would leave the actual signature validation up to Wikipedia itself rather than requiring visitors to do the authentication themselves. I imagine it would work something like:
Editor #2453 views a page that he wants to sign.
He clicks a link to get the raw source of the page as a text/plain file.
He signs that page with GPG and posts the ASCII signature to a web form.
Wikipedia verifies the signature and sets the "Editor #2453 signed this" bit on that page and discards the signature (or archives it for catastrophic database recovery purposes).
See any major flaws in that? I'm not sure that allowing visitors to authenticate signatures would be useful, but I could be wrong.
Academia also has its "religions" that come and go and shut out opposing views. Microkernel people spent years being nearly as good as existing technology [...]
...says one of the major contributors to a very popular monolithic kernel. The irony in those two statements is a work of art.:)
In other news, John Kerry admitted that George Bush was almost intelligent as a Democrat, and Bill O'Reilly conceded that Michael Moore is nearly rational.
In fairness, I did say "by signing a revision with their public key" at the start of my post.
Perhaps the user interface could allow visitors to select between a CVS-like "head" branch (the latest revision of each article) or "stable" branch (the latest revision vetted by a trusted editor). The latter could include a message at the bottom like "This article also has 5 untrusted revisions; click here to see them" to make users aware of new data while still showing only trusted information by default.
At first glance, it seems to me that Wikipedia would benefit from a public key system and reputation service. Allow editors to endorse articles by signing a revision with their public key, and allow visitors to establish a trust level for each editor whose signatures they encounter.
If J. Random Hacker endorsed the "Cryptography" and "PKI" articles, and I agree with him that those articles are accurate, then I would be likely to trust his endorsement of "Elliptical Curves" (which I know little about). Similarly, if Pete Cruft endorsed "Linux Are Teh R0ck0rz", then his opinion on "Critiquing SHA-1" may not hold much weight with me.
The same could be done on a lesser trust level without PKI by allowing visitors to "vote" on the accuracy of articles and using that to generate trust scores on other articles based on the editors.
How 'bout it, Jimmy? Is a reputation server viable for Wikipedia? It seems like that would alleviate a lot of the concerns people are expressing about the reliability of your information.
Umm, no. A receipt that looked like "John Smith voted for Bush, Bush, and Smitty" would obviously be a stupid thing to have.
However, a receipt that was an encoding of the vote record encrypted with the voting machine's secret key and protected by the voter's PIN, and that by law could only be decrypted in a special booth where only the voter was allowed entrance, might not be so unreasonable. Who said that the receipts needed to be human-readable?
I reached the exact same conclusion when I was deciding between Sony Wega 27" TVs. I bought the midrange model that was identical to the high end version, except that the speakers are the cheapest possible. Step one when I got it home was to disable the internal speakers altogether in favor of my surround system. I saved about $200 by not buying the audio upgrade that I would very literally never, ever hear.
I had the exact same experience with my Samsung 19" monitor - except that the returns guy actually had the intelligence and freedom to accept the manufacturing date from the label instead of my long-gone receipt. My model was apparently discontinued, so the cross-shipped replacement turned out to be a much better 900NF (flat screen).
I've bought Samsung whenever humanly possible since that day. They bought my loyalty and a lot of good PR to my friends, family, and the Slashdot crowd.
It's even easier than that. Mercury's axis of rotation is perpendicular to its orbit, so you could build your tracks very near one of the poles so that the sun is just barely obscured by the polar region itself.
For example, if Mercury's axis were exactly perpendicular, and you wanted to keep stay at least one mile below the horizon, and you round Mercury's radius to 1500 miles, then your track would only have to be about 55 miles away from a pole for a total length of about 345 miles. That's substantially shorter than the 9500 mile equatorial track you'd otherwise have to build, and since the angle of incidence would be much shallower your track wouldn't get nearly as hot during the day.
Also, since Mercury's day is about 59 Earth days long, a base on a near-polar track would only have to travel about.25 miles per hour. Contrast that with the more spritely 6.7 miles per hour of equatorial speed you'd need to maintain. If the base-moving motor were to break down, a near-polar astronaut could easily manage that pace on foot during an emergency evacuation.
You mean that we're flying through this "space" stuff at Mach 87.5? That's crazy-talk, man! If you're so smart, where's the sonic boom? And what about the poor turtles?
You kids and your "physics". Bah. When I was your age, we'd glide through the ether, and we liked it that way!
It did? The only reference turned up by a quick Google was the dismissal of Wal-Mart's application for an injunction against Wool-Mart. It seems like logic did indeed prevail here, unless you have other references to prove otherwise.
That wouldn't work for us. We're using a Zope server, and the queries that take ages to run are isolated in their own objects. The page that displays the results has no knowledge of the internals of the query objects, other than that they return some interesting attributes.
I hate them, too. What I hate even more is that MSIE randomly chooses to ignore the Refresh: headers that we were hoping to use instead, meaning that we had to switch to JavaScript redirects so that legacy browsers would be able to use our site (which is a limited-access system for a short list of customers who need to interact with our database).
Basically, we got to choose between using not using JavaScript or supporting MSIE, but not both. I campaigned for the former; my boss picked the latter and he and his paycheck-writing skills won the discussion.
For the sake of customers like yourself, I added a clickable link that's encased in <noscript> tags to the new page. The whole reason that we have an intermediate page is that the destination page takes about 90 seconds to generate, and we wanted customers to have "instant" feedback that they had successfully clicked the link. We didn't want them to sit there click-click-clicking all afternoon as query after query queued up on the server and the application ground to an agonized halt.
If we could get all of our customers to upgrade to a standards-compliant browser then my life would be much easier and I could use the right tools, not just the ones that happen to work. Still, I've at least managed to keep the entire site validateable as XMHTL 1.0 STRICT (plus validated CSS), so things could be worse.
I remember developing one application in XHTML, only to find that it has no support for the javascript OnLoad page event which completely broke what I was trying to do.
If that's what stopped you, then you weren't ready to be writing JavaScript anyway. I wrote this today:
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd "> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
....
<script language="JavaScript" type="text/javascript"> function primeRedirect() { window.location.replace( some long formula to calculate a redirect ); status = 'Now loading the page you requested...' }
window.onload = primeRedirect; </script>
In other words, I used onload in an XHTML 1.0 STRICT document, and the results validated and worked correctly in IE 5.5, IE 6.0, Konqueror, and Mozilla. That's good enough for my purposes.
You are exactly right: if they find a compromised machine on myisp.net, then they can emulate email from mydomain.net. Note that this is vastly superior to the current situation where any machine on the Internet can send email as mike@mydomain.net, not just you and a compromised machine at your ISP. In fact, if someone is successfully forging you address, then you now have a very shortly list of possible culprits to check when compared to the list of Internet-accessible hosts.
We've only been broadcasting RF for about 100 years. Another possibility is that there are so many pre-communicative civilizations that advanced races simply aren't interested in Yet Another Mute Species and there aren't any alien RF detectors in a 100-light-year sphere of us to know that we've figured out how to make baby speech.
Similarly, perhaps said races have been checking up on us ever 1,000 years or so. When they last visited in the 1400s, we were busy trying not to be killed by our own microbes, we couldn't comprehend electromagnetism, and couldn't even leave the surface of our own planet without a physical structure to support us. Maybe we'll show more promise next time around, assuming that we haven't managed to exterminate ourselves in the mean time.
Slashdot Mirror
- http://subwiki.honeypot.net/cgi-bin/view/Computin
g /DotZshRc
- http://subwiki.honeypot.net/cgi-bin/view/Computin
g /DotZshEnv
for the most recent versions of myBash is a good shell, and I have nothing bad to say about it. However, zsh seems to have been designed from the ground up by power users and for power users. I absolutely love it and everyone that I've given a example config file to (to get them running with little hassle) has permanently switched.
Bash was my first shell and I used it exclusively for years. One day, I'd read enough about zsh to force myself to give it a try. Oh how I loved thee, bash, but I won't be going back.
One non-obvious point is that the chroot directory need not be a full (or even partial) FreeBSD installation. At one time I managed to do a complete Gentoo install using FreeBSD's Linux emulation and pointed the "jail" command at that directory. Voila - a full simulated Linux environment. Other than the inability to load Linux kernel modules, it looked and acted pretty much exactly like any typical bare-metal setup.
Plug: for easy management, install my JailAdmin port. Loads of secure environment goodness!
In that vein, is there any real reason not to trust Wikipedia in this situation? Anything that involves any software other than a web browser is going to put off 95% of visitors, and requiring something as complex as PGP/GPG is going to weed out 99% of those left. I think that a nice, strong crypto system would get used by you, me, and about 100 other people total. That may be enough to make it interesting, but not necessarily enough to make it worth the work.
2. Not that this is a good solution (I'm typing as I think), but: what about having a separate "Wikipedia keyring" where the signatures on those keys correspond to a trust in that person's endorsements, and not a trust in the identity of their key? To a first approximation it seems like the models overlap quite nicely.
3. How would that work?
4. Hmm. We are supposed to be adopting the "semantic web" any day now, right? :) I suppose Wikipedia could create "<atom>" tags that representing single pieces of knowledge. On the other hand, read the discussion page behind George W. Bush's entry (too tired/lazy to link) in reference to the "Popularity" or "Public Perception" sections. There's quite a bit of debate about how to separate facts and opinion, so this may be easier in principle than in real life.
Nah, I don't like that. Instead, I guess I'd advocate going back to the original idea of storing the sigs and making them downloadable by visitors, and make it possible for anyone to download the raw source of a page so that they can verify the sigs on their own. This would tie back in to the global PGP/GPG PKI by allowing real-world webs of trust to be used. For example, you could verify that the guy claiming to be your Physics professor on Wikipedia really is the one that you swapped keys with after class, and wouldn't have to trust Wikipedia whatsoever. A nice side effect is that it might be another incentive for regular folks (read: intelligent people who don't happen to be cipherpunks) to learn about PGP.
On the other hand, notice that you and I are the only people in this thread? Apparently we're more interested in the idea than anyone else. :)
Agreed. Once the infrastructure was in place, I'm sure that it would be simple to provide a list of "certainty options" ("trusted", "minor edits only", "unfiltered") for each visitor.
I like your idea of defining a "release" as a set of articles signed by a core committee of members who are trusted by default.
You know, this all seems imminently do-able. I would leave the actual signature validation up to Wikipedia itself rather than requiring visitors to do the authentication themselves. I imagine it would work something like:
See any major flaws in that? I'm not sure that allowing visitors to authenticate signatures would be useful, but I could be wrong.
...says one of the major contributors to a very popular monolithic kernel. The irony in those two statements is a work of art. :)
In other news, John Kerry admitted that George Bush was almost intelligent as a Democrat, and Bill O'Reilly conceded that Michael Moore is nearly rational.
Perhaps the user interface could allow visitors to select between a CVS-like "head" branch (the latest revision of each article) or "stable" branch (the latest revision vetted by a trusted editor). The latter could include a message at the bottom like "This article also has 5 untrusted revisions; click here to see them" to make users aware of new data while still showing only trusted information by default.
If J. Random Hacker endorsed the "Cryptography" and "PKI" articles, and I agree with him that those articles are accurate, then I would be likely to trust his endorsement of "Elliptical Curves" (which I know little about). Similarly, if Pete Cruft endorsed "Linux Are Teh R0ck0rz", then his opinion on "Critiquing SHA-1" may not hold much weight with me.
The same could be done on a lesser trust level without PKI by allowing visitors to "vote" on the accuracy of articles and using that to generate trust scores on other articles based on the editors.
How 'bout it, Jimmy? Is a reputation server viable for Wikipedia? It seems like that would alleviate a lot of the concerns people are expressing about the reliability of your information.
However, a receipt that was an encoding of the vote record encrypted with the voting machine's secret key and protected by the voter's PIN, and that by law could only be decrypted in a special booth where only the voter was allowed entrance, might not be so unreasonable. Who said that the receipts needed to be human-readable?
There aren't that many people in Canada, let alone Alaska. Now we know you're lying.
I reached the exact same conclusion when I was deciding between Sony Wega 27" TVs. I bought the midrange model that was identical to the high end version, except that the speakers are the cheapest possible. Step one when I got it home was to disable the internal speakers altogether in favor of my surround system. I saved about $200 by not buying the audio upgrade that I would very literally never, ever hear.
I've bought Samsung whenever humanly possible since that day. They bought my loyalty and a lot of good PR to my friends, family, and the Slashdot crowd.
For example, if Mercury's axis were exactly perpendicular, and you wanted to keep stay at least one mile below the horizon, and you round Mercury's radius to 1500 miles, then your track would only have to be about 55 miles away from a pole for a total length of about 345 miles. That's substantially shorter than the 9500 mile equatorial track you'd otherwise have to build, and since the angle of incidence would be much shallower your track wouldn't get nearly as hot during the day.
Also, since Mercury's day is about 59 Earth days long, a base on a near-polar track would only have to travel about .25 miles per hour. Contrast that with the more spritely 6.7 miles per hour of equatorial speed you'd need to maintain. If the base-moving motor were to break down, a near-polar astronaut could easily manage that pace on foot during an emergency evacuation.
Oh, and don't forget about the quarter-inch layer of Arctic Silver smeared over the whole thing "+0 h31p 1+ c0ndukt0r h3a+".
You mean that we're flying through this "space" stuff at Mach 87.5? That's crazy-talk, man! If you're so smart, where's the sonic boom? And what about the poor turtles?
You kids and your "physics". Bah. When I was your age, we'd glide through the ether, and we liked it that way!
It did? The only reference turned up by a quick Google was the dismissal of Wal-Mart's application for an injunction against Wool-Mart. It seems like logic did indeed prevail here, unless you have other references to prove otherwise.
Bummer.
Hello, Ellen.
That wouldn't work for us. We're using a Zope server, and the queries that take ages to run are isolated in their own objects. The page that displays the results has no knowledge of the internals of the query objects, other than that they return some interesting attributes.
Basically, we got to choose between using not using JavaScript or supporting MSIE, but not both. I campaigned for the former; my boss picked the latter and he and his paycheck-writing skills won the discussion.
For the sake of customers like yourself, I added a clickable link that's encased in <noscript> tags to the new page. The whole reason that we have an intermediate page is that the destination page takes about 90 seconds to generate, and we wanted customers to have "instant" feedback that they had successfully clicked the link. We didn't want them to sit there click-click-clicking all afternoon as query after query queued up on the server and the application ground to an agonized halt.
If we could get all of our customers to upgrade to a standards-compliant browser then my life would be much easier and I could use the right tools, not just the ones that happen to work. Still, I've at least managed to keep the entire site validateable as XMHTL 1.0 STRICT (plus validated CSS), so things could be worse.
If that's what stopped you, then you weren't ready to be writing JavaScript anyway. I wrote this today:
In other words, I used onload in an XHTML 1.0 STRICT document, and the results validated and worked correctly in IE 5.5, IE 6.0, Konqueror, and Mozilla. That's good enough for my purposes.
You are exactly right: if they find a compromised machine on myisp.net, then they can emulate email from mydomain.net. Note that this is vastly superior to the current situation where any machine on the Internet can send email as mike@mydomain.net, not just you and a compromised machine at your ISP. In fact, if someone is successfully forging you address, then you now have a very shortly list of possible culprits to check when compared to the list of Internet-accessible hosts.
Similarly, perhaps said races have been checking up on us ever 1,000 years or so. When they last visited in the 1400s, we were busy trying not to be killed by our own microbes, we couldn't comprehend electromagnetism, and couldn't even leave the surface of our own planet without a physical structure to support us. Maybe we'll show more promise next time around, assuming that we haven't managed to exterminate ourselves in the mean time.