Is it too much to hope for Linus to either wholeheartedly endorse this patch, or (preferably) eviscerate it for not being implemented well in some way? That would really be the icing on the cake.
I propose center padding. Why does the padding need to be at the end of the word? That's just an artificial limitation imposed by the rent-seeking incumbents in the padding industry.
But there is actual value in doing things the npm/unix way.
Just yesterday I used a module to turn numbers to comma separated strings 10000 -> 10,000
Could I have written a function to do it ?
Sure
But every less line of code I need to write saves me time.
Programming is fundamentally a creative field ( which means there is no absolute truths ) - and each individual developer should be given the freedom judge when to write code and when to use other's people modules.
I would say that this whole fiasco just proves how awesome programming has become - remember the days when adding a dependency was hell ? Now we live in a world where adding dependency has so little cost that we rather not even spend 10 minutes writing a function.
To me its an improvement over the state of affairs from the past.
Its also cheaper to switch dependencies - imagine if the leftpad disaster was somewhere in the window's kernel ? or in std:: ?
There is always trade-offs in every decision you make in software - I think we are moving in the right direction.
"But there is actual value in doing things the npm/unix way."
This is where the node community falls down.
They think because there is value in sometimes doing it this way, there is always value in doing it this way.
Rarely is the right answer for architecture/programming/etc at one of the extremes.
The left-pad debacle is not an indictment of small dependencies. The problem would have still happened even if left-pad were a 10,000-line dependency, if that 10,000-line left-pad was as popular as the 10-line left-pad was.
The issue was that authors in the npm ecosystem could pull their packages and cause havoc. Copying code is a partial workaround for this problem for small dependencies only, but the problem should be solved at the npm level--and once it's solved there, the virtues of copying code go away.
I don't buy your argument that "the virtues of copying code go away" in any way, shape or form. It seems somewhat arrogant to me to think that people have spend decades on software engineering approaches to these kinds of issues, but y'all think "yeah, we solved that, no problem!".
But I'm not going to argue this further. I guess time will tell.
This doesn't seem responsive to my argument at all.
I'm speaking from experience with a package manager that was specifically designed up front to avoid the left-pad issue (before left-pad even was a thing). In that environment, dependencies, even small ones, are great. With an overrides feature and lockfiles, you get all the benefit of copying code (ability to hack on it, responsibility for updates, reproducible builds) without the hassles of copying code and trying to stay in sync with upstream.
Copying code isn't something you have to spend decades to invent. Rather, I see it as giving up on proper package management. There are coherent arguments that package managers aren't worth it (though I disagree with them), but I don't agree that it's arrogant to try to build package managers that scale up and down, any more than any attempt to use software to solve an engineering problem is arrogant.
> Additionally: The core problem wasn't the existence or the reliance of dependencies. But simply the fact that the package was no longer available.
Which is - no matter how big the packages are - a huge problem.
This really misses the point. Every dependency is its own point of failure. When you explode your dependency tree into 1,000s of individual dependencies, you vastly increase the odds of something going wrong.
Making package publishing immutable won't save you. What happens when the dev of one of those 1,000 packages you rely on has his or her account hacked and a malicious point revision is pushed? Even if you pin all your dependencies, do all your 1,000 dependencies pin all of theirs?
Micropackages like left_pad and is_array had hundreds of dependent packages and a tiny handful of watchers on the repo itself. The NPM community is lucky that the first major consequence of their micropackage-insanity was only a brief outage.
> The core problem wasn't the existence or the reliance of dependencies. But simply the fact that the package was no longer available.
I figure the social dynamics bundled with a micropackage model matter. If you have a few big packages with lots of owners, central dependencies are less likely to be deleted by unanimous consent of owners than the same software divided up into many packages each with a single owner.
I think the reason people felt it was silly is that there is a whole library (a tiny one, sure, but still a dedicated library) for that one function. If there had been a left-pad function in a larger utility library that everyone was using, nobody would have thought it was silly.
Why would a larger utility library would have been better?
Replacing a big dependency is much more difficult. If the reason is "because now a lot of dependencies could dissappear/change" then that's an argument against the npm inmutable history issue and not modularity.
But every less line of code I need to write saves me time.
How much time did you take to find the code, read the documentation for it to make sure it does exactly what you need, did you budget time for the future when it doesn't work exactly as you wanted and you'll have to either find another module or fix it yourself, etc.?
If it's something nontrivial (e.g. SSL/TLS), then it certainly makes sense to reuse. But if it's trivial, then the overhead can be far greater than the savings.
Of course, the definition of "trivial" varies greatly depending on the skill level of the programmer.
OF course there's value. There is also a cost to adding another dependency.
> But every less line of code I need to write saves me time.
It saves you time now. The recent left-pad brouhaha is a very good example of how it can also waste a lot more time. This focus on only the initial development time without any consideration of the maintenance cost always creates problems in the long-term.
Maybe this attitude is popular with programmers on short contracts that won't be around to maintain the project? It sounds plausible, but I'm not sure. At a minimum this shows the human tendency to be very bad at evaluating risk.
The bar for publishing needs to be higher because there is too much broken, incomplete shite out there. Usually because they just pushed the internal quality, undocumented, untested garbage they just wrote. Don't test arguments, don't set constraints. Tag on a sentence of hurried description, done.
I don't understand the half-assed mentality that does that. That's how one makes the world a worse place, not a better one.
It was only natural. I propose a POSIX extension with a new signal type: SIGLPAD. You know, for on demand left-padding by the user. Because user choice is important
The consensus estimates on left-pad.io’s [LPAD, -0.57%] fiscal 2016 earnings per share and revenue have come down sharply compared to estimates, with ongoing softness within the padding family of functions pushing many analysts to the low end of their guidance.
Actually this is an opportunity for left-pad.io. Previously they had to maintain custom code, but now they can interface through to the kernel which is much faster and allows them to scale.
Many people are on older kernels and might not be able to upgrade, or for convenience or other reasons simply prefer to use an api for their critical business logic.
left-pad.io was shortsighted from the start, everybody knew that, but nobody in the echo chamber wanted to admit it. Now that left-pad.io's unicorn chances are all but smashed, perhaps we can look forward to SF rents finally coming down!
For context ioctl is considered this ridiculous grab bag of a syscall that people overload (abuse) rather than add new syscalls. Used a lot for a lot of things, but the literature doesn't speak highly of it.
ioctl means "We made this object's API file-like, but there's something we need to do with this object which we can't express in terms of the normal file operations."
Setting terminal options is a classic use of ioctls: You have a file descriptor which connects to a terminal or, more likely, a pseudo-terminal, and now you need to ask the user on that terminal for a password. By default, the low-level code will echo every character back to the user, so they can see what they just typed, but that's insecure for passwords, so you need an ioctl to tell the low-level terminal handling code to not echo.
Plan 9 removed some of these warts, but it's hard to see a fully, truly elegant way to handle something which is mostly-file-like but has some un-file-like attributes programs need to frob.
73 comments
[ 2.9 ms ] story [ 147 ms ] threadThis one was awesome though.
Hardware accelerated leftpad anyone?
https://reverseengineering.stackexchange.com/questions/2774/...
> Leftpad has millions of users, so it has to be as fast as possible.
Flawless logic.
* Or until the kernel revokes your programming license.
Somehow, this just makes it better...
EDIT: Here's an idea: Monetize your padding by putting ads in it.
Need to make it a package so other code can depend on it though.
But there is actual value in doing things the npm/unix way.
Just yesterday I used a module to turn numbers to comma separated strings 10000 -> 10,000
Could I have written a function to do it ?
Sure
But every less line of code I need to write saves me time.
Programming is fundamentally a creative field ( which means there is no absolute truths ) - and each individual developer should be given the freedom judge when to write code and when to use other's people modules.
I would say that this whole fiasco just proves how awesome programming has become - remember the days when adding a dependency was hell ? Now we live in a world where adding dependency has so little cost that we rather not even spend 10 minutes writing a function.
To me its an improvement over the state of affairs from the past.
Its also cheaper to switch dependencies - imagine if the leftpad disaster was somewhere in the window's kernel ? or in std:: ?
There is always trade-offs in every decision you make in software - I think we are moving in the right direction.
Just need to make package creation immutable.
This is where the node community falls down. They think because there is value in sometimes doing it this way, there is always value in doing it this way.
Rarely is the right answer for architecture/programming/etc at one of the extremes.
The issue was that authors in the npm ecosystem could pull their packages and cause havoc. Copying code is a partial workaround for this problem for small dependencies only, but the problem should be solved at the npm level--and once it's solved there, the virtues of copying code go away.
I'm speaking from experience with a package manager that was specifically designed up front to avoid the left-pad issue (before left-pad even was a thing). In that environment, dependencies, even small ones, are great. With an overrides feature and lockfiles, you get all the benefit of copying code (ability to hack on it, responsibility for updates, reproducible builds) without the hassles of copying code and trying to stay in sync with upstream.
Copying code isn't something you have to spend decades to invent. Rather, I see it as giving up on proper package management. There are coherent arguments that package managers aren't worth it (though I disagree with them), but I don't agree that it's arrogant to try to build package managers that scale up and down, any more than any attempt to use software to solve an engineering problem is arrogant.
Which is - no matter how big the packages are - a huge problem.
This really misses the point. Every dependency is its own point of failure. When you explode your dependency tree into 1,000s of individual dependencies, you vastly increase the odds of something going wrong.
Making package publishing immutable won't save you. What happens when the dev of one of those 1,000 packages you rely on has his or her account hacked and a malicious point revision is pushed? Even if you pin all your dependencies, do all your 1,000 dependencies pin all of theirs?
Micropackages like left_pad and is_array had hundreds of dependent packages and a tiny handful of watchers on the repo itself. The NPM community is lucky that the first major consequence of their micropackage-insanity was only a brief outage.
I figure the social dynamics bundled with a micropackage model matter. If you have a few big packages with lots of owners, central dependencies are less likely to be deleted by unanimous consent of owners than the same software divided up into many packages each with a single owner.
How much time did you take to find the code, read the documentation for it to make sure it does exactly what you need, did you budget time for the future when it doesn't work exactly as you wanted and you'll have to either find another module or fix it yourself, etc.?
If it's something nontrivial (e.g. SSL/TLS), then it certainly makes sense to reuse. But if it's trivial, then the overhead can be far greater than the savings.
Of course, the definition of "trivial" varies greatly depending on the skill level of the programmer.
Dammit people!
http://www.xent.com/pipermail/fork/Week-of-Mon-20091109/0545...
OF course there's value. There is also a cost to adding another dependency.
> But every less line of code I need to write saves me time.
It saves you time now. The recent left-pad brouhaha is a very good example of how it can also waste a lot more time. This focus on only the initial development time without any consideration of the maintenance cost always creates problems in the long-term.
Maybe this attitude is popular with programmers on short contracts that won't be around to maintain the project? It sounds plausible, but I'm not sure. At a minimum this shows the human tendency to be very bad at evaluating risk.
The bar for publishing needs to be higher because there is too much broken, incomplete shite out there. Usually because they just pushed the internal quality, undocumented, untested garbage they just wrote. Don't test arguments, don't set constraints. Tag on a sentence of hurried description, done.
I don't understand the half-assed mentality that does that. That's how one makes the world a worse place, not a better one.
0
It must be a bubble.
Let's wait for HN resident economists to tell us about it.
Many people are on older kernels and might not be able to upgrade, or for convenience or other reasons simply prefer to use an api for their critical business logic.
[1]: https://github.com/divan/depscheck
ioctl means "We made this object's API file-like, but there's something we need to do with this object which we can't express in terms of the normal file operations."
Setting terminal options is a classic use of ioctls: You have a file descriptor which connects to a terminal or, more likely, a pseudo-terminal, and now you need to ask the user on that terminal for a password. By default, the low-level code will echo every character back to the user, so they can see what they just typed, but that's insecure for passwords, so you need an ioctl to tell the low-level terminal handling code to not echo.
Plan 9 removed some of these warts, but it's hard to see a fully, truly elegant way to handle something which is mostly-file-like but has some un-file-like attributes programs need to frob.
I think you added an "H"
For the secret* kernel that is known only to us, facebook () should be replaced by hn().