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

> That’s not to say that there is no microplastics pollution, the U-M researchers are quick to say. > > “We may be overestimating microplastics, but there should be none. There’s still a lot out there, and that’s the problem,”

Good news with a note:

> That’s not to say that there is no microplastics pollution, the U-M researchers are quick to say. > > “We may be overestimating microplastics, but there should be none. There’s still a lot out there, and that’s the problem,”


And with some actual numbers, when digging in further:

> They found that on average, the gloves imparted about 2,000 false positives per millimeter squared area.

> Clough prepared the substrates while wearing nitrile gloves, which is recommended by the guidance of literature in the microplastics field. But when she examined the substrates to estimate how many microplastics she captured, the results were many thousands of times greater than what she expected to find.

The reason this is important is that one flawed dataset reports a hopeless situation; the other at least provides a “if we stop now” message.


Be honest, did you just reply to the title and the title along even skipping the other comments?

I opened the article and read the first paragraph. Then skimmed the rest.

As others pointed out: the fact you can do this in CSS tells you everything you need to know if you consider what CSS is for. Even w/o ever looking at the spec or understanding how it came to be.


i don't see what you mean? it's a rendering technology

i guess if you're someone still stuck on the "web browsers are for displaying static documents" and "css is for prettifying markup" thing, then sure, I bet what you said sounds real witty


> There has been a somewhat fast "fsync" library built around Linux's futex

The article actually goes into that in quite a bit of detail about that.


Yeah but to the commenter I was replying to, I don't think it was clear that detail was relevant to the benchmark numbers they were quoting.

I mean, that is not what they are writing buddy.


AMD has very decent drivers on Linux which are even open source. It is one of the main reasons people recommend people go with AMD cards for Linux.


It really should be illegal. Companies aren't going to do it themselves as it is a huge potential revenue stream.

So much so that it effectively has become the main focus of some companies who we as consumers still perceive as online stores/marketplaces. Specifically sponsored search results apparently can become a bigger income stream than the one from actual sales themselves.

Which is great for these companies, terrible for us consumers.


It's one thing to enforce contracts but another for government to dictate how private platforms monetize their own property. If ads make the service worse, the answer is competition and exit, not government bans. No one is forcing you to use these platforms.


That argument ignores the reality of the current market structure. The "competition and exit" theory only works when valid alternatives actually exist.

Right now, we are dealing with effective monopolies and duopolies. You can't just exit the App Store if you have an iPhone, and Amazon has cornered the market so hard that switching isn't really an option for most people. When competition is dead, the market can't self-correct because consumers have nowhere else to go.

Also, "monetizing their own property" is doing a lot of heavy lifting in your take. These platforms already charge: transaction fees, commissions, listing fees, higher product prices baked in, and in many cases consumers are paying directly (Prime, app purchases, ride fares). Injecting ads is basically double charging. On top of that it shifts the platform from "help me find the best match" to "whoever pays the platform wins".

Honestly, unless you are in a C-suite role, I'm not sure why you would defend a model that actively works against you as a consumer.


Don't forget the tradition of having to migrate to a new API after a while because this one gets deprecated for "reasons". Not just a newer version, but a complete non backwards compatible new API that also requires its own setup.

To be fair, that might have changed in recent years. But after having to deal with that a few times for a few hobby projects I simply stopped trying. Can't imagine how it is for companies making use of these APIs. I guess it provides work for teams on otherwise stable applications...


> One could argue whether Phones with the Google android were ever really open.

In recent years, you can argue that android has no longer been open. In the early years of Android that argument would be much harder to make. To be clear, I am not talking hardcore FOSS libre open. But meaningfully open for the end user to do what they want on their device without much restriction. Early android didn't have sandboxing, had no permission system, was easy to root, etc.

Certainly with Nexus devices you had pretty much the freedom to what you wanted.

Could it have been more open? Sure, but I feel like it is almost disingenuous to say it was never if we are comparing it to the real world situation we find ourselves in today.


Early android did have sandboxing and a permission system. It's just that you had to accept all permissions on app install. (Which is still a lot better than common practice on the contemporary desktop.)

That didn't make the system less open though. The user gets to make an informed (or not) choice.

What was different is that the Play store back then was basically a free-for-all. There was no meaningful approval process. This did contribute to making the system as a whole more open, but at a cost...


I am surprised nobody mentioned the curse of knowledge: https://en.wikipedia.org/wiki/Curse_of_knowledge

It is actually a fairly well known phenomenon, certainly in educational circles. Being aware of it when you are writing any form of documentation is a first step. But even then, it is very difficult to properly assess the knowledge entry level of your audience.

Having others read through your documentation and importantly work with your documentation is a good strategy.

One thing I can also highly recommend is simply start out with a list of assumed prerequisite knowledge in your intro. Specifically things like certain environments, frameworks, etc. Bonus points for not only listing those but also linking to the documentation for those.


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

Search: