The fork? Node.js: Code showdown re-opens Open Source wounds Open source software rarely receives the kind of attention that the press lavishes on the latest hot new thing blessed by Silicon Valley venture capitalists. Yet these projects are the foundations of the web world. Without open source there would be no Slack, no Medium, no Github. Nor would there be Google, Facebook, or much …
Shit, think about this Doug, Microsoft would be the least bad of the players that would be strengthened, and thats saying something. But imagine IE 6 forever, the only reason IE went further was because Mozilla presented such a major threat in the mid-00's.
But imagine a much more powerful Oracle. As well as a non-gutted IBM. Without open source they would likely be more powerful than they would have been otherwise.
Then again, maybe OpenVMS wouldn't be (virtually) Itanic only and have more marketshare, and its probably my favorite proprietary OS so maybe it wouldn't be that bad, but then again thats only one tool whereas with open source there are literally thousands. And if you don't like one (like for me, what people call "Linux" [not the Kernel, kernel's great and so is a great deal of the team that works on it]) you can pick something else (again in my case, FreeBSD) that works just as well, if not better for whatever use case.
"...and then what would we do?"
learn how to code without some 3rd party library?
Seriously, maybe it should wake people up to the *evils* of things *like* 300kb java libraries. Do we REALLY need THIS on EVERY web site? It's worse than an irritation. It's a PLAGUE, or a CANCER. 'Teh Intarwebs' needs an enema.
/me points out (again) I hand-code my html and use '<table>' to format it really nice. Why can't others do this? 1/10 the size, or even smaller, faster loads, faster renders, yotta yotta...
(fortunately, MOST open source is far less trivial, and far more useful, than 'leftpad')
Sure, so how about you vertically centre that line of text next to that image which is on the right, and doesn't wrap around when the viewport gets small?
Have fun with your cross-browser CSS. I've already finished with tables.
Old isn't always bad.
Just because they're old, doesn't mean they're good. Tables are generally agreed to be bad unless you're actually representing tabular data, i.e. what they were designed for. I've yet to meet any web developer in the last 10 years who doesn't advocate CSS, it works fine cross browser unless you target ancient versions of IE.
Using tables you're bloating every single HTML file with presentational info, rather than allowing the browser to cache it once in a single CSS file. If you want to modify your site's design you'll have to edit/rebuild each HTML file rather than a single CSS file.
Tables are also slower to render in the browser since they need to be processed in full before any rendering can begin.
Last but not least, using table tags is actually more long-winded than using divs.
<table>
<tr>
<td></td>
</tr>
</table>
vs
<div>
</div>
tl;dr Shitty code can often be quicker to write but it's a bitch to maintain.
Except you've completely failed to answer my vertical centre challenge and the markup you require is a complete clusterfuck of mangled HTML and CSS hackery that is the total opposite of separating content from presentation logic.
And frankly, given that CSS even contains generated content directives these days, that idea sailed away a long, long time ago.
It's easy enough to use table layouts via css without lying in the markup and having table tags for things that aren't tables. It's certainly messy if you're defining most of your styles with css but some crucial formatting in html. It's about separation of concerns, it's difficult to argue that mixing concerns in better.
The drive towards making HTML describe it's content is a sensible one and putting everything in a table, though quick, doesn't help in this respect. It's certainly shortsighted when it comes to disabled users and alternative rendering mechanisms.
Welcome to 2016.
http://caniuse.com/#feat=css-table
<style>
.tableish { display: table }
.tableish>* { display: table-cell; vertical-align: middle }
</style>
<article class="tableish">
<p>that line of text</p>
<img alt="that image" src="who-gives-a-shit.gif" width="400" height="800"/>
</article>
"Similarly, anyone hosting code on GitHub might want to think about what the transition away from GitHub will look like for their project."
Some projects have made a similar transition in that they've moved from Sourceforge to Github. Maybe projects should voluntarily move every few years, partly to ensure that they have the capacity to do so and partly as a reminder to the corporates that this can happen if the corporates don't play nice.
Git (the open source code management system by Linus Torvalds,not Github the company) is decentralized by design, and it is trivial to move the code itself elsewhere, e.g. Bitbucket or self-hosted, much easier than switching from Sourceforge to Github.
What is harder to replicate is the community. Github's value is from its role as the social network for developers, not from its code-hosting. They cannot afford to antagonize developers. A recent example was when most of Github's Enterprisa sales and Product Management left the company. They were taking the product in directions that caused a backlash from individual developers, and the company opted for the latter:
http://go.theinformation.com/259fbd
Fazal is absolutely right. I've made cost driven decisions to switch between bitbucket, github, and a self hosted gitlab several times in the last year. We are currently on Github currently. Switching it is a bit of the PITA but not the end of the world. You have to deal with reconnecting your CI env and making sure everything is migrated, etc.
I'd just like to put up a little reminder of this article:
When some of the criteria are:
"Says “free software,” not “open source.”"
"Encourages use of GPL 3-or-later as preferred option"
and
"All code sent to the user's browser must be free software and labeled for LibreJS or other suitable free automatic license analyzer, regardless of whether the site functions when the user disables this code."
You have to wonder about the validity of the criteria
And seriously, there are a lot more than 4 code hosting services. And GNU Savanna may be ethical but is horrific to (attempt to) use.
Because I always do what GNU and FSF tell me to. Since they know better than everyone else of course. I can't wait til Hurd finally ships so we can abandon the Linux kernel and force everything over to GPLv3, the best license ever created.
Who needs actual freedom when we can be told what to do by our betters?
(I hope its obvious but I'm being sarcastic)
Yeah, then what? People should grasp that Open Source and control freaks don't mix. While I do sympathize with the left-pad author, ultimately there's no such concept as "deleting" your open sourced-code as long as anyone at all has a copy (and if nobody does, then you really don't matter at all). Conversely, if Github goes "poof" tomorrow, I'll still have the cloned repo on my desktop machine; I guess I'll just look for a different host or whatever - where's the harm?
Moving the repo is easy but what about Travis, Coveralls, etc?
I never use the bells & whistles. Most of the git repos I work on are private and self-hosted.
Issues and pull requests would seem to be more important for open-source projects. I don't know. In practice, I see thousands of them in a few popular repos I track, which just confirms that those projects are hopeless clusterfucks. Is Github making it too easy?
Strictly, open source just means that users can see and/or use the source code if they want to. It doesn't mean that no licence applies or even that no non-restrictive licence applies. Just that there is source code. But it may be still mine and copyrighted and if I decide to take it away, which this bloke did, then I can. Since he could and he has.
Security. The Node Package Manager allows packages to depend on other packages and define a loose dependency rule that allows them to accept minor or major updates in the other package.
What this means is that if hacker were able to compromise a commonly used package and upload it, they could infect any other package or end-product which directly or indirectly depended on it. Node.js is not like Javascript in a browser - it runs with user privileges on the machine it runs on and can do pretty much anything it likes.
There is a way to lock down NPM dependencies - shrinkwrapping. But that is not the default behaviour in NPM and even if it was there is no checksumming of packages to ensure that the version 0.3 fetched this time is the same version 0.3 fetched when the shrinkwrap was made. So even shrinkwrapping isn't a solution. At the very least I think enterprises should not point at the standard npm js repository so if there was a breach they would be isolated from it.
The underlying issue in this case had more to do with how fundamentally flawed Node.js was? It's code namespace being such that a dispute over package name like this was inevitable? I don't use Node.js. As I understand it there is no way to split the namespace by, for example, developer name, project, website, etc. It was just something I heard on another site. Not sure if it's true.
This article no doubt points out the elephant in the room, but the smart corporations largely avoid this by keeping the natives at least content. At least until the platform stops making them money and they try alternate ways to monetize (sourceforge) or just close up shop. Guess it's good thing we have shabby platforms like this to point out just how much of a house of cards the "cloud" is. Not to mention the possibility that these "forks" that presumably have replaced this missing code haven't been reviewed (that's assuming the originals were). It'd be pretty easy to stick some malicious code in at this point in time.
TL:DR Rather than be concerned about tension, I'd be more concerned with building upon solutions that are likely to fail even before they shutdown.
At what point does one stop trusting the libraries used? At what point does one take private copies? At what point would a developer need to start asking questions about the genealogy of the libraries they are using? If you are producing code which only you use, then that is probably fine, but if that code is being baked into an application that is being sold or used by others then this is the sort of thing that will break that application in the future, and one reason why end-users are rightfully wary of downloading updates.
The BSD TCP stack wasn't open source, it was the licensing was too hard so control of it was ignored. DARPA paid for the BSD stack and a fair amount of the BSD project and since the US gov doesn't have the concept of a Crown Copyright, the software was free to use by others. You still needed a AT&T Unix (TM) license to use it but those were free for Universities but a small company would need to fork out over $80,000 for a source license to use the BSD TCP stack on their Vax. There were other TCP network stacks and some of them fixed some of the issues that are still causing problems with BSD influenced stacks today. STREAMS and Plan9 are just a few years younger that the BSD stack while Solaris still uses STREAMS today.
OpenSSL started out as SSLeay and the early versions of that could be used as a drop in for a very expensive RSA library which is kind of odd since the later RSA SSL-C was based on and written by the guys who started SSLeay.
I remember going through the licensing paperwork when we were running the CERN http and NCSA web server but we had DARPA taking care of most of that and covering the bills.
There were others like the ISODE ISO stack, email and general X400/X500 mess that sometimes were public domain and sometimes very expensive to maintain at the same time. I seem to remember that our support for CDC's version of ISODE was only about $50k a year in 1992.
Will you guys stop saying that "all the code that depended on it broke"? It only would stop the package manager from installing or updating that package or packages that depended on it. All it meant was that developers couldn't push out an update unless they had a local repository or didn't update packages depending on it. Yes, it is used in a lot of packages, but it wouldn't have "broken the Internet" by any means. Nothing that was already built would have been dependent on running by that package being in the npm repo, ergo nothing would have stopped working suddenly. It was a minor inconvenience at worst that made Kik look like a corporate bully and the npm people look like shills.
See Joel Spolsky's excellent article on how Microsoft's Excel team was paranoid about dependencies, to the point of having its own compiler:
http://joelonsoftware.com/articles/fog0000000007.html
Much harder and more expensive than promiscuous code reuse, but it does have its advantages.
Thank you for posting that link. Though quite historical time-wise much of what is stated is still relevant today. There is a good after-discussion there too, which lemmings -er- managers thinking of moving to the cloud might like to make their bedtime reading.
At some point in the chain, there is a point where reliance is placed on something that has gone before. Even the compiler that the Excel team built for themselves will have been based on methodologies that were brought to the table by members of the team. Methodologies arguably are layers above coding in terms of abstraction, but they result in code that embodies those methodologies, even though it might not be possible to see that at the assembler code level.
The problem with high-level tools is the ability to continue to use those tools to generate at minimum the same code in the future as it was possible to do yesterday. By knowing and trusting the roadmap of the tools you use today should ideally give you more stability in the future. Flash would be an example of there being a breakdown in such trust. The possibility of hacking code generated by a high-level language at assembler code level in order to maintain it is nil these days due to the complexity of code that is generated.
A package vanishing from a repository is just one of the myriad of types of shit-that's-annoying that I've had to deal with on a weekly basis for the last 10 years. i no longer give a shit about this software politics kind of stuff
There's little recognition of the pain in the ass fragmentation is having on software development. While a Microsoft monopoly would be bad for innovation the complete opposite in which there are 100 shitty forked ways to do 1 thing is similarly bad
Developers wasting time learning how to use the reinvented wheel rather than developing an expertise in a few tools
The fundamental problem exposed by this silly fiasco is the pervasive lack of any kind of software hygiene in much software today. Without the common courtesy of interface management, what is exported and what is imported, and what is expected of all that, this kind of problem is pervasive. This is simply Bad Programming. Look up David Tilbrook's USENIX paper about Software Hygiene from, oh, 25 years ago now.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
