This is actually quite fascinating (and part of my upcoming book...)
Despite the obvious high/low-level language differentials, people have been managing multi-million-line C code-bases since the 80's. Then again, think of how little the build tooling has actually changed -- instead of fragmenting, you're left with llvm, gcc, make at the core of most compiled software.
JavaScript is the exact opposite with the lowest possible barrier to entry (built-in to every web browser...), and the proliferation of frameworks and libraries may be due to this in combination with the lack of fundamental understanding of design patterns that can scale. Lots of people trying to partially solve symptoms, missing the forest for the trees.
Theoretically there's nothing preventing good patterns in high-level UI development, but I'm not quite sure it's been done right, yet and have no idea when the dust will settle.
My point though, is that it's always a "secondary" or "tertiary" business concern... a point emboldened by the number and frequency of data breaches -- always followed of course, by the email newsletter follow-up & mea culpa. "We care about the security of your data, we swear. We regret to inform you that ..."
Sadly things are not always as they should be, friend...
Probably because very little innovation happens to any long-standing protocol until it becomes a primary business concern.
Almost every business relies on OpenSSL or some equivalent, but how many actually learn enough about SSL to contribute back to the codebase? Not many, because despite the need there's little acclaim or funding to be had pursuing things that won't make direct revenues, regardless of their importance.
Protocols like this generally don't get updated until it becomes a matter of necessity -- either by public awareness (we're far from that point) or someone designing the "next big thing" needs an un-implemented feature and contributes.
I do think there's some value to pointing out the irony though; two men from two cultures that couldn't be more distinct, with titles that could be synonyms, using what is essentially the same scripted prose to control and appease the media/populace.
Personally I find it disheartening. I think the Chinese are copying key aspects of the American Media/propaganda model because it's been demonstrated as so damn effective...
You seem extremely knowledgeable about high-performance servers!
Your example is fantastic -- I realize it's written in C, but perhaps you could explain how in the context of a tool like this (current article) might allow it to function as an end-to-end webserver?
What kind of limitations? What are the advantages, security implications? What is it well-suited for?
Really appreciate a reply -- I'm writing a book on architecture design and I'd really love to include some elements from the bleeding-edge of performance -- you clearly know what you're talking about.
Can you tell me where I may find more info on KDB or how this may compare to more traditional serving options for static resources, HLLs or anything that might fit well in a large tree.
I'm trying to understand exactly what its limitations are though, both in terms of what it can do and when it may be a poor candidate (when lower req/s is ok and greater flexibility is needed).
Hah, the way you phrase that makes me wonder what you found.
Right now really just web apps. Content sites are doable, and I know people running networks, but it's not possible to do profitably without clickbaiting, low-quality mass-produced content, and other greyhat techniques I don't particularly like.
I think it's fair to show you an ad if I save you 30 seconds to a minute of time. Creating garbage content slideshows with writers from the 3rd world countries to rack up pageviews is one step over the line for me...
Simple apps are great because they have utility (so google always approves your tag), and honestly the doubleclick exchange isn't so bad -- with enough simple single-page apps, it accrues pretty quickly.
Not exactly, I think it was a poor choice of words as I was referring to my build/deployment tooling.
If I have an idea (e.g. a "ES2015 to ECMA6" converter), I'd look for a library to do this (if there isn't an open source one, I'd consider building my own as a learning experience).
Setting up the webpage up (converter/form) is trivial since it's really just one page and a few settings.
The really cool part is I've built laravel commands to do the hard work for me. They can:
- buy domains based on a keyword search with some common regex-like patterns
- set up a git hook to continuously deploy to an AWS micro instance via codedeploy/CircleCI
- manage different adsense codes across properties
So, if you're wondering these are things that have utility. I'm optimizing the pains of setting up each site, though.
I do build adservers for a living, but never once have I created a crappy content-farm click-baiting blog -- they are the scourge of the internet >:{
[edit] lastly, I'm not sure if you have a problem with google ads (doubleclick/google publisher network) but I think they're pretty sensible in what they allow... no reasonable person would take issue with that.
I'm sorry to say I won't be releasing that first... The first is due within the next 12-14 days, after which it should take me 1-2 months to finish writing & editing the adsense-property-model guide.
To leave you with something tangible, it's very feasible to produce 5-figures per day with only hosting cost as your overhead ($300/mo).
[edit] without automation tools though, it would obviously be very tedious to produce the number of properties required to have that kind of income by hand. process flow & site generation/management is the crux of this strategy.
Well, "startup" is a poor choice of words, but he actually has a half-decent idea.
As someone who owns dozens of little "tool" sites (think less/scss converters, meme generators, JS beautifiers, etc), I can tell you each is probably 1-2 pages, took an hour to build and thankfully due to some domain squatting (kw in domain) and a low bounce rate I don't have to worry much about SEO.
As for the Adsense revenue, I think you'd be quite surprised.
One is an afternoon, not a startup idea.
50, on the other hand, could be passive income for a very long time.
Just something to consider before jumping to negativity. ;)
It's really interesting to see services like this emerge.
In my opinion, the merchant processing/gateway revolution happened when providers (Stripe, Braintree, et al) started providing quality APIs for user/profile/subscription management and took the burdens of PCI compliance off of the companies building consumer products.
On the surface, I feel like this is a great way to offload the liability of storing sensitive user data -- though it also creates a central source of failure. Success is predicated on Luno securing their data; if they can't, the model would die.
If they can, it's possible we'll start to see a mass-migration of authentication-based apps switching to these service, if only for the legal intention of offloading liability.
Yes, Islam is a particularly violent religion -- if you have read the Koran, many of its concepts seem very incompatible with the idea of a free secular society. Then again, the bible has the crusades.
I'm personally an atheist and I honestly don't think the problem is the the text itself but the cultural, ideological conflicts of an impoverished region that allows whoever "shouts the loudest" to assume power. The kids committing these atrocities probably couldn't even tell you what you just told me about Mohammad -- my point is that they are brainwashed and utterly uneducated so whomever comes along and says "this is god's word" is who they will listen to.
Anger + Desperation - Education = Extremism
You won't solve this problem by banning the Koran, but if you can get Muslims everywhere to renounce this "us-or-them" culture in favor of a more moderate interpretation (you know, how all religions seem to evolve if they want to survive) then perhaps we can neuter these kinds of groups before there's a power-vacuum?
It does if you play devil's advocate and follow the chain of reasoning.
If god is great and non-believers are bad and "god" says it's righteous and just to punish the non-believers, then naturally doing "god's work" is doing no harm?
Actually the truth is even messier... most of these young men committing atrocities are merely indoctrinated pawns who know very little of their own religion and instead defer to their "emir."
This ideological poison is being propagated by those individuals, with power/financial interests back in the middle east. I think the individual committing the act believes they are doing good, and the individual who convinced them to do it is too morally corrupted & detached to care about ideals such as "civilian life."
There are far more atrocities that occur in this world than there are psychopaths in the general population.
If we hope to make any progress toward peace, I think we need to truly understand the reasons why and how weak, impressionable minds with poor cultural integration can be manipulated to commit such atrocities.
It's easy to label these individuals as determined, unreachable psychopaths (particularly out of fear) but the sad truth is, most extremism is borne not of evil but of weakness. A select few manipulate this weakness to convince otherwise insignificant people, often with desires of grandeur to commit unthinkable acts. This power of perspective becomes increasingly obvious as you realize most problems with immigrants in European countries occur in the 2nd and 3rd generations -- those who have seen the true horrors of war first hand are not so easily fooled.
The hard truth is: if society doesn't provide susceptible minds with alternatives first, a small but steady % will be at the mercy of whomever comes along promising "answers."
As someone who develops high-performance systems and is continually learning, I think this is a fantastic idea!
Honestly, something that seems desperately needed as that knowledge is currently spread out among hundreds of thousands of blog posts, forums and threads -- diamonds in the rough.
I'm going to try to get something published on gumroad (and open-sourced on github) in this vein, if you're interested let me know and I'll reach out when it's done :)
Because it has never been a question of who is deserving of what...
The poor have no leverage, and realistically, no one is going to give that to them.
We're not talking about an idealistic re-working of civic values, but the natural tension that already exists between private interests and the public sector.
One need only look to antitrust law to see why letting any single locus of control grow unchecked can wreak havoc on a market/economy -- I think we should appreciate the few checks & balances we have left, lest this notion of naive idealistic equality allows them to slip away unchallenged.
I was actually planning on testing a 33% deployment this evening, I guess what I'm really wondering is that because this is a low-level networking adjustment that modifies locking behavior, are there 'gotchas' I should be aware of beforehand?
I'll test and report back regardless; only afraid of the scenario where the test goes well, and the entire network goes down a week later (e.g., a wonderfully-fun time we had previously chasing down rogue epoll queues and zombie processes that only occurred after a threshold of sustained load).
Can anyone comment on whether it would be a good or bad idea to try to implement this in production ASAP?
I'm a bit far removed from the Linux kernel to be comfortable auditing that myself, but I run some high-volume/low-latency exchange clusters and the limiting bottleneck on requests/box has always been due to SYN/ACK negotiation.
I solved that currently by having hundreds of smaller servers, which distributes the network load quite nicely but isn't even coming close to maximal utilization of CPU. Realistically since moving from PHP to Haskell we're seeing about 1k req/s/box, but without the network slowing things down we're looking at a magnitude of increase on the current hardware.
Just FYI I've already handled the obvious, such as intelligent caching, nginx split upstreams, TIME_WAIT and reuse adjustments (1s), et al. Qualitatively, we're looking for an assurance on <= 100ms TTFB for the 99th percentile, in a way that allows us to use the most of our hardware via green threads.
It's because there's at least one person on-board the company who understands the technical underpinnings, and has incentives that (usually) align with shareholders -- versus consultants whose bottom-line is never entirely dependent on the success of your company.
I'm not sure I see that as a fatal flaw... ultimately, the user is sitting in front of a digital box that can guide and prompt them in all the same ways a researcher can--the only limit is in performing tests that require a medical professional to assess biomarkers. If the pace of medical device development continues, it's even reasonable to think something like a Theranos-that-works could commoditize the process while being intrinsically tamper-resistant.
Regardless, users can be prompted to perform any software action (knowingly or unknowingly, to affect bias) and that action can be measured by the system. It may so happen that every critical measurement occurs unbeknownst to the user, before they self-report anything (if at all). As we are currently undergoing a period of sensor-proliferation (fitness/health devices, wearables, internet of things, etc...) it's not unrealistic to think we will soon be able to instantly correlate data from a smartphone camera, blood/tissue, and the cloud.
Now there's always the problem of intentional fraud/deception, but I think the aggregate nature solves that problem. A small percentage will try to "break" the system, and that small percentage will never surpass a critical threshold with enough volume. In terms of ML/SVM's, we're now very good about filtering outliers or "misrepresented data"... while the responsibility is on you to develop a reliable classifier (for data-consistency more than arbitrary measurement), I imagine at scale you could infer trends with the same relative accuracy of traditional academia and research.
It's a really fascinating new direction--even if only an adjunct to traditional research--and I'll definitely be keeping an eye on the project.
I'm afraid you're misinformed, but for socially-conscious individuals (ie, they don't support a scorched-earth, ends-justify-the-means policy to get that $250,000* from your nephew for torrenting Inside Out) I'm including my comment below.
If you are a programmer, security researcher, artist, or entrepreneur you can make a difference.
1. As an individual: if you understand the methods, contribute to open-source tools that allow individuals to exercise their rights. https://github.com/apprenticeharper/DeDRM_tools (one example)
Artists: Use self-publishing platforms (gumroad, bandcamp, even spotify...) and self-incorporate. Discriminate against giving your business to companies that don't support open, sane protocols. Don't let them exert their power against the populace through backdoor trade deals.
Entrepreneurs: Create new content delivery and streaming platforms that force the transition to digital--rightsholders like to claim that piracy is responsible for their failed economics, though the truth is that they had an artificial market advantage of scarcity. User-generated content has bloomed with the advent of digital, and more consumer choice is a death knell to the traditional monopoly.
2. As a cause: support the EFF, and any politician looking to work with the FCC who understands this issue is deeper than "restricting content," and could undermine the rights of property and security of ownership. Do not trust anyone who does not comprehend the societal implications of critical infrastructure being "security through obscurity." http://apps.fcc.gov/ecfs/comment/view?id=60001303221
The security of your laptop, the concept of personal ownership, and your right not to be digitally inspected at over 40 international borders is at stake.
* figure revised to more accurately reflect the reality of the american justice system.
Despite the obvious high/low-level language differentials, people have been managing multi-million-line C code-bases since the 80's. Then again, think of how little the build tooling has actually changed -- instead of fragmenting, you're left with llvm, gcc, make at the core of most compiled software.
JavaScript is the exact opposite with the lowest possible barrier to entry (built-in to every web browser...), and the proliferation of frameworks and libraries may be due to this in combination with the lack of fundamental understanding of design patterns that can scale. Lots of people trying to partially solve symptoms, missing the forest for the trees.
Theoretically there's nothing preventing good patterns in high-level UI development, but I'm not quite sure it's been done right, yet and have no idea when the dust will settle.