> Are knobs and plastic moldings that expensive though?
Yeah, the molding for any typical single component is tens of thousands of dollars per iteration. A car has a lot of those components, so the fewer the better.
I don't believe yet another package manager is going to fix anything, more likely it'll take years to reach maturity, will be riddled with bugs until then, and have some serious fundamental issues on its own that will be revealed down the path, if it ever gains popularity.
Don't fix it if it aint broke should be a motto for more developers. Settling for good enough prevents second system effects and retards immaturity in the form new "trendy" products that over-promise and under-deliver solutions.
Nothing is perfect, but replacing something from scratch because of some mostly irrelevant issues that would be better handled by improving the standard solution usually just causes more issues than it solves.
I think 100% of these issues are irrelevant in practice, 99.9% of the time. Sure, there was that "left-pad" thing one time. Sometimes NPM is down briefly.
Otherwise, it's all ideology. Some people make money off of other people's work. NPM could turn evil. I don't care, at least not at this point. Wake me up when it becomes an actual problem in terms of "getting work done".
I also disagree with the characterization that NPM really "owns" or "controls" anything. If they did something really bad, they could get replaced fairly quickly. Therefore, it's unlikely they will.
1) it takes really long to get a replacement of the ground (it's gonna be riddled with bugs etc)
2) wake me up when it's an actual problem
To me it seems like these two don't coexist well.. if it has become a "real" problem (whatever that means) then it'd appear that it'd already be too late to build a replacement solution, in your own logic.
> 1) it takes really long to get a replacement of the ground (it's gonna be riddled with bugs etc)
I never actually said that. It shouldn't take that long to get a package manager going. Also, there are already "alternative" package managers out there that one could switch to right now, should the need arise.
Most JavaScript-related threads I see on HN feature at least a handful of comments from people who will avow that e.g. the npm ecosystem is hot garbage. Seems to me that it is broke and needs fixed.
Works fine for me. Could be better, but 'broke' is a strong word for something I use heavily, daily, with very few problems. Of course HN users love to complain that the npm ecosystem is full of junk, but that's like complaining that most websites are junk. Just learn to find the good ones. Learn to identify high quality packages. Run it by someone more experienced if you're not sure. And if you really can't find a decent quality package that fulfils your requirements, then that's probably a sign your requirements are specific, so roll up your sleeves and write some code.
> Most JavaScript-related threads I see on HN feature at least a handful of comments from people who will avow that e.g. the npm ecosystem is hot garbage.
It's not the "NPM ecosystem" that's hot garbage, it's the Javascript ecosystem. There's a culture of creating micro-packages that have dozens of of often trivial transitive dependencies. With a lot of popular projects, one "npm install" dumps maybe hundreds of packages and thousands of files into a "node_modules" folder that you can't reasonably move out of your source directory. There's also a culture of breaking interfaces and configuration a lot. Many developers growing up in this ecosystem think this is the "normal" way to do things, thus compounding the problem for "future generations".
None of this has anything to do with NPM or the company that runs it. Some of it has to do with NodeJS, which isn't the same as NPM . Another package manager wouldn't solve any of these problems. In practice, NPM works fine 99.9% of the time. That's "good enough".
The main issue with it is that it's too good and successful, therefore it's too easy to publish whatever crap as your library or its dependencies.
That's not really a fault in the tool managing installation and publishing the library, its dependencies or managing the repository, providing the auditing system, script runner frontend and the other things npm does.
You could similarly argue github is hot garbage, because there are so many crappy projects hosted on it.
That's a fault of npm - _the registry_'s policies, not of the package manager. You could do the same with most other popular package managers if you have control over the registry.
I'm not quite convinced by their federated approach though. It feels like its just spreading out the problems, and not really preventing them from happening, and in the worst case even creating new ones.
As pointed out in the talk, running a registry becomes expensive once it becomes popular. So now instead of 1 central registry (which I agree is not a good idea) needing to fund the hosting, you have maybe 10-100 federated registries, with each one of them needing to fund the hosting and coming up with different economic models around it.
I'm also not sure how they would really be able to ensure immutability of packages in a federated system. A node could simply publish two different packages with the same name and version number to different parts of the network. Yes, you can reduce the impact by saving an integrity hash in a lockfile, but npm already does that today.
> It is the fault of the tool though if previous versions of a package are mutable, indeed deletable.
The package-lock.json contains hashes to verify integrity.
For legal reasons, you can't really have packages that are immutable or undeletable. In practice, that's just not really a big deal.
Also, how do you solve the problem where a maintainer hands over control of the repository to some malicious actor? What if a maintainer gets hacked? Ultimately, you'd have to audit every single release of every package.
Again, despite those theoretical risks, despite the fact that Javascript projects often have thousands of dependencies, it all works out okay in practice.
That's what I was about to say, that the current state of JavaScript package management is "broken" in certain aspects. The dependency on a private organization for open-source packages makes no sense.
I think it's a healthy sign that we're starting to see more npm alternatives, decentralized package management protocol/standards. After some churn, may the best ideas win!
Probably worth it, since he got a MacBook Pro a year earlier than everyone else. For the rest of us, the MacBook Pros (started as the short-lived Core Duo models) weren't available until spring 2006. The Core 2 Duo models didn't exist until late 2006.
Then I most likely have the timeframe wrong. It was RIGHT when the Core 2 Duo came out. It was just the MacBook though... not a Pro. November 2006 sound right?
Completely irrelevant, yet amusing: At a former employer, we had access to what can only be described as unlimited supplies of hydrogen.
This led - in addition to lots and lots of eardrum-splitting workshop pranks - the occasional kids' party balloons being inflated with hydrogen. (As it was free, which He definitely isn't. HS&E be damned.)
A then colleague of mine claimed they'd cracked a window and caused instant panic at his son's birthday party when a bright spark decided to put a balloon to a lit candle to show the other kids it'd pop.
I doubt the cracked window (given a standard party balloon is pretty small - and a cracked window would likely mean lots of -ahem- eardrum deficiency in the assembled crowd) - but I can imagine it got the kids' attention all right when the balloon more or less exploded.
(We did crack a couple of windows in the workshop, though - you'd be amazed at the bang a litter bag filled with a hyd/ox mixture can produce if set alight.)
I guess - never having tried the party balloon trick myself - that such a small amount of hydrogen will mix well enough with the surrounding air as the balloon pops to create a (modest, at least) bang as the mix ignites, but this is just conjecture.
Maybe I'll have to do some empi research one of these days - we do have a few bottles of oxygen and acetylene in the workshop at my current employer.
Hey ho, time for an engineer to pay our welders a visit.
So how about the plurals of some words ending with "us", like fungus-fungi, but virus-viruses-not-virii and how about dingus-dingii-or-dinguses, doofus-doofii-or-doofuses and so forth?
Chickens can perform short flights, but from my limited observations it seems like the stamina is the main limiting factor for them. They've however clearly evolved from fully flight-capable birds, but the now-extinct Moa however might have been a different story: https://en.wikipedia.org/wiki/Moa
Oh, yes, there are evolutionary dead ends, but e.g. the Moa (or even the Dodo[1]) basically evolved for really long without any evolutionary pressure towards avoiding "enemies" and thus was stuck in a local optimum with no way out.
Still ~25 seconds of sustained flight, just about the record for a chicken, I think seems like not-evolutionary-dead-end-enough to my untrained eye. :). YMMV.
[1] AFAIUI, it was humans that ultimately drove it to extiction, but it could have been any invasive species that would kill bird-like thigs. Maybe I'm wrong on that.
Not only does materials overall matter little, but Lithium is also super cheap compared to the other materials in the batteries. There's a lot more of Nickel in a Li-Ion battery and it's much more expensive per volume and weight as well.
The batteries would be called Nickel-Carbon or something like that rather than Lithium-anything, if they were named by the amounts or costs of materials in them.
I'd also say a large part of its issue is lack of internal consistency of the format itself. Firstly there are the various official RSS versions, then there are all those Atom things and probably others as well, and then there's the thing about how you're supposed to render the things correctly. XML as the content format is also pretty much antiquated.
A modern format would no doubt have to be JSON- or YAML-based and have its human-readable content in plain text or markdown, so it'd have to be pretty much readable with a plain text http client, like curl.
So, just let RSS die the slow death it's been going through for good reasons and bring something consistent and straight-forward into its place. Something that you could easily generate and parse from any modern language without specific libraries.
Bringing RSS back is like trying to bring SOAP as a RPC system back; it just won't fly anymore no matter how much hot air you try to pump into it. We know better now and have better ways to do the things.
