On Fri, Mar 23, 2012 at 7:35 PM, nchurch <nchubr...@gmail.com> wrote: > I like BernardH's idea of doing it anonymously; if nobody from Core > minds, we could set up an anonymous survey to see how much interest > there is. > > cej38, your suggestions are very sound----personally, I would love to > see curated, distilled APIs for common things a Clojure programmer > needs to do from Java or JavaScript, not just I/O.
I'd suggest the I/O library for ClojureJVM be a moderately-thick wrapper around java.io, java.nio, and java.net, incorporating the existing clojure.java.io things and with-open of course. Then implement it on ClojureCLR and ClojureScript (and any others?) to present the same API to users, while doing whatever is necessary under the hood. This *should* work reasonably well, since java.io is already, out of necessity, a common-denominator cross-platform I/O abstraction. > In the long term, offering bounties for specific things might be a way > to spur fast progress of needed things, but I feel that should only be > tried after basic community funding works. An alternative would be to go outside clojure.core and set up a kind of "Kickstarter for programmers" where people can propose and pledge money to various software developments in general, and those who code and release (with an open license) something that fits the bill get to collect the bounty. (There'd be some interesting dynamics. For instance, someone who can code feature X for Clojure, Debian, or whatever might be tempted to code it but hold off on releasing it until the bounty accumulates more pledges, but that risks being scooped by someone else who started coding later but isn't as greedy. Also, pledges would presumably be expiring, the money returned to the donor from escrow N weeks after being pledged if the program/feature isn't released by then.) Established FOSS development teams like clojure.core could also claim the pot for something they did themselves. Of course, for the requirements for a new feature for an existing FOSS program to be met would require that its devteam accept the patch and release a new version (a public beta, at minimum) with the patch, in most cases; I suppose those who proposed the bounty can decide in advance whether to accept a fork or only a new official version in that case. They need to set criteria for what qualifies as fulfulling the bounty regardless, so that would just be one more criterion. > It seems like open source software development settles into a groove > that isn't Pareto efficient, even if it's much better than closed > source. Think about how much time we all invest in learning and > developing Clojure. The more the ecosystem expands, the more our > investments of learning and development come to be worth, and the less > likely we are to lose them to some other technology taking over down > the road. And yet the ecosystem itself only gets worked on as a > second priority to other work. That's probably as it should be. The ecosystem itself is, after all, a means to an ends (useful software tools) rather than an end in itself. Things that directly improve the ends (the tools coded in Clojure) will naturally get some priority over things that do so indirectly (ecosystem improvements). That said, one of the less efficient things about the Clojure development process is the whole CA thing. A lot of FOSS projects seem to get by fine without erecting such a barrier to participation. On top of that, I'm not sure the CA thing really protects Clojure from the boogeyman of someone later deciding to rescind their permission to use code they wrote. After 35 years, someone who signed their CA and sent it in can claim termination rights and effectively undo the CA, and if you don't think their code will still be in use in 35 years, sorry, but that isn't where a betting man should be putting his chips. The guys that wrote all those two-digit date fields in all that old COBOL code for various banking systems back in the early 60s clearly didn't expect that code to still be in use on January 1, 2000, and look what happened. :) > It's a dilemma: either you get unsharable, secret technology worked on > full-time, or you get sharable technology part-time (with maintenance > dependent on the vicissitudes of life). I'd like to think a generous > and not overly expectatious community can transcend it. Lots already have, notably the Linux community. OT side issue, added because this is the main group of outside-opinion techies I have access to: a Vista box we use for miscellaneous purposes got hit by the "System Fix" scareware recently. Diagnosis was easy and recovery was complete and only took tdsskiller, another malware scrubber, four reboots, and a couple of hours (aided by having physically shut off the power and restarted in Safe Mode as soon as it was clear that the box had somehow been hacked), but I'd very much like to know how that box got hacked in the first place. Nobody that has access to it isn't tech-savvy. IE isn't used on that machine, or Outlook, or any other notorious giant security hole masquerading as a MS network client, the OS and Firefox on it are kept patched up to date, both had just *been* updated (Firefox 11 had just been installed a day or two earlier, and the March Patch Tuesday Vista patches a few days before that), and it had antivirus with up-to-date definitions (Avast!, which updates itself on all our boxes two or three times daily to judge by the chorus of annoying "Avast virus database has been updated!" voice clips that echoes through the place every few hours.) Everyone using it knows better than to open a suspicious email attachment or similarly. Furthermore, I was sat at the keyboard myself when the attack apparently occurred, just browsing idly while waiting for something-or-other. Firefox suddenly disappeared, Avast! warned that a process with a suspiciously nonsensical filename was trying to disable the ability to use task manager, and then other things started crashing, without my having run anything from any source. Improbably, it seems that it must have been a new version of the scareware (thus invisible to Avast! until it tried to do something sufficiently naughty, instead of being identified and quarantined instantly on launch) that was deployed via a zero-day (or nearly so) exploit in Firefox 11 that isn't blocked by Vista's Data Execution Protection settings (which I just verified my currently running Firefox process is protected by) and was hosted by a seemingly reputable site (no way am I dumb/crazy enough to surf porn or warez sites from work). Just to make sure this sinks in, this was ahead of an OS's security patches from less than two weeks prior, ahead of a browser's security patches from less than one week prior, and ahead of virus definition updates from less than *eight hours* prior, AND not stopped by the DEP on the Firefox process, as well as not hit by surfing a seedy back alley of the internet but rather by surfing along cyber Wall Street and e-Broadway. Does anyone on this list have any idea how to ensure it never happens again? Nobody here has a clue. Every security precaution was taken, other than "using the machine while logged in as administrator", which is more or less necessary when doing lots of software development; nobody admits to doing anything dumb like opening a questionable email attachment, and nobody here would lie about something like that; the browser history had no sites of dubious morality/legality in it. So, this simply should not have been possible. Other than "don't use the web until Mozilla releases Firefox 12 with yet more security patches", how is a recurrence to be avoided? Even two hours of lost productivity (with zero data loss) is two hours too many, and as far as I'm concerned what happened was a violation of our property rights not much less severe than if someone broke a window and tried to abscond with the hardware in the dead of night, thwarted only by the machine being chained with one of those anti-theft doodads to the desk and the desk itself being too big to fit through the window. Short of having any way of siccing the cops on the burglar, I'd at least like a way of making that glass shatterproof and rigged to an alarm from now on, so to speak. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
