When I first heard of the is-odd and is-even NPM packages I was sure they were a joke, yet there we are: 200K weekly downloads! Publishing the packages may have been the effort of one spammer, but many developers obviously chose to use them - that's the part that boggles my mind.
Well, look at one of the dependents: https://www.npmjs.com/package/handlebars-helpers - certainly a more useful npm package, but by the same author. Seldom do people actually type `npm install is-even` - there's just a jungle of transitive dependencies that can be traced back to one of jonschlinkert's many packages, which then circles back to something inane as `is-even` or `ansi-red`.
I once ran a simple grep in some of my node projects - most of them had a jonschlinkert package in node_modules, certainly not through any (direct) choice of my own.
What is a bit worrying though is that he is an active member and contributor to TC-39. Meaning that this kind of community hostility is very much alive among the people who rule JavaScript.
8 years later and despite much support for the `.node-version` file.
Someone else started using the .node-version file years ago, and because all open source packages won't form a committee to standardize this file, nvm will not support it.
They have a lot of hills. JS Private Properties was another.
Very often when I’m digging around GitHub Issues because of some bug or quirk or insanity in the JS ecosystem (which is often) I see someone spout the worst possible take - often being kind of a jerk about it - and when I look to see who’s responsible, very very often, ljharb’s name pops up. Often.
Dogpiling on someone deep in an HN comments tree isn’t exactly the classiest thing but…never having interacted with him myself, I’ve been harbouring this low-grade antipathy towards him - nothing unhealthy, just a groan whenever I see his name on GH - for years now, and it’s cathartic and almost gratifying, given his prominence in the community, to feel seen like this. Thank you.
I think we as a community really need to have a conversation about ljharb and his role in the future of our industry. If he was only a library maintainer, that would be one thing, we could just move on, find workarounds, alternatives, etc. But his involvement in TC-39 makes him one of our rulers in a non-democratic structure. That makes this different.
To be fair, the ESM switch has been botched beyond compare.
It’s like they didn’t want to become Python 2/3, and then did the absolute worst possible alternative.
It is beyond frustrating that it’s up to individual package authors whether or not their package supports ESM or CommonJS.
And yeah, it’s a pita when one of your downstream dependencies decides to go ESM only, and breaks your entire friggin chain of stuff that depends on it being CommonJS.
I agree. Mistakes were made and migration has been unnecessarily hard. This particular issue doesn’t even affect me. I simply turned off `no-unresolved`. TypeScript handles a lot better anyway (even with jsdoc type annotations).
But what is the issue here is the stubbornness of the maintainer and his unwillingness to accommodate a very sizable portion of his user base. The industry is moving on, and as a TC-39 member he should be aware of where the community is moving as well as show some empathy with his users.
I see, thanks. I guess that answers one question, but raises another: why have his packages depend on more of his packages? If his goal was to be included in as many node_modules directories as possible, and handlebars-helpers was already included what's the point of pulling in is-odd/is-even, too?
Might be this from his GitHub bio “Several years ago, just before my 40th birthday, I switched careers from sales, marketing and consulting to learn how to program” Good way to get more eyeballs…
He could sell rights to the repos and disavow any knowledge of its maintenance while maintaining the link in his own repos. When those sold rights are used to commit some crime he has plausible deniability as anyone else but got a payday. If you try spinning off the subpackage just prior to a sale then it shows some sort of intent.
I did learn one new thing from browsing the is-odd source code: Number.isSafeInteger(n) checks that n falls within the [Number.MIN_SAFE_INTEGER, Number.MAX_SAFE_INTEGER] interval.
...
if (!Number.isSafeInteger(n)) {
throw new Error('value exceeds maximum safe integer');
}
...
Given the lack of integers and my hesitancy to trust modulo for non-integer variables, I don't know if I would trust it. You would need to add some safety checks, but either you create an is_even/is_odd function that has safety checks, or you have to rely on developers adding in the checks anytime the number might have been in close proximity to a floating point number.
Something as simple as this can end up being neither even or odd.
I have not read the source but I had always assumed that this was the lovingly crafted effort of someone who is intimately familiar with the js standard making sure that some hypothetical expression like ![1] is neither odd nor even. Surely the idea that modulo is beyond developers is too horrifying to contemplate.
/*!
* is-odd <https://github.com/jonschlinkert/is-odd>
*
* Copyright (c) 2015-2017, Jon Schlinkert.
* Released under the MIT License.
*/
'use strict';
const isNumber = require('is-number');
module.exports = function isOdd(value) {
const n = Math.abs(value);
if (!isNumber(n)) {
throw new TypeError('expected a number');
}
if (!Number.isInteger(n)) {
throw new Error('expected an integer');
}
if (!Number.isSafeInteger(n)) {
throw new Error('value exceeds maximum safe integer');
}
return (n % 2) === 1;
};
It does some checking the `value` is an integer in the safe range, which doesn't even seem right to me. Why shouldn't you be able to call this on integers outside the save range?
Just want to say I really like the values on your careers page. Compassion and humility, but raising the bar at the same time. (Of course, it could all be complete corporate BS, for all I know, but I'd really like to believe it's not!) It's such a shame you switched from "remote (worldwide)" to "remote (North America)"!
Yeah, as hilarious as this is when it happens to a bad guy the really sad aspect of it, for me, is that their customer service experience is not so abnormal. If it were, most would immediately identify it as fake. Like, counting the numbers of nuts in a photo is a bit much, but we are so used to horrible CAPTHAs now that it's just plausible. Same with the phone menu, etc.
Only 20-and-a-half years to fix that one! In this case it wasn't because nobody got around to it, but because people could not agree on the fix, even though more or less everyone agreed that the old behavior was bad.
There is a browser.warnOnQuitShortcut setting in about:config, that can have it pop up a nice warning and stop you accidentally ctrl+q'ing firefox. I don't know if they've gotten around to making that the default for new profiles. That bug thread is a irritating mess of conversations.
The timeline of this vulnerability might just be the best argument I've ever seen for full disclosure:
2019-09-26 Reported to vendor with POC
2020-01-14 Followed up with vendor
2022-01-24 Publicly disclosed (still no fix over 2 years later!)
2022-01-28 Fix released by vendor
I wonder if the same will happen with this RIGOL oscilloscope vulnerability.
No, the whole point of the original post is that a lot of users see (and use) the option, so that the app's database of personal data is full of rubbish.
I don't think the GP's scenario is realistic. A user would see that their location on the map is wrong before they even get a chance to begin navigation.
Besides, Google Maps already sometimes tells people to drive through roadblocks and locked gates and such (which it isn't aware of), so it already requires the driver to think for themselves to some extent.
XPrivacy was great, but apps would regularly crash when I denied some permissions - so apparently it was not faking data well enough. It got so bad that I would never just click "deny", but always "temporarily deny" first. Then, if the app worked, I would deny permanently. If it crashed I'd have to figure out the minimum set of permissions I could get away with granting.
What are your fees?
Tips at time of donation. You decide.
If payment is required to use a service then that payment is not a "tip" - it is a "fee". Anything over the required payment would be a "tip". This FAQ answer implies that the required payment is zero, which, it turns out, is false.
There is absolutely nothing wrong with charging a fee for a service, but there is something wrong with lying about it.
> There is absolutely nothing wrong with charging a fee for a service
Agreed, but percentage-based fees can quickly become an unfairly large part of payments. I love the idea of this project, but I'd prefer there to be a 5% or X dollars minimum, so that if 5% is more than X dollars, then it doesn't force 5% minimum. If I'm donating $500 to 45 projects, then each project on an even split is getting $11, but thanks.dev is getting $25 even though their service isn't actually in use by my app/service. Seems unfair to me.
My guess is that more than half of that $25 goes to the payment provider (Stripe etc.). Maybe more.
The remaining ~$10 will go to thaks.dev to cover operational costs, administration and other expenses.
I don't expect them to work for free. If you think it's unfair, contact the developers directly to see if you can wire them money (to avoid PayPal fees). If it's too much work, you can pay services like thanks.dev that does the work for you.
Please take more time to read the context. If you read the post that I replied to instead of jumping to conclusions, you will find that you are incorrect
$25 refers to the 5% fee of the total amount ($500) that the site takes. I said that more than half of that fee is used to pay Stripe.
