HN user
Hmm. My Mom was a trained engineer. She's no longer with us, but if she'd lived long enough to select a Bitcoin wallet, I have no reason to believe she'd have picked a poor one...
(And yes, I get the irony that they probably picked this headline out of fear that "not your dad's..." was sexist.)
Without newsblur support, not really likely to rebuy.
I respect the work involved in moving what had been a google reader client into a true multi-provider client, so would rebuy it it supported the provider I actually use. :-)
This doesn't seem to me to mean as much as the author thinks.
By the same reasoning, after all, email as a communication mechanism is "dominated by" spam, much of it similarly shady in nature.
There is an interesting difference, though -- while spam actively hurts the usability of email, botnet traffic which parasites on the TOR network helps make the system as a whole stronger, by adding more noise in which the important uses of TOR can be lost.
Yes. A central idea of the American experiment is that there are exchanges of liberty for security which it is not acceptable to make even if the people collectively decide to make them.
That is why certain liberties are enshrined in the Constitution, which is intentionally made hard to amend, rather than merely in law, which is relatively easy to change.
Looking at the number of totalitarian systems which started out as expressions of the collective will of their societies in the two-plus centuries since, I'd say the founders got this one right...
Dumb question, but the author kept running a TOR node at a site he knew was under NSA surveillance? That doesn't strike me as very responsible...
Except that before "just supporting Linux (and maybe MacOS)" was the thing to do, it was "just support Sun (and maybe HP-UX)". And before that, it was "just support BSD/Vax (and maybe SVR2)".
So, when you take a broader view than "just support what everyone uses", you're not just helping niche platforms -- you're future-proofing.
Beyond the question of how meaningful these metrics are, wouldn't it be a more useful metric to look at how complex the code you write when you use each framework is, rather than the code that implements each framework?
I suspect -- but don't know -- that these might even turn out to be inversely correlated for some types of frameworks. DSL-based frameworks often require some interesting tricks to get right.
So which is better? A complex framework that lets you write simple, concise code? Or a simple framework that requires a lot of boilerplate and complexity to use?
This will not only miss non-ascii printing characters, but it's not even much shorter than typing
[[:print:]]
This would seem a problem that could be solved by a cloudish sort of solution, though -- have an iPad app which hands actual typesetting of a document off to a server somewhere, sending TeX sources, and receiving a PDF in return.
A simple starter implementation might require your TeX to be a single file, and could just run TeX in a mostly-readonly chroot jail (bearing in mind that TeX can shell out, read/write arbitrary files readable by the executing user, and so on), and serve up a PDF, all wrapped in a web service of some sort.
This wouldn't be terribly fast, but given TeX's performance, the actual typesetting is likely to be the bulk of the time spent, even considering the round trip.
I think you're not considering enough ways in which one technology can be superior to another.
Ruby wins for the web not because it is faster _at executing code_, but because the combination of Ruby and Rails is faster _at iterating new features_; the optimization which has led it to win is performance of programmers, not code.
Likewise, Windows is inferior to Unix as an OS design -- but it is vastly superior to (non-MacOS) Unix in the time it takes to get a semi-technical user from a machine still in the box to a machine which can do the things most users care about (browse the web, edit documents, and so on).
In the long run, which matters more? Machines are getting faster much more quickly than programmers or users are getting smarter...
No disagreement with the basic, point, but was a bit surprised by this quote:
"So, here's our situation. We have a man (presumably; at any rate he appears to want to be identified as such) in the Australian Linux community, who targets women by sending them private abusive emails from a throwaway address and with a name that can't readily be connected to any publicly known member of the community. His ISP won't hand out information about him without a court order, his abuse doesn’t present the kind of imminent threat to physical safety that might interest law enforcement, and despite Linux Australia’s diversity statement and Linux.conf.au's anti-harassment policies, it's not clear that there’s any practical thing that either of those groups can do about him."
Is it Bayley's position that ISP's should give out information on their users in response to warrantless requests -- from private individuals, no less?
Is it likewise Bayley's position that law enforcement should be going after people for making lewd comments online?
There's a Mr. Turing here to see you about whether this site is really connecting him to a lady, sir.
There are a couple of ways around this -- all of which fall under "be careful". :-)
though be careful how you do this -- it's easy to end up with a divergent program, as prolog tries to:
* prove X(A,B)
* realizes that it can prove this if it can prove transitive(X, A, B, C), and then prove X(B,A)
* realizes that it can prove this if it can prove transitive(X, B, A, C), and then prove X(A,B)
* ...
Wait, really? "Anger"?
I mean, "disappointment" maybe. Or "annoyance". Or "wistful regret" -- all reasonable reactions to the real loss you suffer when someone else decides not to pay for your education.
"Sadness", perhaps, if you believe society is worse off for not having more PhDs int he world, I'd buy, too.
But "anger"? How entitled do you have to feel to be "angry" at not getting a free ride?
Just askin'...
In fairness, this is stretching the meaning of `binary blobs' a little, right?
I may be misreading, but the issue is that some of the elisp sources of CEDET were generated from bison input files automatically at some point -- but they're still elisp sources; a user can still modify them if needed, and if an asteroid hits the house of whoever did the original conversion, development can still continue that way.
That doesn't mean that _technically_ we wouldn't be a lot better off if the bison sources made it into the next emacs release, for completeness and ease of future development -- but I'm not sure I see the GPL violation here.
Yes -- one could argue this opens the door for other bad behavior at OSCon, since it's not on the (new) list of things not to do.
That's the problem with putting these things in writing -- the more rules you write down, the stronger the impression that whatever's not on the list isn't against the rules.
So, the complaints seem to break down into two types:
a.) things which broke because they depended on Rosetta (PowerPC emulation), when Apple has been warning for at least three versions that PowerPC emulation will be going away any version now.
b.) things which Lion makes available to apps (new APIs), but which Adobe apps don't yet use -- meaning only that their apps work as they always did, but don't take advantage of new features of Lion.
Depending on the length of Adobe's release cycle, they may not have had enough time to prevent b.) since developer previews of Lion became available earlier this year -- but they can't really claim they didn't see a.) coming.
I recently read both volumes of "Artificial Intelligence -- An MIT Perspective", which is a great view of the high-water mark of the MIT AI Lab. This two-volume set, put together between 78-81 is a review and collection of papers showing off the current state of the art in the AI Lab's work in five areas:
* Computer Learning
* Natural Language Processing
* Computer Vision
* Manipulation Technology
* Programming Languages (including short versions of GLS's thesis on CPS compilation for Scheme and Carl Hewitt's ACTORs paper, and a review-and-outlook paper on the development of the MIT Lisp Machine, among others)
Along with introductory comments by Patrick Henry Winston and Richard Brown, the set includes papers by Marvin Minsky, Gerald Sussman, BKP Horn, Jon Doyle, Richard Stallman, GLS, Hewitt, and more.
Taken in total, the collection shows how the world of AI looked from MIT goint into the eighties, before the boom and the bust which followed.
Now, you can get each volume for $1.00 on AbeBooks. Sic transit gloria mundi...
Yeah -- there was a great example of this yesterday, too:
Pretty much exactly my experience, except that I'm running a lot more compiles and a lot less photoshop on this 13" MBA.
In particular, if you're upgrading from a machine without SSD, the speed advantages you'll see for things like emacs or compiles of large projects -- things which access lots of small files -- are huge.
This machine replaced a MacBook Pro which was technically its equal in processor speed, but it feels faster in every way (and is a heck of a lot more usable on the train).
Decades in, I don't think we have a meaningful (or at least measurable) definition of what productivity actually means (the article touches on this).
So it's hardly surprising that we don't pay in accordance with something we still don't know how to measure...
It's kind of obvious dropbox wasn't storing raw file blocks encrypted, or there wouldn't be much point in doing dedupe -- any reasonable crypto algorithm should be giving you output close enough to random that two users storing the same data with different keys would not dedupe with each other.
So unless they were only deduping two copies of the same file blocks if they were stored with the same key, at least the data blocks are being stored plain.
As for who can access the fact that a given block is yours -- well, they still make substantially better promises than most ISPs or hosting companies do.
So yeah. Have reasonable expectations about how private data there is, and decide what to store there accordingly -- and if, before this change, you were expecting them to fight a warrant for you (or even say no if threatened with one) rethink your plan.
Sure -- but they were beaten by ordinary machines because the combination of better ordinary machines and better techniques for running lisp on ordinary machines improved to the point where lisp machines weren't better at running lisp.
A lot of this is that a few small low-budget research groups were building lisp machines at a time when the big players suddenly started pouring all their efforts into developing commodity single-user graphical workstations. But it's also true that developments in GC technology -- developments which Torvalds seems unaware of in this 2002 post, even though they were 15-20 years old by then -- made GC really fast even on hardware not designed with GC in mind.
I'm not sure I agree -- it's my experience that too often `practical concerns' become an excuse to teach faddish details of what is being done in the `real world' now, instead of provide any sense of the parts of the field which don't change with each new technology.
I'd rather teach a new hire who had worked through a curriculum built around SICP[1] or HtDP[2] the languages and technologies we actually use here -- even though we never write a line of scheme -- then teach a student who got a four year `Computer Science' education focused on the details of a particular programming language or technology stack how to use that very stack to accomplish lasting things...
Anyone know what's changed in the new edition? Addition of IPv6, I assume?
Nice to see A-W keep developing these (and APUE, and UNP) after Stevens' passing. Hope Fall proves as good a choice here as Fenner did for the new UNP edition.
This is obviously a book about how Steve's small business succeeded in one small niche industry -- but a lot of the advice here is more general.
For those interested in his niche market, there's also interesting stuff here about entertainment franchise licensing, SFG's switch from big print runs to in-house print-on-demand, and more.
I'm not sure that judging a retail sales strategy by change in sales between January and April of 2009 -- exactly the period when consumer confidence plummeted to match the tanking Dow -- is a great idea.
For comparison, line up this chart
http://finance.yahoo.com/echarts?s=^DJI+Interactive#chart1:s...
with the one in the article...
I guess the test will be whether sales will shoot up when they reverse this policy.
(The article also doesn't say anything about whether they tested this approach in some stores before converting all stores; Walmart has a long history of mining their sales data to try to pick out patterns in store performance, so if this was done as abruptly as the article says, I'm surprised.)
Try ESC-@, which runs mark-word -- once you have the mark set, you can expand/contract the region as normal by moving point.
I think the fact that we're now asking this question shows how successful the Scheme and Common Lisp efforts have been.
Thirty years ago, there were dozens of variants of LISP out there, from the mainstream (MacLISP, InterLISP, Lisp Machine LISP) to the esoteric (it seems like every major CS department in the world had a local LISP dialect, much as many of them would soon have local Unix dialects).
Many of these dialects had differences between them -- from the everything's-a-message architecture of Carl Hewitt's ACTORS (think smalltalk-meets-continuation-passing-style) to a number of LISPs with logic programming features. A number of dialects even played with Algol-like syntax (McCarthy himself had planned to give LISP an Algol-like syntax. S-Expressions were a fortuitous stopping point on the way to an implementation of so-called M-Expressions which never came).
In the writings of the time, I don't see much debate over whether these systems were or were not LISP. Mostly, people understood this as a big family of languages.
In contrast, Common LISP and Scheme not only have much more in common than those LISPs did, in one important regard (lexical scoping), they are closer to each other than they are to the vast majority of historical lisp implementations. The only reason we're asking this question is because after the fading away of other historical LISP dialects, the differences between Scheme and Common LISP seem bigger than they are.
So yeah, I'd say Scheme is LISP.
(By the way, two great looks at the LISP family tree are The Evolution of Lisp[1] by Guy L. Steele and Richard Gabriel, and Olin Shivers' History of T[2], an early dialect of Scheme with an extensible version of set! similar to Common Lisp's SETF)