Hacker Newsnew | past | comments | ask | show | jobs | submit | benwr's commentslogin

Maybe IQAir? They do have paid plans, it looks like.


I have an IQAir monitor, but their whole system seems like a PurpleAir copycat. Right now, most of the data on their maps comes from PurpleAir sensors, and it's likely that it's PurpleAir that doesn't care for that.

That said, IQAir is kind of crazy to me. They launched a new dashboard which has a "view as TV dashboard" button, but doesn't let you click it unless you upgrade your plan. The local data access situation is also unclear to me; I bought the sensor after reading that it has a Samba server, but it requires the indoor monitor to display the password to you. I opened a support case to get the password for local analysis, but am beginning to feel like they're not going to give it to me. (Who wouldn't want an indoor air quality monitor? Well I already have one. I've cared about indoor air quality forever, but after wondering for two days why the sky was a weird shade of yellow, I wanted to keep an eye on outdoor air quality as well.)

In that case, it will be UART time. It's definitely Linux running an out-of-date unpatched Samba. Won't be at all difficult to get my data, I'm guessing. The question is... why do they think there's money in a cloud service that shows you dashboards of your own data? They should be bending over backwards to accommodate anyone that wants to contribute to their public site; they are way behind PurpleAir there.

TL;DR I'm certain that PurpleAir is the unnamed company in this article. IQAir is too new to be relevant in the space.


This comment saved me from just ordering a IQAir outdoor monitor. Great timing. I'd like an outdoor unit that supports PoE (which the IQAir monitor has) because I'm definitely not going around replacing batteries all the time, but that seems hard to come by, so I might have to give up my attempts at measuring air pollution from the side of my house.


Yeah. Send me an email if you want the outcome of my support ticket or attempts to hack the device.

Ignoring the software, the device itself is great. Two sensors compare their outputs to figure out if it's valid or not, and the case seems quite protective from the elements (and easily mounted to my weather station pole). I didn't need POE, I have AC out there, but overall it's a good way of supplying power to something like this.


Sure, I'm not saying it's unreasonable.

The big selling point of `soanm` is that you don't need to have anything extra installed on a typical distribution (not even ssh!) and you don't need to know any extra configuration language, or how to use a special library, or anything beyond shell scripting. Of course, you also trade a lot of functionality away: The programs you write aren't declarative, and so on. But personally I don't care about that when provisioning a new dev machine. I'd much rather just run some quick scripts.


Interlingua is a similar project for primarily Romance languages: https://www.interlingua.com/interlingua-en/


Entropy of a single password isn't actually a well-defined concept; entropy is always about a distribution. "Entropy calculators" that look at your password and tell you "its entropy" are making assumptions about how you chose the password.

We care about the distribution from which you drew the password, because that lets us analyze how difficult it would be for an attacker who knew your password selection process to brute-force the password. Just knowing the password itself isn't enough information to determine that (though of course you can judge how hard it would be for an attacker once you know their brute forcing strategy).


I mostly agree, but I do find myself choosing a new FDE and login passphrases about once a year, and I wish that I could choose these using something like Diceware, but memorable enough that I wouldn't need to write them down at all. Thinking about how I might do that is what ultimately led to this post.


Login, like for your local computer? Why rotate those?


More often for e.g. work computers.


This is a fair question; I've been thinking about "weird" password choice strategies recently, for which it can matter. For example, if you want your password to be an English sentence, choosing sentences based on random parse trees will produce duplicated sentences with ambiguous parses.


I've done a fair bit of research into this, and as far as I can tell, the entire internet does this thing you've never seen. For example, https://en.wikipedia.org/wiki/Password_strength#Entropy_as_a... implies the use of Shannon entropy.


[sigh...] +1, though you're making me feel d*mn old.

I won't tell you what decade it was, when I found that some "bright" user had picked his/her own office phone # (10 digits, 2 hyphens) to use as a "high security" password.

My own mental model - with a decent compression algorithm, and compression dictionary pre-loaded with popular passwords and personal information, how many bits would the specific password in question compress to? That also catches the clever folks who pick stuff like "abcdabcdabcdabcd" or "3.1415926535".


If anyone is interested, I've been trying to think about the problem of moving ranges in a list-structured CRDT for a couple of weeks now for a side project, and I've got a candidate that seems to satisfy the most obvious constraints. I'd be really interested in any feedback / holes you can poke in my solution!

Rough notes are here:

https://docs.google.com/document/d/1p1K3sxgKGYMEBH72r-lnP9Gn...


This is interesting! I've been looking for a good sequence crdt to implement in my Rust CRDT toolkit [0], which is still very much a work in progress but I want to make it really useful. Do you know how this compares to yjs [1]?

[0]: https://github.com/anchpop/crdts [1]: https://github.com/yjs/yjs


I hadn't looked at yjs; I'll check it out! [edit: It looks to me like yjs is much more flexible than my design here, but doesn't include an ability to move ranges of lists to different locations]

Darn, and just after I'd implemented it myself in terrible beginner Rust! I might get started reimplementing it using your tool :)


The title seems totally unsupported by the article to me. A less misleading one might be "The 'sharing economy' has evolved into a collection of large, unregulated, rental businesses"


The sharing economy was always fron day 1 about rentals. That's the central premise.

What's deviating from the original concept is that barriers to entry are restricting supply to the point that providing a service becomes too profitable and actually pays off to provide it full time.

Consider Uber. The principle behind ride sharing is quite simple: if you're already driving somewhere you can help someone out by sharing your ride with someone who wants to go where you're going. Cars are already clogging the roads while operating at 1/5 of their capacity. So, why not give someone a ride and be rewarded for your efford? Except that regulation bars individuals from doing just thay, and thus so-called rideshare companies are actually taxi companies.


Sure - I still think the title is misleading. "Was always a scam" implies that everyone in the sharing economy has been lying for decades in order to make money. I don't see any evidence presented in the article that supports that implication.

And when looking at it through a reasonable lens as you do in your comment, I also don't understand the urge to treat it as though "sharing economy" companies are somehow evil or deceptive. They're just responding to market conditions in a way that (at least in the short term) produces value for both drivers and riders. There are other arguments you can make about whether this is bad in the long term due to e.g. dynamics around regulation, but that's an argument about how things will play out in the future, not about past or current bad faith on the part of Uber or AirBnb.


>The sharing economy was always fron day 1 about rentals. That's the central premise.

If I may, the central premise is about being middle-man in a (renting) transaction, shaving off a fee from it for the service of establishing a contact between the two parties and - optionally - provide ancillary services (again at a cost for either party involved in the transaction).


You've just defined a business transaction. Being paid for providing a service is not the central premise, and completely misses the whole point.

The central premise of sharing economy is that people have access to resources, whether they are goods or services, that are underused or even wasted, resulting in an unnecessarily high level of economic inefficiency. Thus if a system is set to encourage those who have the resources to make them available to potential clients for a fee then everyone involved wins. A key concept is to set a centealized service which handles the hard part of a business such as transactions, business models, and disputes.


Well, that is exactly what the "businesses" revolving around it are doing.

Offering in your words a "centralized service which handles the hard part of a business such as transactions, business models, and disputes" cutting a fee from the value of the transaction.

The point of disagreement between our opinions only revolves around that service(s) being the "hard part" of the business and about the actual amount of the fees involved for these services.

Anyway a line needs to be drawn between an actual "sharing car" approach, as an example we have here blablacar where someone already has to go from A to B and offers a ride to recover some costs and something like Uber and Lyft, here the driver is going from A to B only because the customer(s) needs to go from A to B.


This is a critical response to https://news.ycombinator.com/item?id=18609375 ; in the comments is a response by Jamie Farnes, the author of the paper, and a rebuttal by the blog's author.


To clarify, the response and rebuttal benwr mentions can be found in the comments on the blog post, not in the HN comments from the previous thread. :)


I have absolutely no idea who is right, but I don't see why Dr. Hossenfelder is being so patronizing? In her rebuttal in the comments she says

>Trust me, I do not enjoy doing this, but I do not want false claims to spread in the popular science literature.

The only way to stop popular science lit from misinterpreting/aggrandizing scientific findings and publishing what eventually amounts to false claims would be to just never publish anything provocative at all...and then they'd still probably find some BS to publish. I don't really see why such reasoning would prompt this response for the paper.


> I don't see why Dr. Hossenfelder is being so patronizing

This is her personality. I don't think it's productive to resolving scientific disagreements and don't endorse it; she looks obnoxious in contrast to the author's polite reply in the comments. But it's definitely her natural state, and it seems to produce a writing style that readers enjoy.

> The only way to stop popular science lit from misinterpreting/aggrandizing scientific findings and publishing what eventually amounts to false claims would be to just never publish anything provocative at all

Hossenfelder is claiming much more than that the work is provocative. She's claiming it's highly disfavored for widely known reasons that the authors do not sufficiently address. She's probably also implicitly suggesting the authors are allowing their work to be marketed directly to the lay public, who do not have the expertise to assess the work, for personal gain. Obviously you can always give alternative explanations (the establishment is close-minded, or whatever), but keep in mind that Hossenfelder is waaaay outside the establishment.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: