semisight

Guessing as to what the GP meant--coral TPUs max out around 8M parameters, IIRC. That's a few orders of magnitude less than the smallest LLM model.

More context: https://notabug.org/libreboot/libreboot/commit/27fce189cd1cd...

Well this strikes close to home. During grad school, I'd drink a red bull (or two) a day. Now, I've quit caffeine completely (save a tiny cup of coffee in the morning occasionally).

I hope the author has a quick and easy recovery.

Playing them against each other would be a pretty cool way for the two companies' AI teams to compete though.

Facebook is heavily invested in Torch, a learning framework built in Lua.

A Neural Turing Machine can learn programs.

I'm not sure I agree with you, long term (about the chips). I think that the value here is in the ecosystem. If Google can compete with CUDA, they'll be doing really well.

Yup, I assume they're gonna keep them in house as a competitive advantage for a time. I doubt they'll do it forever; the most valuable part of NVIDIA's CUDA is the ecosystem, and I think Google knows that.

This is huge. If they really do offer such a perf/watt advantage, they're serious trouble for NVIDIA. Google is one of only a handful of companies with the upfront cash to make a move like this.

I hope we can at least see some white papers soon about the architecture--I wonder how programmable it is.

For 3., I've been interested in the same. How would it work though? Would it include non-free components, or be open source? If it's open source, why would the majority of people pay?

I say this as someone who would definitely pay. I'd love to see something like an XPS developer edition, but with a (relatively) coherent graphics paradigm like OS X.

+1 from me. My favorite feature for browsing Reddit is the RES collapsing button.

If HN declines to add it, maybe someone can make an `HNES'?

Almost all of the open source software in the area is permissive-licensed, and relies on non-free components (CUDA).

To be honest, I'm not sure how Gneural plans to compete with those packages without support from CUDA or cuDNN, all of which are distinctly not open source.

Can't speak for OCaml yet; I've wanted to learn for a while but decided to go with Haskell first.

On the Haskell side of things--it's biggest seller (functional purity) is also the biggest downside. To give you an idea, papers have been written about the best way to implement common data structures purely functionally.

From what I've seen, OCaml has less "abstraction overhead" because it can dip into imperative code. While Haskell is really fun, it definitely has moments where you want to beat your head against your desk.

Thanks, I didn't catch that. I'll have to make some time to play with this, especially once it gets further along.

This seems more like MirageOS/Ling than a rumpkernel. From what I remember, rumpkernels are more general, at the cost of being less "unikernel-y" (i.e. lean and fast). I agree that it would be easier and faster to use a rumpkernel if the intention is use in production soon.

I can't tell if this is a research project, or intended to be production quality at some point.

Noticed the same thing, wondered if I was missing some niche side effect here. TBH, I've noticed there's almost never a reason for a general reduce() in Python (to my usual dismay, as an ex-Clojure programmer). It does result in clearer, less clever code for the most part.

I'm five years out from this and still remember the stress. Students are now asked to give up their present for a chance at a good future.

Exciting to see this! I haven't taken a look at TensorFlow code yet but it looks very similar (method names and all) to Caffe. I've wanted a CNN library for Rust for a while.

It sounds like performance is important to you. Are there any plans to add GPU paths soon? If it's CUDA, are you going to use cuDNN?

Good to see this project making progress, but I don't see a changelog. What's new?

140 characters may not contain the full breadth of his view on the topic. Tweets are easy to compose but myopic. All the same, I understand your point. There's definitely stuff we don't know here.

Change is sorely needed, I agree. And I don't think that the Common Markdown team should be forced to be backwards-compatible (I would prefer they didn't). However, Gruber's request to simply not call it Markdown is fairly reasonable, the same way you wouldn't call Clojure "Common Lisp."

It was certainly their decision to do a clean fork or not, and I'm not judging them for wanting to take ownership of a neglected project. I was just commenting on the fact that Atwood had sent an email and expected a response in 24 hours or so. A week or two would perhaps have been sufficient.

I think those are two different issues. Gruber has a legal and moral right to ask the Common Markdown maintainers to change names. The easiest thing is just to not have a name with Markdown in it.

I don't disagree that it is still mostly Markdown. I do understand the Gruber complaint about it not being a strict superset. I see it as similar to C/C++. Not all C code is valid C++ code--they have diverged. No one would deny that they have a very closely shared heritage.

I agree with the majority here--Atwood's reaction complies with the word of the request, but not the spirit of it. On Twitter, Gruber says that he's opposed to the naming because it restricts markdown [1]. Aka, valid markdown from Gruber's markdown processor may not always compile on Common Markdown.

Honestly, this seems pretty reasonable to me. I also don't think that the Common Markdown implementors gave Gruber a sufficient amount of time to respond: "We haven't heard back after replying last night, and I'm not sure we ever will..." (emphasis mine). Last night? This is one of Gruber's most famous projects, and you're giving him hours to respond?

Honestly, I think they're going about this the wrong way. This group has people at both Stack Overflow, Reddit, and Github, three of the most prominent users of Markdown. Why not rename their version completely? It would eliminate the possibility of future conflict (which IMO is almost guaranteed). They don't need the name recognition--Markdown has needed this for a while, and I think it will be adopted fairly quickly.

As for "new" names, how about:

* ReMD (pronounced "remedy"): fairly standard programming naming convention--adding "Re" as a prefix. Also easy to Google.

* Vernacular: Longer, less common word.

Good luck to Atwood and Co.. I really do hope they find a way to keep the project going.

[1] https://twitter.com/gruber/status/507651498692849665

There technically is an "unsafe" mode, but not in the way you're thinking. You can drop down to C level by writing code in unsafe blocks and using methods prefixed with "unsafe." This will stop the compiler from doing things like inserting bounds checking and should perform fairly close to Clang.

Generally though, rust strives for the same ideal as C++: you only get what you pay for. You can carve out the subsection of the language you need through things like feature gating without too much trouble right now (and the standard library is still improving in this regard).

Why? Vim is a well tested codebase. It has many features. Starting over would produce better code, but in what timeframe? I think the neovim contributors made the right decision to refactor.

My grandfather helped Hyatt to write his patent. Interesting to finally see any press about him.

Just an FYI however: there are lots of different subtypes of Cherry MX keys. You can go with Blue or Green switches (named for the color of the 'stem' under the key cap). They give you a Model M-style feel, with a click halfway down. Brown and Clear give you the feel of the click without the noise, and Red and Black are quiet. User preference and all that.

Very cool. Reminiscent of express.js, but statically typed and in Go. I may look at this for future projects.

I never felt pained on switching layouts. If this makes any sense: learning the muscle memory for Colemak almost seems to be on a lower "level" than vim (to me), so I kept hitting 'i' and 'a' and so on without even noticing.