iand675

It's really like that. In the countryside, you'll occasionally see rice fields with small walkways in between them in a + configuration with a vending machine hanging out in the middle. Presumably for the farmers to get something to drink...

Having not really used Discord, what about it is better to you?

I don't understand this part:

> If you don't have a CSS cookie set, I inline the CSS in the HTML, load the CSS file asynchronously with a slightly adapted loadCSS JavaScript, and set the cookie.

What is the purpose of the cookie here? Is CSS being stored in the cookie? Does the value of setting the cookie exceed using an Etag to only load the CSS if it's modified?

I actually just paid real attention to this pointing technique on my way home today for the first time. This isn't just a puff piece for a technique that only a few workers do.

It appears that organisation is named Gravitational, and the project name is Teleport.

I don't think there's much basis for this critique aside from the poor title choice.

So the latest AMD cores seem like they might be more competitive... does anyone know which AMD processors are likely to support ECC memory? My one big gripe with Intel CPUs is that they currently only support ECC memory for non-consumer chips. I run a personal ZFS cluster and am more concerned about data integrity / cost than I am about pure CPU performance.

Bootstrap was not made by GitHub. You're thinking of Twitter there.

Very clever. Would be interesting if you could map the text input to words that he's said contiguously in real life.

My first test was typing in "I never said that.", and it would have been great if it actually pulled a clip of him saying the entire phrase.

Granted, the corpus of things he's ever said on camera is fairly large.

At the risk of oversimplifying:

Why would anyone expect Hayao Miyazaki to be interested in programatically generated walking algorithms for 3d zombies? That seems so far outside of the realm of anything that Miyazaki has worked on that expecting meaningful feedback from him seems rather foolish.

Last time I looked, RSS and Atom didn’t have pagination support and many RSS feeds only show the most recent N items. I'd say solving that issue to make feeds more browseable would be a significant improvement for the way that I want to use them.

Cash-based for consumer payments (especially in the countryside). Business-level payments and cities have much more extensive credit card support, and it's only continuing to become a more common payment method.

This is neat, but the tags don't make for a great first impression. #gore, #violence, #beating, #shot to death. It's all well and good if people are into that, but probably a turnoff to the average user that comes across the site.

I use it, so...

The Haskell one is a bit off, honestly. Web development is one of Haskell's stronger areas, and it doesn't event rank for that at all.

Not even the right continent for me.

You're kidding, right?

Yeah, sorry for not addressing that. I guess what I'm getting at is that I don't agree with the fundamental premise of the article. I don't really see "a large enough subset of the Haskell community never reaches that stage and just continues to delight in how clever they are for writing Haskell", and I've used Haskell for about 9 years now. Where are these people?

I think you're equally missing the point– for serious Haskell programmers, using a monad to structure computation for a CRUD app is nothing to write home about. Having personally written quite a lot of CRUD code with Haskell, I have never thought "Gee, I wrote this with a monad. I deserve a back pat."

If we're talking about things that make me smug as a Haskell developer, I'd probably say that I feel most accomplished when I figure out how to encode more invariants into the type system so that the compiler helps me make fewer errors. I still stand by Haskell as being the best language for that that's not just a university research language.

It's worth noting that it was written quite a while ago, so while it's still a great book, there are portions that have a wee bit of code rot. In the event that one of those sections trips you up, I'd encourage you to visit the #haskell IRC channel!

I'm using it with pretty good results so far. I had to stop using Emacs for a long time because I was developing a case of Emacs pinky, but I can appreciate that it does a lot more out of the box. After switching to Vim, I really came to appreciate its idioms too. Spacemacs lets me get the best of both worlds.

I noticed that it says "the first shading language" to be supported will be GLSL. Does that imply that there will be a new shading language or extensible shading language facilities?

> Not in portable computers. I can get a TB, but that's it. I have build artifacts that clock in at about 300 - 500 MB and I'd version control them if possible. I can't, because that would fill my disk within a couple of month, so I have to push them to a server and somehow link them.

git-annex is a pretty good solution for this: https://git-annex.branchable.com/

> That's a strawman. The article does not argue that there's no use-case that's solved by git or and DVCS. It's just that not every use-case is solved by git. I'd even go out and argue that most use-cases are solved just as good by a solid centralized system with less complexity involved.

I'm not convinced that it is a strawman– I'm not an uber-developer, but I've had to do it reasonably often. A common case is that the originator loses interest, and you still need to do maintenance on it. I'd rather my go-to choice of a version control system support that notion rather than learn a different tool to deal with this case.

> I see a developer wedge his git repo with a pull + rebase about once a month. And then somebody needs to walk over and explain. DVCS fundamentally introduce complexity that is not always needed. And I doubt that the fundamental complexity can be abstracted away.

Sure, there is an additional level of abstraction, but to argue that it's insurmountable seems rather pessimistic. Most technologies that we take for granted now required multiple decades to get to a consumer-friendly state. This is perhaps a philosophical difference that only time will answer.

Anyone else remember the days when having your SVN server go down meant that you more or less had to wait until the server came back up before you could get back to doing things? (if you wanted a nice atomic commit). Let's not forget people that have to travel a lot for work– SVN + airplanes is a match made in hell.

Anyone else ever had someone delete or close an open source project that you cared about? Finding a copy with the history that mattered to you could be tricky.

Anyone else ever needed their own fork of something due to differing goals from the parent project, but needed to fold in upstream changes relatively often? That's by nature the sort of problem that a DVCS solves easily.

Other objections to this article:

* Nothing precludes you from using the patch model with DVCS (I mean, Linux kernel development uses Git just fine with this)

* The author mentions that you have to retain the whole history of a project. For one thing, storage is cheap. Another point worth mentioning is that you can make shallow clones with Git. I don't know what the status is for committing to them these days, but there's nothing fundamental that should prevent a DVCS from letting you work on shallow clones if space is such a big deal.

I could go on, but the article seems to be griping about UX issues. Just because we haven't had tools in this space with wide adoption that are user friendly doesn't mean that we won't eventually.

They neglect to mention that you have to have a Red Hat subscription to view the paper.

Very cool, but seems like it would be nice to have the hardening steps documented outside of code too (for those of us with more exotic provisioning tastes).

The icon animations are really slick!

A nice way to look at it: if you share what code you have had to reimplement, you're making it more than 69% great for the potential Haskellers that follow!

I'm not stellar with C, but I'd be happy to contribute!

While I can understand that the Docker team operates in a very Go-centric environment, it’s a shame that some of these libraries don’t export a C interface to enable other languages to use them.

That being said, it’s a neat project that I’m tempted to port the ideas from.

I'd appreciate seeing a link to an example of this. I put a decent amount of work (a few years ago) into writing some bindings in Haskell to the objc runtime, but ended up shelving it until I could come up with a satisfactory solution to the variadic function dilemma.