halosghost

I am confused. Most things in this article talk about tobacco products, but many e-juice and e-cig products actually do not contain tobacco, though they do contain nicotine. Is this just failure on the author's part, or is this bill not really going to affect e-cigs afterall?

I sincerely hope this is not just available for C++ but also for C.

The RFC makes it seem like it is a little Cxx-focused, but having this tooling on C would be terrific!

So, is your contention that both Go and Swift have equally-strong type systems? If so, you may want to consider saying that instead (though I am not sure how to phrase that in the format you have). If not, should they not be bolded with some elaboration on which is stronger or weaker and why? Or, were you not interested in a discussion of type-systems (if so, perhaps you should just remove the “strong” from that first line :P)?

This is roughly my point.

“Strong” and “Weak” are inherently relative terms; so, when used without a reference point, they will mean something different to different people. So, without a point of reference, the terms are not useful.

“Strong enough for what I want” is fine. But the author's point is unclear. Strong compared to what? Did the author mean “strong compared to Smalltalk”? Did the author mean “Go and Swift are Equally Strong”?

“Strong” and “Weak” don't mean anything in discussions of typing without a reference-point.

You are confusing static typing and strong typing.

I understand that both Go and Swift are statically typed. My comment is about saying that Go and Swift have type systems which are really strong, but such an assertion means nothing unless you give a point of reference (i.e., “strong compared to X”)

To clarify, type inference and strength (or strictness actually) of typing are completely unrelated. For example, Haskell, which is statically typed (and far stronger than most other languages out there—though certainly not the strongest) has incredibly good type-inference, so you rarely need to specify types.

> inferred strong static typing

“strong” compared to what? Go's duck-typing actually makes it weaker than a lot more type systems than you might expect, and compared to something like Haskell or Rust, both of these type systems are incredibly weak. If you're comparing to C, then sure, but “strong” and “weak” typing mean nothing without reference to another language.

I completely agree.

In addition, I feel like there have been so many games which might qualify as “artistic” that should be plenty (even for those who feel they have a rigid line between “art” and “not art”) to qualify video games as a valid medium for art.

For example, Kentucky Route Zero (talk about an incredible experience).

Disclaimer: I am not a particle physicist

In the theoretical physics courses I took in college, we spent a while on anti-matter, and one of the things that the professor mentioned was that it is widely accepted that photons are their own anti-particles as well. Researching this now (read: googling for sources that seem legitimate), that seems to still be widely accepted.

However, I have never read anything that suggests that photon collisions would lead to annihilation. Is there a reason such might be the case for {anti-,}neutrinos?

In C, control flow like if, for, while, do, else, etc., take the rest of the line of code (i.e., till the next semi-colon) and runs it under the conditions of the clause.

braces—{}—allow you to take multiple lines of code and have them be guarded at the same time rather than having to repeat the condition. GP is taking advantage of the fact that the next for clause will be considered a single statement, and therefore the second set of braces are not technically needed.

However, omitting braces for single-line snippets has caused plenty of havoc in the past (cf. Apple's gotofail). Some would say it is better to always include braces in control flow.

This is a nice little idea; I’m cleaning it up for my own use under Linux, and I’d like to release it, but I cannot seem to find a license declaration for Ted’s code.

Anyone happen to know what license it was released under?

First of all: thanks! I'm excited to read this!

Second of all: ugh! Dear HackerNews team, please fix your URL matching algorithm so it doesn't include <> in URLs; they're actually explicitly recommended by the URI RFC as delimiters.

Sincerely,

halosghost

Actually, though I deeply enjoy grsec and pax, I find it to work just fine with Arch. I have definitely considered gentoo hardened though; the notion of being able to rebuild everything exactly how I'd like it is pretty damn tempting. Thank you for the recommendation; everytime someone gives me a serious recommendation for Gentoo, I always have to take a moment and give it a more serious thought :)

I would love to see this make it upstream. I use PaX/grsec under linux and one of my favorite things about them is that they try to enforce w^x.

Unfortunately, a ton of programs break this policy (seemingly for no benefit). Having upstream firefox respect w^x anyway would mean I could remove its exception under PaX and a whole class of possible security flaws just GoAway™.

Ideally, I'd love to see Linux embrace w^x generally, but the kernel devs do not seem terribly interested in that. Either way, keep up the rockin' work OpenBSD team!

Edit: Oh wait! The patch for this is actually upstream! This bit of news is OpenBSD enabling it! That's awesome! /me tries to rebuild firefox with the patch enabled.

My point was that this particular article doesn't tie-in with the others and instead focuses on this specific case rather than taking this case as an instance of the larger problem and driving the issues with the larger problem home.

(Perhaps I was not as clear as I should have been either, doh!)

The title and major thrust of the article is that ebooks are generally bad. The real point only made at the end though is that they aren't, they're only bad when corporations and DRM are in-control.

Imho, if they had been clearer from the get-go that the problem is DRM, not ebooks in-general, it would be much more powerful.

This is one of those things where the FSF has the completely correct idea, but has accidentally pointed their finger at the wrong culprit. The problem here is not e-books, it's DRM. The article even says as much at the bottom. I completely agree with the whole point of this article but wish it had used this case as a further tie-in to the various other articles asserting DRM's horrible. I think that the use of the specific case with specific examples to draw into a larger argument is often more effective than continuing to just point the finger at the single instance of the problem.

That's a good question. He is under the impression that it's actually scanning them, but I honestly don't know (I am aware that the mapping data would be much easier to accomplish).

Absolutely. Like I said, I'm only aware of that feature being informational; I have no information regarding its use in the autopilot mode :)

Actually, my dad has a Model S and one of the coolest features is that it actually does scan for speed limit signs and tell you the current speed limit on the dashboard (you can configure a limit over the speed limit for when this should show up).

Now, I have no idea whether or not this feature is utilized for autopilot (though I would kind of assume it would be), but it is there :)

On the one hand, this looks incredibly cool. On the other hand, I actually find it a bit worrying. With things like BadUSB[1] still out there, I would be worried about anything that gives USB devices more wide reach or higher privileges.

That this project aims to offer "full functionality" of the device, afaik, means it is likely doing exactly the kind of thing that I find worrying. Can anyone talk about this a little more in-depth?

[1] http://www.youtube.com/watch?v=nuruzFqMgIw

(2013)

Yep, this project depends on youtube-dl[1] (which is an awesome tool anyway, so if you don't have it already, you should consider grabbing it regardless).

[1] https://github.com/rg3/youtube-dl

I'd love to see this make it into F-Droid! Fingers crossed!

> Just because you're wealthy enough to not do the dirty work means you're somehow above the DP, but poor people who can't should get the DP?

This is actually not a good argument at all in-favor of the death penalty for this person but rather another great argument for its elimination entirely.

Continuing my streak of posts regarding preference which likely apply nearly only to me[1], I will gladly take on this question! As with the others, I should reiterate that I am a niche user and that the things I want will likely not be wanted by everyone else.

1. Terminal-only (^Z is still something I want/need)

2. Not ncurses (as much as I like ncurses and what it did for TUIs, it's got too many pain points and short-comings to make sense lately).

3. Configurable/Extensible/Scriptable through the host language or one DSL (i.e., allowing a ton of different languages for plugins (I'm looking at you vim, ಠ_ಠ) is a SadTime™). Given this and (2), I would be tempted to say I'd prefer this editor to be written in Haskell and use Brick[2]; there is at least one editor that attempts this [3].

4. Incredibly stripped-down core functionality with officially maintained extensions for likely-to-be-wanted features (e.g., syntax highlighting). This is not because I don't want syntax highlighting (I definitely do), but rather the recognition that one size does not fit all and that making the whole system as configurable as possible is often a huge win. Note, this cannot be done at the expense of performance (which is why I would be tempted to say that accomplishing this sensibly would require (3) be accomplished through the host language (and that it would add another strong argument for Haskell)).

5. Modal (One of vim's greatest triumphs is the brilliance and simplicity of function in modal editing—yes, it's a very odd concept when you're starting out, but it's irreplacable once you get used to it)

6. Asynchronous (One of vim's greatest failings is an interface that is completely incapable of dealing with asynchronicity)[4]

7. Some or all of what Gary Bernhardt mentions in "A Whole New World"[5] (great talk anyway if you haven't seen it). Particularly, layers and a flexible auditor.

---

[1] https://news.ycombinator.com/item?id=10072796

[2] https://github.com/jtdaugherty/brick

[3] https://github.com/yi-editor/yi

[4] http://geoff.greer.fm/2015/01/15/why-neovim-is-better-than-v...

[5] https://www.destroyallsoftware.com/talks/a-whole-new-world

First of all, good for atavist. They recognize their market, and are following the path of greatest efficiency and effectiveness. Sounds like great business sense to me.

Now, on the other hand, I have to say, this kind of thing always bums me out. For a news distribution service, it does not matter so much I suspect, but in-general, the trend of putting more and more of the functionality I rely on daily into a web browser is distressing. Web browsers, despite all the innovation and work that has gone on lately, are still an enormous attack surface with the most significant likelihood of security breach (especially given that the rise of javascript has led us all to the point where we are almost allowing arbitrary code execution from untrusted sources on every page visit). Not to mention that web browsers were founded on the notion of conveying content, not functionality; HTML is a markup language (with <canvas> and JS and HTML frameworks, that's not so concrete anymore), it was not meant to host alternatives to the power of native applications.

I often find myself wishing for the ability to use a text-based web browser and have "The Web" still work, but those days are mostly long-gone[1] till I finally get around to writing my own browser[2] (which seems like it should not be a necessary step just to be able to interact with a simpler Web).

I suppose I am just tilting at windmills at this point (and, as I said, this post is not really aimed at atavist since I think content-delivery is a perfect niche for being web-only). Ah well, a user can dream, I suppose…

[1] https://www.youtube.com/watch?v=r38al1w-h4k

[2] https://news.ycombinator.com/item?id=10072796

I completely agree. In general, the only warnings I get on my code anymore are ones related to how a library I use does something. In those cases, I surround those particular library calls with no-warn pragmas for that particular warning and then I go about my day. It feels so much cleaner.

When I first saw the announcement, I was really annoyed since I am a PTS backer. But, with the offer they're giving so that I can test out the new one, I'm pretty okay with it afterall. In fact, given that one of the reasons driving my decision to get the PTS was the ~10-day battery-life, I do not suspect I will even consider the PTR; but I love that Pebble was self-aware enough to offer me the choice.

Good work Team Pebble! Keep on rockin'!

This! I religiously use clang's -Weverything -Werror. Does it mean I spend more time dealing with false-positives? yes (though honestly, not that much). Does it also mean I end up writing much better code? yes, absolutely.