Hacker News new | past | comments | ask | show | jobs | submit | lawl's comments login

mindustry allows you to still get the game on github, you just don't get steam integrations. i think that's pretty fair.

However, even if that wasn't the case i think it would be fine. If I contribute to a BSD licensed project, i shouldn't be mad if someone ends up selling my code.

So as long as the license permits it, I think it's generally fine. Otherwise, what's the point of the license?


The difference between stores and repositories is the ability to add your own sources that you may or may not trust, making it not a walled garden.

(And yes, that does make snaps a walled garden)


This is a great point regarding walled garden vs repositories with respect to choice.

The original point though was implying repositories were better because they are trusted.

However if choice allows trusting a new repository you just came across, choice similarly is fine to trust an .exe from the internet too.

Not advocating for random .exe installing BTW. But honestly, for 99% of what we do we make trust choices based off Reputation and Probability guesses for outcome. We mostly don't have a clue what the executable code will do exactly.

In this case, I have a hunch that a well known repository is likely not to feed me malware. But I also figure that VLC/7-zip/notepad++ probably won't either. So will happily download their .exe. And I don't want anyone removing that option.


Theyre pretty easy to DIY. Just look up a video on youtube of some kid doing it. Thats actually a lot more dangerous because now you run the risk of them doing it improperly and having batteries explode.

None of the things you need to DIY a vape can be controlled because its all common of the shelf stuff used for many things.

The only thing you can control is nicotine. And i can also order it from china, and the chinese always forget to label the concentration correctly or mention it at all.

So, i think this wont stop kids, but might stop adults from switching to vaping. Because nicotine free vaping is impossible to effectively ban, trivial to DIY. And the nicotine part that you can try to control (e.g. india does) is only really interesting to existing smokers, but also: chinese labeling.

Last but not least, i'm not sure i would have ever went and gotten a prescription. Probably not. The extremely low barrier of entry and ~100x cheaper were important factors for me.


The addictive part is the main issue. People don’t smoke for 30 years because it tastes good, and I don’t think vapes are any different.

I don’t think kids would ever DIY non-nicotine vapes enough to cause a public health crisis. Kids could have huffed Halloween fog machines in the 90s but they didn’t.


Vapes are very different. Im speaking from experience. Switching from smoking to vaping is way harder than quitting vaping.


I don't doubt that. What I'm saying is that, if health concerns with vaping is justified because it's safer than smoking, then it makes sense as a cessation product. But that's not the way they're currently marketed, regulated, and sold. But, being "safer than smoking" is not a justification for hooking a new generation of consumers who didn't previously smoke.


I disagree.

I have dealt with bugs that were thought to be fixed a long time ago, only for them to mysteriously pop up again later. Ticket is created and the old ticket is linked.

It's really helpful to see what was done 2 years ago, including the attempted fix that is now still live in the code base but apparently doesn't work properly.

That said, as always, it's not black or white. There are definitely cases where it doesn't make sense, but I don't think you should call it 'totally worthless'.


But they host the software, you already have to trust them.

This threat model just does not make sense.


The user has to trust the business no matter what. Even if the chat was e2e encrypted, the business could just choose to share the messages with somebody else.

This use case is more for the business, who knows that the chat is hosted by a 3rd party, but is reassured that the 3rd party wont have access to messages.


The point is that the host can modify the code at will and can therefore access the messages if they wanted to. It defeats the idea of e2ee which is to make it impossible for a middleman to access the messages.

With e2ee you have to trust the client. But a client that is running as a website hosted by someone else can't be trusted as the host can modify it and you'd never known because browsers don't have a way to alert you when a site changed.

The only way this makes sense is if you (or your business) self-hosts.


Another option is for the business to host the (open source) chatbox themselves, but the messages are stores and routed through a 3rd party. The chatbox is probably just a plug and play component that can be embedded in any page, and hosted statically by the business. Much easier than self hosting the entire messaging infrastructure.

This is one of the major benefits of having an open protocol like Matrix. The clients are separate from the servers. People with more resources and more expertise can host the servers, while regular users just need to download an open source client, and they can rest assured that the messages are secure.


There are other considerations though aren't there? Assuming that you trust the hosting entity:

* You may not want to trust the hosting entity for all of time. If you trust that E2E is deployed now, then you don't have to trust the future version of the host

* You may want additional protection against the host database being compromised. If you trust that E2E is deployed then a compromise of the host would not mean anything for your users privacy


The software = chat box? Could be hosted by yourself, too


I would expect most people spend most of their time at home and at work, so that doesn't really surprise me.



Ugh, way to overdo it... #444 is WAY too low contrast.

If black is too dark, I'll reduce the contrast of my monitor myself, so can y'all please stop trying to force me to squint to decipher your gray-on-gray oh-so-beautiful but unreadable text?



Maybe I'm misunderstanding the intended scope of this engine, or I just ran into a bad result page, but:

https://beta.sayhello.so/search?q=Java+aot+compile

Does not seem to mention graal anywhere. (It's just a random test query that popped into my mind)

Asking a full question for a code snippet seems to work: https://beta.sayhello.so/search?q=How+do+I+sort+a+map+in+Jav...

How do you deal with licensing for these snippets though. Is that up to the user to verify?


Because we're currently built on top of Bing's index, we're somewhat dependent on the raw pages they provide. If those pages don't mention graal, neither will our AI. Building out our own index is something we're working on.

It is currently up to the user to verify licensing for the snippets, but we try to make it easy (using the See Reference button) to go to the original source.


Thank you! The "See Reference" makes it much easier to comply with licenses, than GitHub Copilot.


I don't necessarily buy this and am too lazy to look deeper into it. But I like your attitude, good luck.

Edit: where is this 6% number coming from? https://ourworldindata.org/ghg-emissions-by-sector

Chemical & petrochemical (3.6%): energy-related emissions from the manufacturing of fertilizers, pharmaceuticals, refrigerants, oil and gas extraction, etc.


1. Incredible line.

2. That 6% is based on the most recent IPCC report which estimates 1.4 GT from HFCs, and another ~1.4 from CFCs+HCFCs, so 2.8 total. OWID seems to get its data from climatetrace, I haven't dug into their data, but if I'm reading that correctly it looks like that is only energy usage from manufacturing, rather than direct emissions of the gases. Looks like maybe this breakdown just ignores refrigerants, which is unfortunately common.


> Be honest - did you write an overcomplicated piece of code that was super hard to understand?

Not the person you asked but I have definitely done that. Usually writing overcomplicated code means you don't understand that particular domain/tech well enough and there may be no one else around to ask.

Half way in you realize you took the wrong approach. Now you have the difficult decision of sunk cost a fallacy here or not.

The correct answer may not be obvious, sunk cost isn't always a fallacy. I have definitely made wrong decisions here in the past and wrote bad code.

But sometimes the decision is ship something or nothing?


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

Search: