I just ordered a Framework yesterday. I'm not interested in the 12th gen chip, but is there any other reason I might want to cancel & re-order today? i.e. would I be getting an older design?
Not GP but if it were me and you don't care about the 12th gen chip, I definitely wouldn't cancel and re-order. I would guess the battery improvement won't be dramatic, but you'll end up with a little more cost and a longer wait time. The only thing might be the new cover. The old one is pretty flimsy and doesn't tolerate heavy abuse well. Mine is always in my house or a backpack so it's not been a problem for me, but if I carried it around publicly where it can be dropped and such, I might be concerned about it.
If you want to play with this data, it's available in various formats [1]
I happened to use this last week because we needed test data for a community tree in an app we're building. There are nine communities, and we needed test cases with 0, 1, and many subcommunities. This not only provided ready test cases, but the team is learning celestial facts while working on the feature!
> Are you arguing that Firefox is not even "good," or just not perfect?
I’ll extend the quote a bit more:
> make it good. For many of us it isn’t
I’m saying Firefox isn’t good enough for many of us (mostly various subsets of macOS users).
As for resource hunger, in my case I see it in headless mode (it always turns the fans on), but every point in that list apart from (lack of) AppleScript support was lifted from other complaints I’ve seen in similar HN threads, not my experience.
Most of those problems I could live with in the name of supporting Firefox, but not the lack of AppleScript support. That seems to be the case for many of the aforementioned macOS users: we want to like Firefox, but theres a detail it screws up so bad for our needs, it becomes unusable as a daily browser.
See https://news.ycombinator.com/item?id=20255943. Slowness is a point I’m lifting from other arguments, not my own complaint. I could live with slowness, but that is not my deal breaker.
A simple search gave me the apparent original source for the quote; an article titled Bash — The GNU Shell, first published in the Linux Journal in 1994:
I used it on a project with many thousands of files and hundreds of (mostly dynamic) build rules. This was a literate program, and most build steps required the extraction of code from the source docs --- including build rules themselves --- and I still maintained sub-second updates.
I have! Tup was high on my list of potential replacement candidates (despite being initially put-off by the cheekiness of its homepage).
In my experiments though, Tup failed hard on point 2, lacking a good language to factorize the dependency graph declaration. (and to be clear, I think Make's is pretty terrible by itself, before GMSL or Guile extensions come into the picture)
Edit: I see tup supports Lua extensions, which may cancel my complaint above.
What language and/or system were you writing in? I discovered literate programming in 2003 and was excited by it (still am). But it never took off and the tooling was poor (Leo, the Literate Programming Editor, is the one I remember - and shudder thinking about)
Edit: some dead links there. This "bootstrap" directory contains the custom tangler and the custom rule processor. This 10K, plus the tiny configs in the root, are the only code in the project not in documents.
This kind of as-you-type evaluator is extremely valuable to me. I've written a few tools to support this in emacs, and I use the JS one all the time.[0]
I also wrote one for Graphviz (which outputs to an SVG buffer), and sometimes I'll put the output from the JS playground in `play-graphviz` mode so I can see real-time graph output from JS (by writing code to print dot graphs). ATM I don't know any other tools that can do that sort of thing, let alone compose independent ones to that end. Long live Emacs!
[0] https://bitbucket.org/gavinpc/play-modes/src/default/js-play... (There is an odd bug in OSX where the first character of the input is eaten, so I always begin these "playgrounds" with "/// playing with <whatever>". There are some other oddities which I should document.)
Which leads to this link: https://groups.google.com/g/clojure/c/OnagUrQZ1NE/m/Uwm8fvak...
Where Rich comments on the thinking behind this.
Also see https://clojure.org/reference/lisps , which compares Clojure with other Lisp dialects on this and other points