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

I've tried hard to remove phthalates from my life. The biggest change that I feel is sustainable is looking for "hard" plastics. Usually phthalates are found in flexible, soft plastics. So hard plastics typically have less of them.

What do you mean? This looks like open-source


Only the app, not the server and by all indications it won't be free.

While I admire the work of hobbyists it still looks like C/C++ will be the default until a GPU vender makes the decision to support these libraries.

From my understanding, Vulkan and OpenGL are nice but the true performance lies in the specific toolkits (ie CUDA, Metal).

Wrapping the vendor provided frameworks is liable to break and that isn't tenable for someone who wants to do this on a professional basis.


I don't quite get this comment.

This is supposed to be used in place of CUDA, HIP, Metal, Vulkan, OpenGL, etc... It's targeting the hardware directly so doesn't need to be supported as such.

The site also seems to clearly state it's a work in progress. It's just an interesting blog post...


They also miss that on CUDA's case it is an ecosystem.

Actually it is C, C++, Fortran, OpenACC and OpenMP, PTX support for Java, Haskell, Julia, C#, alongside the libraries, IDE tooling and GPU graphical debugging.

Likewise Metal is plain C++14 plus extensions.

On the graphics side, HLSL dominates, following by GLSL and now slang. There are then MSL, PSSL and whatever NVN uses.

By the way, at GTC NVIDIA announced going all in with Python JIT compilers for CUDA, with feature parity with existing C++ tooling. There is now a new IR for doing array programming, Tile IR.


The Zig compiler can compile C, though.


By this logic, most software engineers would also be considered high risk since they work a sedentary job and have higher risks for heart disease and obesity (which likely leads to higher healthcare costs over the long term)


I wonder how those compare to something like this: https://developers.google.com/optimization/service/schedulin...


Wow, the smugness of that reply. Responding by calling someone naive and blowing them off despite there being real questions.

The “insecure crypto “ that they clearly link to (despite not wanting to put them on blast) was also a bit overdone. I guess we all are stuck hiring this expert to review our crypto code(under NDA of course) and tell us we really should use AWS KMS.


AWS KMS is great product branding. I've never seen another company so accurately capture how it feels to use their product with just the name before.


It's also just a profoundly good product. If you can use KMS, you should.


Always be suspicious of any acronym with a ‘K’ in it, just on general principle.


There are some weird attacks against KMS that I think are possible that are not obvious. For example KMS has a mode where it will decrypt without supplying a key reference (suspicious!). If an attacker can control the cipher text then they can share a KMS key from their AWS account to yours and then control the plaintext. I haven’t confirmed this works so maybe my understanding is incorrect.

Also, with KMS you probably should be using the data key API but then you need some kind of authenticated encryption implemented locally. I think AWS has SDKs for this but if you are not covered by the SDK then you are back to rolling your own crypto.


Unironically, the superior tone likely has done you worse than a single joint.


No argument here, I'm definitely judgmental on this stuff. I probably shouldn't be, hence why I said that my hatred was borderline irrational.

That said, I still find potheads completely insufferable.


> That said, I still find potheads completely insufferable.

In all fairness, they may find you equally insufferable. And to think, you’re not even a pothead!


Probably true. I just noticed a strong delta of before and after when my friends in high school would get into weed.


I hope I didnt come off as flippant or discounting your experience. I just more meant that its likely due to the differences that led you both to where you were, that the feeling is mutual. And that neither of you would be "wrong" for potentially feeling that way. Just different streams I suppose :)


All good!


imo Datadog is pretty hostile to OTel too. Ever since https://github.com/open-telemetry/opentelemetry-collector-co... was nearly killed by them I never felt like they fully supported the standard (perhaps for good reasons)

OTel is a bear though. I think the biggest advantage it gives you is the ability to move across tracing providers


> the ability to move across tracing providers

It's a nice dream. At Google Cloud Next last year, the vendors kinda of came in two buckets. Datadog, and everyone trying to replace Datadog's outrageous bills.


Pretty sure Datadog is literally one of the top contributors to OTel.


I worry that vision is not going to become reality if the large observability vendors don't want to support the standard.


FWIW the "datadog doesn't like otel" thing is kind of old hat, and the story was a little more complicated at the time too.

Nowadays they're contributing more to the project directly and have built some support to embed the collector into their DD agent. Other vendors (splunk, dynatrace, new relic, grafana, honeycomb, sumo logic, etc.) contribute to the project a bunch and typically recommend using OTel to start instead of some custom stuff from before.


They support ingesting via otel (ie competing with other vendors for their customers) but won't support ingesting via their SDKs (they still try very hard to lock you in to their tooling).


Yeah their agent will accept traces from the standard Otel SDK but there is no way to change their SDK to send the traces to anyone other than Datadog when I last checked a couple(?) of years ago.

I mean I understand why they did that but it really removes one of the most compelling parts about Otel. We ended doing the hard work of using the standard Otel libraries. I had to contribute a PR or two to get it all to work with our services but am glad that's the route we went because now we can switch vendors if needed (which is likely in the not too distant future in our case.


Is the author a lawyer? I imagine we will he seeing more posts like this in the future. I doubt the language will ever be good enough for everyone.

Rust doing these things has lead the language to being an example of what not to do in OSS.


Not only is the author not a lawyer, they freely admitted on reddit that they don't understand legalese or trademark law well.

Unfortunately they've succeeded in convincing people there is an issue here when there is no issue.


Any suggestions for a 101 introduction to random forests? In university I encountered some ML courses but never random forests.


Statquest is really good. Maybe a little basic if you’ve taken ML courses, though?

https://youtube.com/playlist?list=PLblh5JKOoLUIE96dI3U7oxHaC...


My book, Effective XGBoost, covers tree theory from stumps to decision trees, to bagging (random forests) to boosting.


Grab any ML book and read the chapter on random forests. If you have the maths background (which is not particularly high for random forests) which you should if you took ML courses, it’s all going to be pretty straightforward. I think someone already mentioned Hastie, The Elements of Statistical Learning, in this thread which you can download for free and would be a good start.


Yeah I did a deep dive on them here -- doesn't require any particular math background beyond high school: https://www.youtube.com/watch?v=blyXCk4sgEg


Consider applying for YC's Summer 2025 batch! Applications are open till May 13

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

Search: