Lisanna has quit [Remote host closed the connection]
infinisil has quit [Ping timeout: 240 seconds]
infinisil has joined #nixos-chat
ma27 has joined #nixos-chat
ma27 has quit [Ping timeout: 276 seconds]
MichaelRaskin has quit [Quit: MichaelRaskin]
zybell_ has quit [Ping timeout: 240 seconds]
zybell_ has joined #nixos-chat
ma27 has joined #nixos-chat
ma27 has quit [Client Quit]
ma27 has joined #nixos-chat
zybell_ has quit [Read error: Connection reset by peer]
zybell_ has joined #nixos-chat
jtojnar has joined #nixos-chat
jtojnar_ has joined #nixos-chat
jtojnar has quit [Ping timeout: 264 seconds]
jtojnar_ is now known as jtojnar
nand0p has quit [Quit: ~]
nand0p has joined #nixos-chat
shlevy has joined #nixos-chat
<shlevy>
Sonarpulse: Just stumbled across https://github.com/oilshell/oil/issues/26. "I fear bash is poorly designed to the point where almost all internal implementation details are not abstracted way." <3
<zybell_>
Fear is good. Very good. Prooving it is better. Even citing examples is better.
<shlevy>
zybell_: The thread is full of examples :)
elvishjerricco has quit [Quit: ~]
elvishjerricco has joined #nixos-chat
vdemeester` has quit [Quit: ~]
vdemeester` has joined #nixos-chat
* zybell_
looks.
<sphalerite>
shlevy: good fun, isn't it
<sphalerite>
thanks for reminding me, I havne't checked on oil in a while
<zybell_>
shlevy:there are many examples of bugs in oilsh, but not one example of 'details are not abstracted' in bash.
<simpson>
zybell_: There was at least one instance of an entirely-refactorable concrete construct in there. Don't worry about it; everybody knows that bash is trash and we're stuck with it.
<zybell_>
it was refactorable bash *script*,what means an amateur programer couldn't be bothered to read docs. But nothing to do with bash *design* itself.
<kgz>
I wonder if anyone has made a shell called trash
<kgz>
it's a good name for a shell
<ekleog>
zybell_: if you want an example of why bash design is wrong, just run `a="b c" diff $a` in bash
<ekleog>
don't know whether oil fixes this kind of issues in any way, though
<simpson>
zybell_: By 'docs' you mean the unofficial wiki, right?
<simpson>
bash is as footgunny as C++. The difference is that when you footgun in C++ you accidentally your entire process, but when you footgun in bash you accidentally your entire filesystem.
<ekleog>
bash is likely the reason why developers are afraid of spaces in their paths, and has caused at least a few rm -Rf / with that unfortunate bumblebee update
<sphalerite>
ekleog: the idea behind the project, AFAIUI, is that osh translates bash to oil, and oil is a saner language
<ekleog>
hmm, so then at first the issues would be the same, but osh would help transitioning from bash to oil? If so that sounds like a nice idea, provided hopefully oil is actually well-designed :)
<simpson>
Oil is pretty Blubby. I look forward to learning to hate it.
<ekleog>
(btw just got to correct myself, sounds like it was rm -Rf /usr for the bumblebee issue, which is a tiny bit less bad than rm -Rf /)
<ekleog>
(well, unless on nixos where it's almost a noop, but... 😇)
<shlevy>
I don't get the issue with rm -Rf /. Surely you take frequent backups and have your system configuration in source control? ;)
<sphalerite>
ekleog: well with GNU coreutils it's worse since for / you have to use --no-preserve-root and with /usr you don't
<ekleog>
yeah, I thought it was something like rm -Rf /*, but turns out no
<ekleog>
“just” rm -Rf /usr /lib/nvidia-current/xorg/xorg as a typo in the root-run install script
<gchristensen>
ooh I love shell discussions
sphalerit has joined #nixos-chat
<Sonarpulse>
shlevy: yeah
<Sonarpulse>
vaguely related to the Postel's law hell I mentioned on your RFC
jtojnar_ has joined #nixos-chat
jtojnar has quit [Ping timeout: 256 seconds]
jtojnar_ is now known as jtojnar
jtojnar has quit [Quit: jtojnar]
<zybell_>
Where is the old unix way, where install was run as user 'bin', not root, so it couldn't touch /home?
<zybell_>
And simpson: by docs I mean official docs like man bash.
<simpson>
zybell_: Oh. Those don't really teach bash very well. Check out the unofficial wiki sometime; it's great.
<zybell_>
Yeah, but using *only* those maybe has brought those misunderstandings. For instance `rm $file` vs `rm "$file"` would have made that typo ^^ harmless.
<simpson>
In general, the idea that a language isn't bad but that its users are uneducated or misunderstand or get confused, is kind of a lame idea.
<gchristensen>
agreed
<gchristensen>
there are so many things which surprise new and old users alike
<gchristensen>
an expert user of bash may be surprised to find some programs eat stdin because of course every program has the opportunity to eat stdin
<zybell_>
Its not that users are uneducated (which is true,but follows from),they don't *want* to learn. Take desu4u as example.
<gchristensen>
erm
<gchristensen>
that is even lamer
<zybell_>
And that cant be attributed to the language.
<gchristensen>
on the other hand users don't like to waste their time and IMO, many of bash's features are wasting users time
<gchristensen>
"features"
<gchristensen>
and is generally unsafe by default
<zybell_>
features wasting your time you dont have to use.
<gchristensen>
you can't avoid them with bash
<zybell_>
call bash sh or set POSIXLY_CORRECT in .profile and they are off.
<gchristensen>
posix is full of the same misfeatures that are wasting users time
<zybell_>
all documented in man page, near the beginning to boot,to waste even less time.
<zybell_>
would you care for an example?
<zybell_>
misfeature I mean
<gchristensen>
I would not, because I don't think it is important that the mistakes wasting users time is documented near the top, when they shouldn't exist in the first place
<zybell_>
nah its not the misfeature thats documented near the top, its turning off all features thats documented there.
MichaelRaskin has joined #nixos-chat
<sphalerite>
clever: any chance you've got nix running on a solaris box before? :p
taktoa has quit [Remote host closed the connection]
<sphalerite>
hm, it seems building nix for solaris will require some changes.
<ekleog>
zybell_: rm $file vs rm "$file" is an example of why bash is misdesigned, the fact that there is a way around it doesn't change the fact it's misdesigned
<ekleog>
I've been using bash for now something like 10-15 years, often scripting so looking up docs, and still sometimes forget a "" pair
<ekleog>
actually recently I've switched to mostly using python with the sh module when possible, as this makes things actually not-so-much-footgunny
<ekleog>
but some nice-designed self-contained not-XXMiB shell replacement would be nice (the python closure is way too big, and this makes me unsure oil is actually a good replacement for bash)
<zybell_>
I don't see it as misdesign. Its different syntax as the datatype of file. perl design is same $ vs @.
<ekleog>
well, it's a feature that's so easily turned into a footgun that I can only see it as misdesign
<ekleog>
if there was another char that wouldn't have this non-quoting behaviour and it was the one people used by default it'd be OK, but there isn't another char that'd implicitly quote
<zybell_>
The problem is that sh doesnt abort if a filename without space is used without quotes.
<ekleog>
well, that's yet another issue :) and then we start speaking about alternatives to find | while read line
<ekleog>
(as that breaks when a filename contains a \n) (yes I was shocked too when I learned a filename could contain a \n)
<sphalerite>
infinisil: why 4 though?
<infinisil>
sphalerite: because you have 8 disks, that makes 4 2-way mirrors
<sphalerite>
infinisil: but they have different sizes
<infinisil>
Ohh
<infinisil>
Didn't see that haha
<infinisil>
Umm.. 3, 3 and 2..
<ekleog>
sphalerite: concat sd[ab] as some bigger device and then you have 4 pairs of same-size disks? (never used zfs though :°)
<ekleog>
hmm nvm doesn't work it'd be 3 pairs and one standalone
<infinisil>
sphalerite: These are replaceable i assume?
<sphalerite>
infinisil: replaceable in what sense?
<infinisil>
Easy to replace
<infinisil>
Where are these disks?
<sphalerite>
not really, they're SCSI I think
<sphalerite>
they're in the physical machine which I have physical access to
<sphalerite>
but I don't have an easy way to actually source replacements
<sphalerite>
won't be storing any data I'm extremely attached to on them though
<infinisil>
I mean if you don't intend to replace or extend then I guess some raid would be best
<infinisil>
3 raids for the 3 sizes, such that in each size 1 disk can fail
<infinisil>
raidz1
<sphalerite>
so 3 pools?
<infinisil>
Nah, 3 vdevs
<zybell_>
So everybody is used to use that bug successfully. Find is designed to run with xargs. Why one should use read is beyond me. Dont know if `read -d ''` would implement the -z flag,but as you say it would be a workaround.
<infinisil>
sphalerite: I think it would be zpool create tank raidz1 sda sdb sdc raidz1 sdd sde sf raidz sdg shh
<ekleog>
good luck running xargs with a shell function
<samueldr>
system utilities are not a replacement for shell misfeatures
<ekleog>
and then you have to write another file for each function you want to apply the output of find
<zybell_>
xargs "$0" -xargs
<sphalerite>
infinisil: would that make the full capacity of each drive usable?
<ekleog>
and then "oh shit how do I find a file in the same directory as the current file? wasn't that some ugly hack that wasn't portable across shells?"
<zybell_>
xargs "$0" -yargs
<infinisil>
sphalerite: That would use 1 drive of each size for parity, in total about 60% efficiency if my calculations are correct
<ekleog>
zybell_: bad luck, $0 doesn't work
<infinisil>
sphalerite: All the space could be filled though (either parity or data)
<ekleog>
you can be execve("/bin/bar", ["foo"])
<ekleog>
and then as you put forward -xargs, -yargs, do we speak about argument parsing in shell? :D
<zybell_>
"$0" works as long as you dont cd. And be run from shell command.
<ekleog>
doesn't if your shell script is called with execve("/bin/bar", ["foo"])
<ekleog>
because "foo" is not actually in the path or whatever
<zybell_>
no parsing only name of function
<ekleog>
I guess there are some less convoluted ways of triggering this issue
<ekleog>
(likely involving mixing different shells that wouldn't use the same environment variable for path selection, like maybe python calling a shell script)
<zybell_>
They are convoluted.There is even a multiline prolog that enables cd. See https://pastebin.com/BzwzuF6G the case at the start.
<ekleog>
ok so I'm reading “sudo” at line 12 and stopped reading altogether
<infinisil>
sphalerite: Oh and maybe you could ask #zfsonlinux for a better zpool layout, they probably know more than me :)
<sphalerite>
they asked me difficult questions like what I'd be using it for :p
<infinisil>
Heh
<ekleog>
anyway, I'm pretty sure that there are some programs that aren't using PATH for their lookups (randomly, in some plugin-able program that would look for executable files in a directory without ever cd'ing in it)
<zybell_>
ekelog:I meant the case that has its esac before that line
<ekleog>
there's no esac before l12?
<ekleog>
anyway, you could do with ${BASH_SOURCE[0]} IIRC, if you really want to
<ekleog>
but then you're just piling up hacks over hacks to get something really simple done: figure out another file in the same directory as the current one
<ekleog>
something nix does with the simple ./foo.nix
<infinisil>
sphalerite: Or you could have 2 pools: 1 which contains 2 raidz2 of the 6 smaller disks. Another one with raidz1 for the 2 bigger disks
<ekleog>
not forgetting the layers of quoting to get "$(dirname "${BASH_SOURCE[0]}")" right
<infinisil>
Then you'd have a pool of about 200GB which will withstand a lot of disks failing. And the second one with 280GB which would resist only 1 disk failing
<infinisil>
Or you could just throw every disk itself in the pool, which will give you 1.17TB, but any disk failing and you lose everything
<sphalerite>
nah I don't trust these not to fail x)
<infinisil>
sphalerite: Well have you decided what to do?
* ekleog
would likely do raid5(sd[abc]) -> md0, raid5(sd[def]) -> md1, raid-mirror(sd[gh]) -> md2, and then lvm over md[012], and then btrfs over this, but that's not zfs :°
<zybell_>
my bad that sudo was once later, but for security it had to be moved into the case. Normally there would be a noop (:) instead and the script would continue after esac in line 14. The if would be missing too.
<ekleog>
anyway, having a prologue to copy-paste is already wrong in my mind :)
<ekleog>
it's another layer of hacks that couldn't be taken care of in the base case
<infinisil>
ekleog: Hehe, zfs could do all of that itself
<ekleog>
also, did you have a look at l29 of your paste? :D
<ekleog>
(ok, '"'"' is pretty standard, but I've seen a huge number of people surprised by it, and it's still a PITA to read)
<ekleog>
infinisil: yeah, guess so, I just don't want to learn zfs because it's such of a tie-in when all your things are running over zfs, I could independently replace any piece of this setup :p
<ekleog>
(well, not that there are a huge number of alternatives, but... :°)
<zybell_>
If you want a func in nix you import the appropriate file, if you need to do something in script, you make the right incantations.
<infinisil>
ekleog: Ah yes and what you said is actually pretty much what I suggested sphalerite at first
<ekleog>
(also, lvm is nice for being able to give you a block device when you want to just run qemu over something not-too-slow, I don't know if zfs can?)
<infinisil>
ekleog: Yup
<ekleog>
(oh, and I'd have a layer of dm-crypt somewhere in the blurb, but… :°)
<infinisil>
Well zfs has native encryption on master and it will be in the next update :)
<ekleog>
zybell_: f you're trying to tell me bash is turing-complete then thanks :D but with this reasoning brainfuck is a well-designed language (and actually I'm more or less thinking brainfuck is better-designed than bash, at least it does what you expect it to do, even though it isn't much)
<infinisil>
And I really like zfs' command line interface, I've played around with lvm at some point and that wasn't very nice imo
<ekleog>
infinisil: oh great! that said I don't think I'll switch to zfs anyway (unless it can bring file-level encryption, maybe? encfs and [forgot the other's name] are cryptographically speaking broken, iirc), as it's still turning a conceptually-micro-kernel into a conceptually-monolithic-kernel (even though I know it's the same kernel underlying the two)
<infinisil>
Hmm.. file level encryption would be nice
<infinisil>
I'll see if there's an issue for it
<ekleog>
lvm isn't bad once you've got your head around pvs, vgs and lvs (that said I haven't tried to do dm-cache with lvm yet, and thin volumes have a not-really-obvious display)
<infinisil>
What's dm-cache?
<infinisil>
(There is no issue for file-level encryption for zfs)
<ekleog>
using a block device (usually ssd) as cache for another block device (usually raid/hdd)
<infinisil>
Ah I see (zfs can do that too)
<ekleog>
(yeah I've heard zfs as a behemoth that does basically all the block-device and filesystem-level stuff in a single huge thing, hence my criticism of monolithicism :p)
<ekleog>
(that said some day I should really try it out)
<infinisil>
((Not sure why you're always using parens))
<infinisil>
I mean it's all disk management, it makes sense for a single tool to do it all imo
<ekleog>
((dunno, likely because I feel like it's side-tracking the discussion?))
<zybell_>
ekelog: FYI That script calls user provided scripts from system level in a secure manner and even handles the case of newline in filenames (and all other chars)
<clever>
sphalerite: my sparc machine died a few years before i discovered nix
<clever>
sphalerite: but i still have 2 of them
<ekleog>
I guess in the linux kernel land it does make sense for a single tool to do all the disk management, I just feel like it's more prone to failure than having each layer only responsible of doing its job, and having recovery tools working in case any of the layers failed
<infinisil>
ekleog: I can also imagine zfs being a lot faster than these levels of mdadm/lvm/luks
<ekleog>
but hey, that'd be microkernel-thinking anyway
<clever>
sphalerite: though i was also running gentoo on it, not solaris
<clever>
infinisil: ive used lvm heavily before, to the point that i wrote my own lvm defrag tool
<clever>
the only thing lvm has that zfs lacks is shrinking support
<infinisil>
clever: I think there was some issue for shrinking though, hold on
<clever>
infinisil: hmmm, maybe 2 sets of raidz1, and a mirror for the last set
<ekleog>
must say I've never tried to benchmark :)
<clever>
so you can handle loosing any single disk
<clever>
that can be done in a single pool if you wish
<infinisil>
clever: Isn't a mirror for 2 the same as raidz1 for 2?
<clever>
infinisil: the first 3 drives are all the same size, so thats 3 68gig disks in a raidz1
<clever>
so it will stripe between 2, with a 3rd for parity
<infinisil>
Yea
<clever>
so you get 68*2gig of storage on that first set
<zybell_>
And opening a file beside the script: A possible approach:`mkdir -p "$0".;exec 3<"$0"./..;rmdir "$0".` And then open /proc/self/fd/3/filename
<ekleog>
zybell_: honestly I'm not really interested in convincing you bash is wrong, I'm content with having shown you actual facts about the misdesign of bash, regardless of whether you acknowledge them or not :) also, the mere fact this script exists and is so complex when it should have been like `#!/bin/ideal_shell\nsudo $SELF` is wrong to me
<infinisil>
clever: Yea, I also suggested him 2 raidz1 for the first 6
<infinisil>
clever: But isn't a 2-way mirror the same as raidz1 with 2?
<clever>
infinisil: the mirror config lets you add more disks later, i turned my 2 sata SSD mirror into a 3-way mirror by adding an nvme
<clever>
infinisil: but raidz* cant do that, you can only replace disks, not add/remove
<zybell_>
That would never work in ideal_shell. read about infinite recursion.
<infinisil>
clever: Hmm.. alright, but is there a difference between the two on the bit-to-bit level?
<infinisil>
Do they store stuff differently on the 2 disks?
ma27 has quit [Ping timeout: 245 seconds]
<zybell_>
Even with ideal_shell you could shoot yourself into the foot.
<infinisil>
Gonna ask #zfsonlinux too
<ekleog>
zybell_: I think you got what I meant, I don't even care enough to try to understand your 30-lines-of-spaghetti script to get what it does exactly, actually ;)
<ekleog>
(and shooting myself in the foot by infinite recursion isn't exactly the same as shooting myself into the foot with opening a privilege escalation or breaking my entire system, also)
<zybell_>
And I hope you get what I mean:Even with an ideally designed language you have infinitely many possibilities to shoot yourself in the foot, as long as its turing complete. Because thats the meaning of turing complete.
<ekleog>
I do, but the thing is what do normal people expect and what do normal don't expect, and that's what differs between well-designed languages and ill-designed languages :)
<ekleog>
if I decide in my language to swap + and -, you'll agree with me it's ill-designed, even though it's still turing-complete, I think :)
<ekleog>
though you “just have to know the language” to practice it correctly
<ekleog>
it's the same for bash, normal people expect `diff $a $b` to diff files that are in $a and $b, not to start doing nonsense when there's a file named '--help' and one 'foo bar'
<zybell_>
Privilege eescalation: that script alone can do nothing in this direction. There must be the equivalent of setuid, by placing sth in sudoers. And I didnt want you to understand it,I wanted to show you the case. Although I should have looked. On the other hand it *is* an example that setuid-like programming in bash is possible, although not easily understandable.
<ekleog>
well, if you give me this script with the setuid bit, I'm root on your system (actually you can't setuid a script, but you got what I meant)
<ekleog>
just because of this `exec "$0" "$@"`, and the afore-mentioned issue of execve("foo", ["bar"])
<ekleog>
(don't think that'd work through sudo, though)
<zybell_>
I for example see diff $a $b as syntax error, although I know that bash is unable to catch it. So I dont *expect* a diff coming out of that. The possibility that it works I see too.
<ekleog>
*you, who know bash* don't expect a diff coming out of that
<ekleog>
can you define what a well-designed language is wrt. an ill-designed one?
<zybell_>
Where rules have maximal possible locality, you have a better designed language, if rules rule over longer distances, the design is worse.
<ekleog>
so you're saying the existence of variables make a language ill-designed?
<ekleog>
and what do you think about set -x, etc.?
<clever>
zybell_: what if i create ~/.local/bin/sudo, and it prints a password prompt?
<ekleog>
(I'm finally noticing we just don't agree on what makes a language well- or ill-designed, so that may be the direction to go, though I don't agree with your definition for the simple reason of the existence of variables thaat would be classified as ill-designed per your definition)
<ekleog>
if you want, my definition of “well-designed” is “makes errors unlikely for every developer, be them beginner or experienced”
<zybell_>
set -x is a debuggig tool using an extra filedescriptor, in set -x the *same* syntax applies, maximal locality despite its far reaching effect. *It doesnt bend the rules*!
<ekleog>
what are the “rules” to you? is that just the syntax?
<ekleog>
or say `set -a`, then, about locality?
<zybell_>
Mostly. The semantic does play a role. If its sub/superclass like ok. Unrelated changes:ill
<ekleog>
(which changes the syntax by making `export` irrelevant) (must confess I had to have a look at man bash to remember all the set *)
<ekleog>
Anyway, if you really assert that your only definition of well-designed-ness is locality, then I can do nothing but finally resign myself to the fact you're just trolling. Well, I had guessed it (with some PM help), but a troll is a nice thing, once in a while, thanks :)
<zybell_>
Thank you for looking it up. As long as programs expect uppercase exports (as is the rule from the days where set -a was default) and my vars are lowercase, which rule is from those days also, I have to document which vars I import (not set myself before expand) and observe when I call such a script.
ma27 has joined #nixos-chat
<zybell_>
I do not troll. But making unlikely that ... is so subjective that I tried to come up with sth objective that amounts to the same result.
<ekleog>
(and, apart from a message from you that states well-designed-ness is not only locality, my last message in this discussion will be that brainfuck has maximal locality by language design, thus is better design than bash as per your definition, given `set -a` and the fact brainfuck has no such locality-escaping rule :p -- actually befunge may be an even better example, as it's by definition the most local
<ekleog>
possible turing-complete language afaiu)
<zybell_>
A C-Compiler written in brainfuck is the ideal tool for bootstrappable.org! So there;-) There exists a brainfuck-compiler statically linked about 1K in size.
<zybell_>
clever: That script runs (NOPASSWD) so your sudo will alert me.
<ekleog>
MichaelRaskin: ^ wasn't this one of those you recommended? :D
<gchristensen>
I've been doing a lot of stuff lately where git's view of changes is very broken and I can't trust it to merge or rebase properly
Sonarpulse has quit [Quit: Leaving]
<ekleog>
I'd have said fossil looks nice for bts and wiki reasons (github bts&wiki have the issue of being relatively tie-in), merge and rebase appear to be basically the same as git?
<ekleog>
(pijul (or darcs) could be a way forward for those issues)
<gchristensen>
I don't know, maybe fossil isn't better at it, just makes me think about looking at other tools :)
<gchristensen>
I've tried pijul but struggle with its name...
<simpson>
I like Fossil, but unfortunately customizing it requires a lot of work and knowing like three different languages at once.
<ekleog>
what's the issue with the name of pijul? (and I'd be curious what your feedback would be, wanted to test but never found a project to test on, needs to be something that I'm doing that'd be single-user-enough to not warrant being nice to other users :°)
<gchristensen>
"The original authors of Pijul pronounce the name like "pee-hool" in english, but won't be offended if you pronounce it differently."
<sphalerite>
simpson: programming languages or human lanaugages?
<ekleog>
oh that's a weird pronunciation
<gchristensen>
it is ...
<gchristensen>
one problem with projects the size of nixpkgs, is having a uniuely large repo
<gchristensen>
so having the linux kernel as a "neighbor" is useful
<ekleog>
well, linux is still 2G while nixpkgs is still at a lowly 1.2G (and firefox is 4G on mercurial if memory serves) :p but you mean pijul was too slow to run on nixpkgs? :/
<gchristensen>
it was, yeah
<gchristensen>
but that was a bit ago, maybe they've improved
<gchristensen>
iirc their authors were interested at the prospect of seeing how it performed
<gchristensen>
(pijul's Nest is all run by nixos)
<ekleog>
oh didn't know, that's fun :D don't see any module for pijul's nest unfortunately
<simpson>
'TH1 began as a minimalist re-implementation of the Tcl scripting language.'
<simpson>
Basically, every change I've made to any of my Fossil repos has been on the level of when I was 12 and copy-and-pasting massive amounts of JS in order to write like a twenty-liner.
<sphalerit>
How convenient
<gchristensen>
sqlite-sql, htmt, css, js all reasonable. th1: :%
<simpson>
Quite.
<ekleog>
well, there was a need for a templating language, so why not reinvent the wheel? :D
<simpson>
The problem is that you'll often have a single textbox with SQL, HTML, and TH1.
<gchristensen>
might as well use PHP, ekleog
<simpson>
But yeah, in case you thought this was *just* a templating language, oho no, nope, there's a link on the admin panel to run raw SQL, and another link right below it to run raw TH1.
<gchristensen>
ouch
<simpson>
Yeah, I wanna love Fossil, but it's prickly. Still, it *could* be used to build whatever you want.
<gchristensen>
that is cool
<gchristensen>
sigh ... I've been trying to setup a WISP in my county and it is such a nightmare with all the hills
<simpson>
Hey, if it were easy, somebody else would have already done it, right?
<simpson>
I want to think that Matador-flavored WISP would be easy, but it'd be a massive pivot and it'd take forever to pay off and actually I might not be allowed to do it within the City of Portland~
<gchristensen>
no, not many people here are skilled like that