LKML: New syscall: leftpad()(lkml.org)
lkml.org
LKML: New syscall: leftpad()
https://lkml.org/lkml/2016/3/31/1108
73 comments
This is the second april fool's post. I dread the next 24 hours.
I hope tesla's model 3 is not april fool's!
We're way past the second at this point. Let's just hope we make it through.
Please don't start this. April 1 is extremely tedious.
Stay offline. It's fun for us.
upvoted for solidarity.
As a longtime OpenBSD misc reader, it took me a few minutes before I became convinced that the OP was joking.
And just like that left-pad.io is cut out of the market. Man, startups are cutthroat these days, but that's business for you.
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.
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.
They can compile a unikernel with this single function, even.
Another unicorn dying.
It must be a bubble.
Let's wait for HN resident economists to tell us about it.
It must be a bubble.
Let's wait for HN resident economists to tell us about it.
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.
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
Wow, this blows left-pad.io's whole business model. Wonder what they're going to use their VC millions on now?
EDIT: Here's an idea: Monetize your padding by putting ads in it.
EDIT: Here's an idea: Monetize your padding by putting ads in it.
Pivot to right-pad.io
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.
Middle out padding. It just might work
Deterministic Random Padding is the way of the future: http://play.golang.org/p/m4he0blGL5
Need to make it a package so other code can depend on it though.
Need to make it a package so other code can depend on it though.
https://lkml.org/lkml/2016/3/31/1125
Somehow, this just makes it better...
Somehow, this just makes it better...
> As everyone knows, within the kernel everything is faster and better.
> Leftpad has millions of users, so it has to be as fast as possible.
Flawless logic.
> Leftpad has millions of users, so it has to be as fast as possible.
Flawless logic.
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.
Since this is such an important system call, I am sure we will see it in the kernel in the next release.
Let's see how far we can ride this joke. I see next step as being an ASIC for leftpad.
Hardware accelerated leftpad anyone?
Hardware accelerated leftpad anyone?
PADL AL, 1hPeople who have never looked at golfed x86 assembly language probably don't realize how close this is to reality.
https://reverseengineering.stackexchange.com/questions/2774/...
https://reverseengineering.stackexchange.com/questions/2774/...
You could make PADL an alias for SHR I suppose!
Someone in acedemic pickup and publish a paper on realization of the algorithm with quantum computer
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.
For more context:
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.
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.
While the joke is relatively amusing, it would be better to seem more useful solutions contributed to the ecosystem like depscheck [1] for Go.
[1]: https://github.com/divan/depscheck
[1]: https://github.com/divan/depscheck
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!
Days since a stupid leftpad joke
0
0
seldom have I seen april fools day won this early!
It's been going for quite a few hours at this point.
This is doesn't help all of the JavaScript developers on OS X.
This really makes node a first class citizen of linux. I am sure moving node modules to the kernel will greatly increase their speed. :)
I propose that facebook() be put into the public kernel
For the secret* kernel that is known only to us, facebook () should be replaced by hn().
For the secret* kernel that is known only to us, facebook () should be replaced by hn().
What was that random comment about how Linux dosn't break userland Abi . Was this a early April l fools joke ?
The message is dated as Apr 1st. At several places it's past midnight already.
Whoosh!
https://xkcd.com/1627/
I think you added an "H"
I think you added an "H"
The "whoosh" spelling is older than xkcd.
Swish
This is actually amazing :D
And so it begins :)
We need an orthogonal `rightPad()` as well to be complete.
No, silly, you just reverse the string, leftPad, and reverse the string again.
1 APRIL 2016 00:33.... 'nuff said people.
I hate to spoil the fun for everyone.
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.
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.
"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.
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.
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.
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.
> But there is actual value
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.
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.
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.
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.
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.
npm != unix, don't conflate the two.
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.
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.
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.
Which is - no matter how big the packages are - a huge problem.
> 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.
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 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.
left-pad not a BUILT IN language primitive --- NON-STARTER!
Dammit people!
http://www.xent.com/pipermail/fork/Week-of-Mon-20091109/0545...
Dammit people!
http://www.xent.com/pipermail/fork/Week-of-Mon-20091109/0545...