310 karma · joined May 8, 2012
NPM does a great job of distribiting development dependencies and Node.js applications.
It's not really intended for non-js binary builds and platform-specific dependencies.
You can always use NPM to install directly from specific repo release but you'll still have to have to include a native compile-to-platform step somewhere.
Then why is paper still the overwhelmingly preferred medium?
Using hypertext it would be trivial to link to an external source describing the specific concept used from linear algebra.
Not providing supporting links is only good for an audience that holds the entirety of mathematical knowledge in their heads (ie mathematicians in academia).
The rest of the world, incl those who have since moved on like the author, don't fit into that category.
Therefore, the work can only be accurately read and understood by the tiny minority of specialists capable of decoding the intent of the work.
Limited reach = limited value to society.
Is the intent of a PHD really to advance the field of mathematics? Or is it just another 'measuring stick' for individuals to prove to others how 'smart' they are?
Getting a math degree just to be able to fill in the gaps created where 'it trivially follows' is equivalent to being required to memorize the API for a framework because clearly defined documentation is hidden behind a paywall.
so called 'intellectual power' has little to do with it. What you're describing is familiarity with navigating a minefield of poorly structured information and tapping a academia (ie at a very high cost of entry) for 'special access' to resources that bridge the gaps.
Of software development suffered from the same informational constraints and lack of innovation, we'd still be playing pong.
Artificial ripening just accelerates the natural process so I wouldn't be surprised if it can be appplied to organics too.
It seems to be especially hard to find good tomatoes in stores, organic or not. Tomatoes become bruised/damaged very easily during shipment. Customers don't buy bruised product so I think supermarkets have responded by offering more dense but less tasteful varietys.
If taste is your concern, growing your own is the best option. If you buy in stores try the smaller varietys and the ones that feel softer to the touch.
Therefore, their work is paet of the public domain and can't be copyrighted or licensed. Period.
It's the law...
If somebody is claiming copyright to public works and/or limiting access for money, they should be publicly shamed out of existence.
If one party or politician wants to logroll additional policies/amendments that work against the interest of the people, the records should permanently reflect their sleazy actions.
Campaigns shouldn't be about PR and a candidates ability to BS people for likes. Their commit history should reflect their true stance and impact on policy.
Not all free software is free.
As for project-level management of external dependencies the tooling can be used to provide a facade for imports. I'm not sure about Webpack but JSPM already does this using a config.js file that maps all of the dependencies to readable import names, sans version numbers so the site doesn't break on future updates.
Ideally, once ES6 modules are used more widely it would be great to see libs start to adopt the facade pattern to provide finer granularity of control without deep linking into a project's source.
The shift to a flat dependency hierarchy in NPMv3 will make managing dependencies of dependencies much more explicit and straightforward to manage.
JSPM already uses a flat structure and shows how simple dependency management can be.
I'm not sure what you mean by "the dynamic nature of the tooling". The JS development ecosystem doesn't attempt to provide an end-all-be-all monolithic core lib. It's a good thing and one of the primary reasons why advances in the JS evosystem are happening at breakneck pace.
https://github.com/systemjs/builder/pull/205
ES6 modules allow devs to easily specify and import only the parts of a library that are being used. The bundler takes care of pulling in the necessary parts. No magic required.
Classic case of NIH syndrome.
I worked at an outdoor produce stand when I was younger. I've been to a number of distribution facilities where fruits/vegetables are bought in bulk.
For the more expensive produce that goes to grocery stores, they use artificial ripening chamber to make the fruit look ripe on the outside while they're nowhere near ripe on the inside. It guarantees a good looking product that has maximum shelf life.
For other fruits, like strawberries. They're massive size is what contributes to the poor quality taste. Selectively breeding to produce maximum output has a bad effect on quality.
Vegetables become bitter when they get old. Supermarkets have gotten better at keeping vegetables looking fresh for longer but old tastes old, period. Anybody who has never had veggies fresh from the garden has no idea how good they can taste.
Everything about the modern supermarket focuses on presentation over quality. Even the produce section is strategically placed next to the entrance to give shoppers an impression of freshness and vibrance.
It's all for show, keeping consistently full bins of fruits/veggies means a lot of product will go to waste and the supermarket needs to use every means possible to extend the shelf life as long as possible.
A much more realistic, albeit messy setup will look more like Walmart. There will be bins that are nearly empty, variations of quality, size, condition, etc. Real produce (ie not the plastic sold in supermarkets) is sometimes messy, dirty, ugly. You don't buy it for how it looks, you buy it for how it tastes.
If you want really good tasting produce, buy from a produce stand. They can't afford refrigeration and long-term storage so they buy the cheaper and better tasting produce.
One of the benefits of prior experience working on flight simulators is I actually have practice landing 737s (testing is fun).
Talk to the control tower, request a runway for approach. Dial in the navigation station to the specified ILS beacon. Pray to god there's no cross wind. Decrease speed @ 5-7 nautical mi range and switch flaps to 20 degrees. Watch the ADI for the cool little runway indicator to popup when the runway is in range (the analog ones are especially cool). Drop landing gear. Adjust approach to stay within one dot on the horiz/vert glideslope indicators. Land. Reverse thruster to slow down. Steer and brake using the foot petals.
The change in flaps is necessary to increase lift @ slower speeds and slightly upturn the nose on landing for that nice rear-wheel-first touch down. Do not attempt to land @ 0 degrees flaps. I've done it before in a 747-400 sim while testing the EGPWS, "you're doing it wrong" callouts. It only took the 5 tries to hypothetically not crash and die.
If you're in an Airbus, 'land' mode is the equivalent to 20 degrees flaps because European pilots aren't smart enough to understand geometry.
Useful tips:
Don't wear yourself out fighting the yoke, the little up/down triggers on the yoke will adjust the trim to compensate for wind and/or resistance. Pitch/roll on the yoke, yaw with the petals. Don't manhandle the yoke, a light touch is enough. Avoid roll on approach. Use yaw to compensate for wind. It's better to be slightly above altitude than touch down short of the runway. If the first approach sucks add power and go around.
Aside: I totally probably forgot something critically important.
There's a whole wide world of people and businesses that could benefit from software.
From an outsider perspective, it looks like they're preoccupied with putting out fires.
The flat organizational structure, absent strong leadership, has allowed some bad actors to manipulate there way into positions of power/influence within the organization. The CEO and driving force of the organization from its outset has been ejected after making the mistake of fraternizing with his employees. The new CEO lacks the leadership and strong personality required to take up the reigns with the current structure. A culture that was established to be inclusive is being leveraged by a malicious outspoken minority to achieve the opposite; which is causing a lot of backlash internally and externally. The public perception of the company is in free fall. Most, if not all of these issues present a legal and/or financial threat to the future of the company.
In short, GitHub's open and informal culture has become a liability.
It takes an established record of misbehavior to legally justify firing bad employees. Especially, those who will use their 'protected' status and public support to attack GitHub after being fired. I'd be willing to bet that their lack of organizational structure has left them without justification/protection and they're scrambling to make up for it.
To protect their investment, the wise thing to do would be to build some management hierarchy; which they're doing by pulling in all of the leadership from remote positions. They need to shield the current CEO from any more mishaps. They'll follow by establishing a record of poor performance for the outspoken assholes. Eventually, when they've established sufficient justification they'll eject the toxic individuals from the organization.
GitHub will emerge a mature and stable but less friendly/open organization. Hopefully, this doesn't negatively impact GitHub's willingness to support OSS.
"Do they actually want all those large open source projects to leave?"
Absolutely not. To ensure GitHub has a future, they have to fix the present.
-----
What we may be witnessing is the hastening recovery of an organization that experienced a systematic failure.
They'll survive... Not before shedding some blood.
Establishing an ATO for end user systems, specifically hardware/software that is intended to connect to the military tactical networks comes with a very high barrier of entry.
Being an OCCFLD made up of media specialists (ie photographers, videographers, illustrators, reproduction specialists); they have requirements for hardware/software that fall outside the generalized platform/support provided by G-6.
Overwhelmingly, they prefer Apple/OSX but building Apple-based systems that support the wide range of security scanning, observation, and auditing requirements simply isn't possible. AFAIK, nobody has established a baseline for Darwin and the cost/risk to do so within the schedule of the systems lifecycle is too high. As a result, Windows is only option.
The systems I supported directly included laptops running a custom configuration (ie Adobe, etc) as well as tactical deployable media production studios that provide print, media, large format, networking, and archival capabilities in the field. At one point we added VLC (ie due to it's superior playback format support) but had to nix it after discovering that it had a CAT I CVE.
Things may be different outside the DOD but for the USMC specifically, MITSC are the 'gatekeepers' for the Marine Corps when it comes to establishing an ATO baseline and meeting the requirements for ATC (Authority to Connect) to the MCEN-N (ie unclassified tactical network). Frequent scans, remote access, and auditing aren't recommendations so much as an absolute baseline requirement. Don't get me wrong, they do their job very well.
When it comes to fielding COTS systems, lifecycle sustainment is a huge problem. Depending on Windows based systems and Dell Enterprise networking hardware makes the problem much worse. Unfortunately, that's what everything is standardized on and systems that can't be bought with a long-term support contract are no-go. Diverging from the standard is a recipe for failure.
I didn't deal with the ATO process directly. Instead, I provided field support, user feedback, and maintenance of the systems.
I established a distribution channels and did my best to provide periodic updates to all the systems within my AOR to meet the requirements of the ATO/ATC. I even spent months trying to hack the bureaucracy -- with little success -- to get the systems connected and operating at their full capacity.
Throughout that process I discovered numerous missing prerequisites buried among a morass of policy and documentation. I'm no stranger to reading dull/dry specifications but the literature surrounding ATOs and their application is a minefield. One misstep can lead to the loss of certification so it's wise to be cautious.
I tried to raise the issue with my superiors but as the saying goes, 'shit flows downhill'. It's not really their fault, they don't know what they don't know. I've learned not to take it personally, life of a contractor in the field is one where you'll inevitably (and hopefully infrequently) accept fault for failures beyond your control.
What really bothers me is that the Marines have to go forward with limited/degrading technical capabilities and little/no support. No amount of effort, willpower, or policy will solve significant technical problems that require technical solutions.
-----
Just to be clear, the following isn't specific to COMCAM. If anything the leadership I had the privilege to work with made an exceptional effort to always do things the right way, despite some of the ridiculous barriers we had to face. This is based on a wider perspective gained from working with many organizations across many military installations.
The DOD doesn't suffer from technical debt so much as technical poverty. Any benefit I had from being good with technology going in became a weakness. The military is a black hole of communication and information sharing. Don't get me wrong, it was an amazing opportunity to 'level up' my people skills but seriously...
I often see people complain about rampant waste and the lack of transparency in government and the DOD specifically. I can honestly say from first hand experience, it doesn't come from lazy or malicious behavior. When limited time/resources restrict decision making to a gray area between doing things the 'right way' and accomplishing the mission, it's the duty and responsibility of our service members to choose the latter. Waste and opaque behavior is a symptom of systematic failure (ex lack of knowledge, communication, unnecessary bureaucratic barriers, etc) at a much grander scale.
I probably have a unique perspective. I went in with no prior military background and a strong technical background. The former makes it very difficult to accept 'broken' as norm, the latter provides a unique perspective of what can be done to fix it.
-----
I'm a huge proponent for OSS, having contributed and/or authored many projects. From what I've seen, breaking new ground and introducing OSS to the DOD on a larger scale is currently beyond reach.
There are pockets of exceptionally talented/capable individuals with the technical background required to make it possible. Except, they represent an extreme minority and are already over-taxed with supporting the existing systems. I'll spare you a the diatribe on why the alternatives consistently come up short.
I have read all of the literature 18F has to offer (except a few blog posts). 18F sets a very good example for others to follow. Unfortunately, the platform is limited to internal use and the organization's capabilities are limited to serving the latest 'hot button' issues within the DC political spectrum.
Much like SV represents an extreme monoculture fueled by exceptional technical ability and a flood of VC funding. DC represents its own extreme monoculture fueled by the concentration of power/influence and a flood of taxpayer funding.
Beyond the bubble the state of things is much messier, broken, and in need of help.
One difference is that the SublimeLinter for ST3 doesn't come packaged with language-specific linters. Instead, they're separated into their own packages. This may be a 'pain point' if you're switching but I consider it a good long-term design decision on the part of the SL devs.
By 'general purpose' I mean the baseline configuration that all non-POR (Program of Record) systems use. Ie, hardened Windows, MS Office, security monitoring, CAC authentication, and DOD certificates. There's no chance in hell that the 'general purpose' configuration will ever be changed to include OSS because it's intent is to be the 'lowest common demominator' of connected systems.
This person probably works as a grunt for the AF branch equivalent of G-6.
The COTS systems you're referring to are POR (Program of Record) systems created and supported by the product development branch. I think for the AF, it's the Air Materiel Command. They fall outside the scope of general systems support, therefore they require their own infrastructure for maintenance/support.
Source: I used to support a POR system.
They largely circumvent a lot of the process with help from policy makers at the highest levels.
Even then, I'm pretty sure they don't offer hosting/authorizing deployments from party sources. So they essentially have a monopoly on the ability to use OSS freely for bulding government websites.
Comparably, a nurse may have a positive impact on a dozen lives over the course of a week. A programmer's contributions may affect thousands or millions and the positive effects compound over time. Even if it takes longer (comparable to other jobs) to accomplish anything meaningful.
Many developers don't overcome the communication barriers with users to realize the impact their work has.
A task that could take somebody 5 hours a month can be automated to take 5 minutes with a program. Package and sell that program to thousands of users and, in terms of reducing operating costs, the software is a cash cow for any business in that domain.
Devs love to get caught up on theoretical minutae, CS fundamentals, testing coverage, methodologies, axe grinding over subjective preferences for frameworks/styling, etc.
None of that matters. Your value is literally measured in your ability to enable others to earn money or save money.
AFAIK, the CIA uses a hybrid setup with the government hosting very large data centers of their own for data and AWS being used to build front-ends that access that data.
It's important to consider the sheer scale of government resources. They run at least one of their own private cloud providers. They're just not accessible to the 'outside' world.
If you can't handle tracking external dependencies that come with battle tested code and relatively well-defined APIs. What makes you think you can do better by recreating all the same functionality as internal dependencies. Unless you have a glut of excess code monkeys to throw at solving problems that already have existing solutions, eliminating dependencies for the sake of reducing complexity is a lost cause.
OTOH, if your goal is to reduce dependency duplication. The problem isn't the code, it's the poor quality package manager you're using. Lately, package managers are switching to flat dependency structures because they solve this exact issue.
If you're worried about managing the uncertainty that comes with dependency updates, lock in the version numbers and shrinkwrap the dependencies.
Keep the link as a reference but it also provides some good quizzes to learn and practice basic concepts. 8 years ago that's where I started learning HTML/CSS/PHP.
Nowadays, cars are more expensive. Insurance is mandatory. Owners are discouraged from doing their own maintenance. Commuting to work only gets worse over time. And, to add insult to injury, gas prices still suck despite oil prices being the lowest they have been in decades.
All of the things that made car ownership fun for young guys is discouraged by manufacturers because they've shifted their profit models to depend heavily on long-term service/maintenance.
If I move close to a city any time soon the first thing I plan to do is get rid of my car. at this point it's just an expensive burden.
With that said. Their consumer apps have always been overly simplistic candy glossed shit, Made worse by the fact that they can't be removed without lower level hacks.
I may not fall with their target demographic but I'd never buy into the platforms/services of a company who won't let me have a choice over something as simple as what Apps I have loaded on my machine.
http://southpark.cc.com/clips/104282/smuggy-san-francisco-to...