HN user
Well, I wouldn't run Gentoo on it. Compiling Chromium takes about a day, and I'm not a big multimedia user. But in day-to-day development work (both client-side and server-side) I've never had any issues. I had actually forgotten it's a Core M.
And updated UX305CA works great with a 4.5 kernel.
Yes, you are right about local storage. I just had my browser locked down too tightly.
But, yes, looking forward to really using it at work this week. I hope to have more useful/constructive feedback for you after that.
This is nice work! I've already downloaded it and started using it. The workflow is absolutely perfect, and is exactly what I have always wanted in a task manager. It fits with my mental model of how I try to keep track of tasks while coding, and may, possibly, prove to be an improvement over pen and paper.
One concern I have is there doesn't seem to be any sort of persistence. I can argue that this is actually a feature: if you don't know what you need to be working on when you sit down at the keyboard, you have bigger problems. (I may be influenced by Jeff Atwood in this respect.) In practice, however, it might prove useful to carry over unfinished tasks from one session to the next. Maybe a simple persistence scheme like that used by TiddlyWiki would be enough to get the job done?
Also finished tasks disappear. It would be nice to be able to review and figure out where the day went. But that way lies feature creep.
But, anyway, those issues are minor compared to finally getting workflow right (for me, YMMV). I'm really excited.
Thanks for sharing this!
CFEngine has really great, comprehensive, reference documentation and really very poor, basically non-existent, tutorial or getting-started information. In order to actually get work done, you need to know a good bit more than how to install it and what the bundle syntax looks like. Puppet OTOH excels in this.
So while the tools are roughly equivalent in capability, if you're new to configuration management in general I think you'll have a lot better success getting started with Puppet.
I honestly can't decide if the news that many scheme implementations encourage you to not follow the standard refutes or supports my point.
Either way, good to know.
...gets back to work hacking in SBCL.
I was in the same boat until I finally read this (chapter 8):
Scheme may be simple, but scheme macros are not. They go way overboard in trying to protect you from yourself. I'm glad to see Arc moving back in the direction of CL macros, which I think makes it a very interesting alternative to Scheme.
It's too easy to tease, but I will try to resist.
But, seriously, they've been talking about this GPU work for upwards of a 1.5 years now. Usually we get something to play with, even if it's pretty badly broken (I'm thinking NDP here), so the lack of code here is pretty atypical. The accelerate link above is news to me, though, so that's helpful. Hope to see more soon!
* EDIT (to back up my 1.5 years claim):
earliest mention, May 15, 2008: http://www.cs.chalmers.se/Cs/Grundutb/Kurser/svh/Slides/may-...
Chak's own work, Jan 10, 2009: http://www.citeulike.org/user/iff/article/3872848 http://www.cse.unsw.edu.au/~chak/papers/LCGK09.html
and, of course, accelerate ("reference implementation") was only released Aug 17, 2009: http://hackage.haskell.org/package/accelerate
I'd be grateful if anyone could point me to the actual code for this. I'd like to give it a try for myself, but all I seem to be able to dig up is research papers.
Digsby has never kept secret the fact that they were considering grid-computing as one possible way to monetize their product:
http://blog.digsby.com/archives/68
The license agreement is simply worded so as to make this possible.
Good to know, thanks.
Haven't used it, but Erlang bindings: http://dukesoferl.blogspot.com/2008/06/tokyocabinet-and-mnes...
Oh, I don't for a second dispute that JavaScript is a much more elegant language than Java, and I would also put it on par with Python. Remember, jQuery is always my first choice.
I only assert that once your (well, my) code base grows beyond a certain size---for me, a few thousand lines, but probably an individual threshold---JS can start to become unwieldy. That "unwieldy-ness" is a problem that Java/GWT does solve. In these cases I prefer Java precisely because it is more constraining.
I think such a developer (one that has strong knowledge
of both JavaScript and Java/Python/Objective-C and still
feels compelled to use one of the abstractions) doesn't
really exist - at least not in any significant numbers.
First, history: Roughly ten years spent programming in JavaScript (it's hard to believe it was that long) before GWT came out in 2006. Immediately tried GWT, found it too heavyweight, and returned to JavaScript (jQuery, specifically) for another two years, before finally really moving to GWT over the course of the last six months.
Experiences: It really is not possible to write a significant GWT program without good knowledge of JavaScript. I think, on average, every Java class I write has one JSNI (JavaScript Native Interface) method, usually to work around some deficiency in the library but sometimes just to circumvent Java's type system. That's not counting the classes that are pure JSNI that exist to wrap up some JavaScript functionality.
It has also been my experience that it takes roughly 4 lines of GWT code to do the work of 1 line of JavaScript (with a good library such as jQuery). That's from comparing LOC counts on a handful of medium-sized projects I implemented with both technologies.
So, why? The thing that keeps me using GWT even though it is an incomplete abstraction that requires more code is organization. Partly that comes from the fact that OOP is a better fit for GUI programming than the functional paradigm. Mostly it comes from having a nice build system that lets me organize my code in the traditional Java hierarchy. There are lots of ways to try to organize large JavaScript projects---I think I've tried them all---and none have every really felt satisfactory to me.
In the end, most of the time when I'm writing a web page I reach for jQuery first. But when the functionality of a web page crosses over some ill-defined threshold such that I start thinking of it as an application in itself, I change my tools and reach for GWT, all for the benefit of (to me) better organized code.
YMMV.
(Edited for formatting.)
You mean like:
And there's this very exciting new development:
http://webanywhere.cs.washington.edu/wa.php
Just for completeness, I'll add this link:
Really, though, the problem is one of established vendors with a lock on the market and, consequently, little motivation to improve their products. Sound familiar? At first pass, this would seem like prime breeding ground for startups, but there are serious barriers to entry.
The biggest obstacle for new products is just that visually impaired users are taught to use JAWS from the get-go: they have the educational market. Yes, they hate it, but when you can't see it's very hard to comparison shop. All screen readers have a big learning curve.
Then, if someone could find your product, evaluate it, and like it, well... most people in the target market are not self-sufficient, and would not actually be able to pay for it. (You would have to market to the charities and grant foundations that purchase the products for most users.)
Oh, and did I mention that it's not easy to write a screen reader in the first place?
As much as I would love to see a startup come into the arena here and change the rules, I think instead we just have to hope for the success of these various open-source projects, and be glad that there are people who take this problem very seriously and are working on it.
Until then, designers and programmers will have to cater to the various quirks of the market leaders. This article is one of the best guidelines for that I've seen.
I was about to respond that they had moved my house about 40 miles---that's where it was when I first noticed this problem two weeks or so ago---but when I just went to maps to confirm before posting I discovered that I now no longer exist at all. So, not just you.
It is dangerous territory, tread carefully. I've seen situations where "exclusive partnership" means "this is threatening to us, we want to put this on a shelf and get it off the market." If the fact that you're asking here reflects a negative gut-reaction to the idea, you might want to listen to your gut. There was an interesting and relevant article posted to HN about two weeks ago: http://news.ycombinator.com/item?id=309526
I realize this is just having fun, but I'm often reading this-or-that to the effect that startups are bad for your health. And, I just don't get it. Or rather, I suppose, I expect that anyone who thinks startups are bad for your health has never worked for corporate america.
Working a job was the worst thing I ever did for my health. Now that I'm at a startup, I get plenty of sleep and exercise and eat healthy, home-cooked vegetarian meals. And the stress involved in working for myself is so much less that that of working for a PHB... I could never go back.
In the last two years, I've lost 50 pounds. I recently completed my first century. I'm in the best shape of my adult life. I sincerely attribute all this to being my own boss and setting my own schedule. Am I really the only one who finds the startup life superior???
And again... I'm putting a few finishing touches on a port of Distel to PLT Scheme that I plan to release this week. I mention it now only because I would hate to see this article inspire anyone to go off and invest in too much duplication of effort. Lisp and Erlang do go together very nicely.
But to answer the question posed by the article, FFI binding to the C erl_interface quickly gets very nasty, with lots of manual memory management. (It was the first thing I tried, since PLT has such great FFI support.) It's actually much easier to just speak the wire protocol, esp. with the Distel source to build on.
I hate to be a ditto-head, but I couldn't agree more. If they have bigger teams and more money, that almost always means you have the advantage. The only way you can lose is if you panic and make bad decisions. Plan your climb and climb your plan.