halosghost

I have not found one yet; I do not believe one has been posted at the moment. But, I would love to see the actual talk and the Q&A as well. Here's hoping one gets posted.

This is great to see! I don't know if it was inspired by runhaskell, but it does appear to be similar. I have to say, this kind of tool is something I have come to feel is incredibly helpful and important for my dev workflow.

I spend most of my time developing in statically-typed, compiled-to-machine-code languages; obviously, one of the major advantages of more dynamic or interpreted languages is the ability to rapidly prototype. This type of tool allows me to quickly prototype something without losing all the power, control and other benefits of my languages of choice (in particular, Haskell these days).

Things like this make me more amenable to python by the day! Keep up the good work!

Honestly, I would not be able to use this unless it had, at least, a native C library. Having it be bash-reliant, though quick and simple, makes it much harder to actually use it in anything native (shelling out is generally a BadTime™). I do not mean to discourage you though, using JSON as a human-readable data-store is something I've definitely done before, so you have a good idea, I just differ in my needs in the implementation.

Personally, I've used jansson[1] for this kind of thing in the past since it makes working with JSON in C an absolute breeze.

[1] http://www.digip.org/jansson/

No. A Black rook would have allowed black to b8b7 and block the white rook from the final checkmate. A knight, on the other hand, would not be able to block the white rook and would therefore result in a checkmate.

On closer look, it seems node is a makedep, not a runtime dep.

Actually, the link is just fine; it appears that you have discovered a bug in HN's URL matching algorithm. < and > are explicitly recommended by the URI RFC [1] as delimiters for URLs.

[1] https://tools.ietf.org/html/rfc3986#appendix-C

Give a shout-out to the Author(s). They are quite responsive. One of them is on the verge of rewriting pb overall to leverage some nicer things that have been created since pb's creation along with making it even faster (despite the fact that, ime, it is already faster than most other pastebins (in the US)).

You don't. Ix is not Open-source. Sprunge (an alternative) is, but I never found it to be very simple. This is one of the things I so love about pb (see my other comment ITT).

Even better than that; it only serves over https. :D

I'd recommend pb <https://github.com/ptpb/pb>. It is free and open-source (so you can easily host your own deployment of it—it's even in the AUR for Arch users: <https://aur.archlinux.org/packages/pb-git/>), provides a ton of features that no other pastebin offers and provides most (if not all) of the features provided by other common cli-accessible pastebins (like ix and sprunge). You can find the reference deployment at <https://ptpb.pw>.

Exciting to finally see the release! But the feature I was most interested in appears to have been pushed to 3.8. Namely, the addition of -fsanitize-trap=undefined (which will allow for some parts of UBSan to run at compile-time rather than adding run-time overhead and bloat).

(Also, I know many people are not terribly worried about the overhead and bloat—and, to be fair, it is pretty minimal—but, I'm a little obsessed with keeping things about as light and small as I can make them.) :P

Either way, great to see the new stuff (especially the additions to the the static analyzer and formatter)! Here's looking forward to 3.8!

Okay, so I know I'm a little odd, but my immediate reaction to this:

“Oh snap! I should totally uninstall my WM!”

Ahh, you appear to be completely correct! The project I was referring to had a software component as well (which is on GitHub); I mistakenly associated the two. My apologies!

I will leave my GP comment here in case people find the other project interesting; but they do appear to be unrelated. Thanks for clearing that up :D

It seems like you've missed the point. The problem isn't that companies are using the work without paying. The problem is that the unnamed companies are essentially lying in their marketing and violating the grsec trademark in the process.

This is not how FLOSS is supposed to go.

I was part of the indiegogo campaign to get the lantern [1] off the ground. I've heard very few updates from them since the campaign ended; here's hoping they still pull it off!

[1] https://www.indiegogo.com/projects/lantern-one-device-free-d...

This is such a bummer! I just recently switched over to grsec (on Arch) and I could not be happier with the results; seriously, it has made such a huge increse in security so simple to navigate. The Grsec team does incredible work; that no lawyer is willing to pursue this case saddens me, but that's a secondary issue. The core problem here is the corporations with money have functionally unlimited legal authority. It is so far beyond me that society has allowed this to come to be and continues to do nothing to stop it.

To Brad and the PaX team directly (if you read this): You do incredible work and I sincerely hope this move leads to an inundation of sponsorship so that even more people can benefit from your hard work and innovation. Till then, know that there are those of us that stand behind you 100 percent!

Actually clang has a static analyzer that is free and pretty usable.

Additionally, I religiously use `-Weverything -Werror` for C and specifically disable warnings I know to be false positives. People have told me that it is excessive, but I have found that it leads me to write dramatically more stable code in the long run.

Clang is also planning to add some additional options in the style of -fsanitize that will allow for compile-time checking and failure on detection of undefined behavior. That is a feature I am incredibly excited for! Having runtime-checks for UB is nice, but bloats the resulting executable quite a bit (not to mention the performance penalty). But having compile-time checks would be awesome; adds a little more work for me if I've been relying on UB, but makes the code better in the long run and doesn't affect run-time unless the change was necessary anyway.

Many of these look like great suggestions; however, I am always a little worried when I run into “C/C++”. I realize many of the suggestions in this seem to be fairly compatible with both languages (some of them certainly aren't; e.g., see the one on the front-page which is on the topic of exceptions and destructors), but I think it is about time we all accept that they are disparate languages and stop treating them as mostly-interchangable or compatible languages.

At the very least, the continued reinforcement of the myth that C++ is “just an extension” that sits on top of C really needs to stop. There is no real benefit from it and it can cause plenty of damage when developers incorrectly assume they have adequate knowledge from one of the two languages to be profficient in the other.

Actually, many of the advanced text editors offer plugins that replicate a variety of the functionality you mention. To better answer your question, I am forced to reveal the text editor I prefer (please do not take this comment as a slant to any other text editor): vim.

For vim, there are several plugins that provide completion functionality (for various languages)[1]. There are things to deal with Java imports specifically[2]. (I don't know what you mean by fixing build rules.) Hey, there are even plugins meant to facilitate whole IDE functionality for some languages[3].

Personally, I avoid things like Java so I have less of a use-case for IDEs anyway. Specifically, I code in C and Haskell (and a touch of by-hand llvm-ir for fun). In C, automatic imports and the like, I do not even wish for (since it is so necessary for me to completely understand the function calls I make, I need to read the docs quite commonly which mention the header for #inclusion). And, for Haskell, I'm constantly prototyping in ghci, so I learn what I need anyway. In neithr of these languages do I feel it is helpful enough for me to desire such things. Having said that, I understand that many people disagree; not too long ago, there was a small uproar that Haskell did not have a proper IDE yet. And I am exposed to IDEs at $DAYJOB, but if anything, that has further soured me towards them.

To all their own, text editors and IDEs alike; I think I'm likely to stick to my text editor :)

[1] https://stackoverflow.com/questions/5169638/autocompletion-i...

[2] http://www.vim.org/scripts/script.php?script_id=325

[3] http://www.vim.org/scripts/script.php?script_id=213

Interesting notion. I am inherently skeptical, because, like many I imagine (and as the article actually discusses), I am squarely in one of the text editor camps (which shall remain nameless to avoid anyone thinking I'm intending on a flamewar).

I am certainly open to the notion of alternative forms of interaction with code, but too often I see this take on the form of an IDE with “designer-like” capacities (this is not to say that IDEs are bad, just not what I am personally interested in) or the more simple interfaces used to teach kids to code (again, not a bad thing, just not what I want to use as my daily driver).

As others have said, it would have been great if they had open-sourced the code or offered a public instance so it could be vetted (even from an early perspective). And while I will do my best to keep an open mind, the macros available in other text editors seem like they may very well be capable of handling some of the functionality demonstrated in the article without much issue.

No. What you point out are not problems with the theoretical Right to be Forgotten, but rather the current implementations of it (which, like I wrote, I have not decided whether or not I can support at all).

Also, I said that it should be legal to order google to delete its stored profile of a user, not that it should have to delete the sources where it got that information from.

I know it's still quite a controversial topic, and I have not yet come down on whether or not I like the current implementations, but I am a fan of the notion of a Right to be Forgotten.

At the very least, I like the notion that a person should be able to have some level of control over what companies are allowed to access about them; the control over what information may be in the public sphere is a little more difficult to talk about. E.g., I deeply dislike that most companies operate on an opt-out system for information collection; I would rather information collection (particularly anything dealing with personally-identifying information) to be universally opt-in with some reasonable attempt (not an EULA) made to offer the user an informed decision.

Search-engines are tricky because they provide a public service for finding information but are, themselves, a company that often profits from the collection of information both in the usership of their service and in the data they crawl to aid their users in finding content.

My current opinion (which is not yet fully formed) is that it is wrong to order Google to unlist results; but, on the other hand, it should be completely legal to order Google to remove what is essentially a dossier that they have on a particular user (at that user's request).

I am still mulling this whole thing over; but, at the very least, it is obvious that the issue isn't a simple one.

In my case (and I'm not sure why), HTTP/1.1 consistently got ~5s and HTTP/2 consistently got ~10s.

I assume I was supposed to see the opposite result? :P

Happy to do it. The last thing I want is for my post to have come across as vitriolic or argumentative; I just wanted to voice the one case of unease the article left me with :)

“opt-out” is certainly correct (though, as I understand it, Pocket, as with all parts of Firefox, is only loaded when it is actually used, so “opt-out” does not seem to tell the whole story to me). I do disagree with the “non-removable” bit. Fully disabling it, to me, counts as removable (though I can understand why someone would disagree).

Perhaps I just read something into the Author's tone (probably due to all the vitriole from the typical discourse around the integration) that wasn't really there. If that's the case, and all the author meant by that statement was that the code itself could not be completely erased from Firefox as-packaged, then that seems to be factually true, and I simply read it incorrectly.

The one thing I don't like about this article (and indeed, much of the discourse around the Pocket integration) is its characterization of the Pocket integration itself. It calls it an “opt-out non-removable [extension]”. The truth is that you can easily disable it just as you can easily disable many other things that Firefox includes by-default. In fact, if you use Classic Theme Restorer (I use it not because I dislike australis, but because I really do not want a navigation toolbar), it has an option baked in to disable Pocket along with webrtc, et al.

Admittedly, I suppose it would be nice if Firefox actually packaged Pocket as a real extension that could be removed from the Extensions menu, but they have already integrated several things without using that schema.

I still use firefox, just with more and more things disabled, because none of the other browsers out there even come close to having what I need in a GUI browser (though, I would note that I'm evermore tempted to abandon GUI browsing altogether).

Either way, the write-up is great, and everything in the article other than that one characterization (which rubbed me a bit the wrong way in the wake of all the fevered discussions around the Pocket Integration) was a truly enjoyable read. Not to mention, it's great that the Pocket devs fixed things quickly; that's always a plus!

It's true that elinks covers a fair bit of what I want. But it does not have libsixel integration, does not have enough JS for me to login to the websites I'd like (afaik, perhaps that has changed since I last tried it) and does not handle <div>-layouting very well.

Admittedly, those three things are the hardest ones in the list.

Okay, so, let me premise my answer with the acknowledgement that probably /very/ few people want what I do.

1. Terminal-only (^Z is a thing that I want)

2. Capable of some basic CSS support (e.g., colors, basic text decorations; whatever can be simply translated to ANSI escape codes)

3. Capable of doing <div>-based page layouts fairly consistently.

4. Just enough Javascript support to login to a couple of webpages I like and nothing more

5. Some basic support for cookies and bookmarks (though, a session save would be an acceptable alternative for me)

6. Basic support for privacy/security features (think DNT header, HSTS, etc.)

7. (optional) libsixel integration for image/video output

Having the above presents me with the ability to leave GUI web-browsers behind entirely. Ads and the like would essentially be immaterial if JS and images are toggleable and everything would be glorious. Of course, no one appears to want this kind of thing enough for it to have been created yet. So I will eventually probably break down and make it myself :P

You're more than welcome, I was astounded by your great work when I saw it on the HN frontpage a week or two ago.

Since then, I have packaged heavything's whole showcase for Arch[1] (mainly because I'm quite interested in using rwasa for my own website but also so that other Archers may reap the benefits as well).

Keep up the awesome work!

[1] https://aur.archlinux.org/pkgbase/heavything

> Linux is 32-bit, runs in protected mode, has flat memory model, and uses the ELF format for binaries.

Well, that's a touch out-of-date :)

All the same, I do find it fun to see the set of articles recently trying to show modern programmers that assembly isn't as terrifying as people make it out to be. My own opinion is that, though asm tends to be a bit more verbose and tedious than other higher-level languages, it looks like it's also dramatically simpler in a lot of ways.

For examle, the Heavything[1] library from 2ton suggests to me that asm can still be used for high-performance applications today.

Good find and a fun read!

[1] https://2ton.com.au/HeavyThing/