You're playing semantic shell games here. The user has no reasonable way of knowing that stripe.js came from stripe, and as such, there are no technical OR human controls that enforce that behavior.
In short, the fact that stripe.js is delivered from stripe DOES NOT MATTER, because the user CAN NOT reasonably validate this behavior.
I know you're not dumb over at Stripe; I have a hard time believing that you're not willfully lying. After all, "disrupting" onerous industry security standards is to your competitive advantage.
I run my own mail server and it's essentially zero work. I have postfix, dovecot, SpamAssassin, and RoundCube, all authenticated via LDAP.
It required some upfront configuration, but it has run itself with minimal configuration changes and 'apt-get' updates for almost 6 years now. I never touch it, and it works.
> It's not just the configuration, your service will always be subpar. At least until there's a good webmail (I have high hopes for Mailpile).
That assumes that user's want to primarily use webmail. In this renaissance of Mac OS X mail clients and mobile phones, that hasn't been the case here.
dsync seems to stop working properly after a while for some reason, the usual solution is to upgrade it, which implies a compile from source. after a while it's a pain to keep all these packages up to date.
i am using it in production (debian wheezy package, version 2.1.7-7 now) and it works pretty reliable. do you have a link to a bug report? i kind of depend on it atm, so i'd like to know its bugs.
Mail hasn't changed much in more than a decade. Systems like Ubuntu update cleanly from release to release. Maildirs are very easily migratable.
You can literally set up a new mail host, and then rsync the old Maildir contents -- aka, all your user's e-mail -- onto your new host, whenever time permits, without disrupting mail delivery or reading. User's historic e-mail will simply gradually fill in.
If your VPS disappears, or hardware failure occurs, or user error strikes -- simply restore your Maildirs on a new system from your backups (tarsnap works great!).
This documentation is long and thorough, but once you know what you're doing, setting up a basic mail server, even manually, should only take you a few hours at the most.
The solution would involve some kind of communication and perhaps a way of electing a 'leader'. I don't claim that it's a particularly easy problem to solve, but it seems to have been done when people just used a mailing list and cvs, so it is possible...
> I don't claim that it's a particularly easy problem to solve, but it seems to have been done when people just used a mailing list and cvs, so it is possible...
It worked back when we had a mailing list, CVS, and a web page because a single individual or set of individuals owned the top-level project infrastructure associated with the name in question.
Github broke that model by making forks largely non-subsidiary to the projects they fork. They exist at the same namespace, they have independent bug tracking, wikis, and author information.
This breaks the social economy of contribution that previously existed; even if you choose to not participate in Github, your project will be forked hundreds of times via published Github-based mirrors that look like every other top-level copy of the project.
I like 0MQ a lot, but this is disingenuous. Let's break it down:
> portability
Sockets are just as portable, more so on UNIX descendants where one can rely on relatively consistent socket APIs. Beyond that, almost every single language and runtime (Python, Ruby, Java, OCaml ...) provides a portable socket API.
> message framing
Length-prefixed message framing winds up being 10-100 lines of code in almost any language/environment.
> super fast asynchronous I/O
Sockets have this.
> queuing
Sockets have buffers. The OS can use those buffers to implement flow control. This isn't the same as queueing, but the truth is that you rarely want blind background queueing of an indefinite number of messages that may or may not be delivered.
> support for every bloody language anyone cares about
Just like sockets.
> huge community
I don't think you can get 'huger' than the community around sockets.
> price tag of zero
Seeing as socket libraries ship with everything, does that mean they have a time/resource cost of less than zero?
> mind-blowing performance
Also, sockets.
> protection from memory overflows
This has essentially nothing to do with a networking library. Plenty of environments have safe/efficient zero-copy chained byte buffer implementations/libraries.
> loads of internal consistency checks
Library correctness isn't a unique feature.
> patterns like pub/sub and request/reply, batching
Ah-ha! Here finally we get to the meat of it!
If you need QUEUES, including pub-sub, fanout, or any other QUEUE-based messaging structure, than 0MQ is better than sockets!
> and seamless support for inter-thread transport as well as TCP and multicast
Inter-thread transport of already-serialized messages at the transport protocol layer doesn't make a ton of sense from an efficiency perspective.
> ZEROMQ IS JUST SOCKETS
No, 0MQ is a lightweight network message queue protocol. It's not competing with sockets.
> Sockets are just as portable, more so on UNIX descendants where one can rely on relatively consistent socket APIs. Beyond that, almost every single language and runtime (Python, Ruby, Java, OCaml ...) provides a portable socket API.
You've got to be kidding me. The BSD socket API is only "portable" for basic things. Do any kind of advanced thing and you will notice the limitations of the "portability".
Want to write an evented server that handles a large number of sockets? Choose your favorite platform-specific API: epoll, kqueue, whatever Solaris is using, etc.
Windows support? I hope you don't mind the #ifdefs and typedefs in code. The WinSock API is still OKish... it doesn't differ from the basic BSD socket API too much. But good luck trying to handle more than 1024 sockets in a non-blocking/async manner. I hope select() on Windows serves you well.
> Length-prefixed message framing winds up being 10-100 lines of code in almost any language/environment.
Only if you're writing blocking code. If your code is evented, good luck with writing 2-3 times more code. Oh, and don't you dare getting that code wrong and introduce bugs. And of course you have to write this code every single time. And you didn't forget to unit test all that, did you?
Most of your argument is that each OS uses a different IO multiplexer. Lightweight abstractions over these multiplexers have been around for decades: feel free to use libuv if you want a fairly 'modern' one.
That the contour of the API differs slightly means nothing. An example of true incompatibility would be, say, supporting UNIX-style mounts on Windows. If you wanted to support that cross-platform, either you or a library would have to directly implement the semantics of UNIX mounts, as opposed to just making a shim over what the OS already provides.
Whether lightweight abstractions exist is moot. The point of the grandparent was that sockets are portable. If you're going to use an extra library besides pure sockets anyway then why is that any better compared to using ZMQ?
> That the contour of the API differs slightly means nothing.
What? It means everything if you have to learn socket intricacies at different levels of abstraction on a per-platform basis. That is not what most people mean when they say an API or library is portable.
Hahaha so true. Last year I wrote some network code that had to use sockets on windows, Linux, xbox 360 and playstation. 3. Each had many slight deviations in the low level socket API, from different behaviours to different error codes.
The socket APIs in Java, Python, Ruby etc don't do message framing for you. My point about having to write bug-free message frame parsing code still stands.
Original 0MQ author here. Pretty good analysis. The only real difference between 0MQ and sockets (i.e.traditional L4 transports such as TCP or UDP) is that it implements messaging patterns such as pub/sub or req/rep. You can think of it as a L5 layer designed to orchestrate communication between N endpoints (as opposed to 2 endpoints as is the case with TCP).
Perhaps that is how you saw it. However you are dramatically wrong. ZeroMQ v4 does full end-to-end encryption, supports protocols like TIPC, and (you knew this but choose to forget it for reasons I never understood) entirely changes how we write multithreaded applications.
The only plausible reason you could disregard the magic of using the same semantics for secure internet messaging and inter-thread messaging is that you don't write applications.
(FWIW, parent commentator more or less co-founded ZeroMQ with the grand-parent commentator; rumcajz left the project and is now working on http://nanomsg.org/.)
After working with 0MQ for a while I felt that this sort of summary was misleading.
I came to think of 0MQ as a multi-point data link abstraction (i.e. layer 2). The API abstracts over sockets, IPC message queues, and in-process message queues as the virtual layer-1 transports.
I say it is a layer-2 abstraction because 0MQ doesn't provide any mechanism for addressing or transparently routing over an internet of connected 0MQ networks. You can do source-based routing by explicitly naming the intermediate hops but this is more like intellegent layer-2 bridging than traditional layer-3 routing. There is no concept of a layer-3 address or naming scheme of any kind and there any important layer-4 features (re-transmissions, flow-control, out-of-order resequencing).
The message structure and fan-in/fan-out features are very useful but they are operating at a layer-2 level, not a 3, 4, 5, etc. layer, from my perspective.
It has been about a year since I spent time with 0MQ so perhaps it has evolved beyond what I experienced.
You might be interested in nanomsg (http://nanomsg.org/), the spiritual successor/spinoff of zeromq, by the original creator (the parent you replied to, Martin Sustrik). It features a BUS pattern too.
TCP/IP does multiple endpoints as well (multicast, multipath, broadcast, server to many, iptables/pfw rules) etc.
Various queue control methods are available in TCP/IP also.
UDP is the only way to get decent performance if your application is designed around it. Why bother resending data if it is too old now to be useful, or if the data arrived via another route? TCP often has more variable latency than UDP, which is the main performance killer for certain types of apps. zeromq isn't multipath aware either.
For many people getting the data from A to B as reliable as possible is more important than getting max performance. If that's something you need to worry about, you either end up implementing a worse TCP on top of UDP, or wondering why data disappear without notice.
Dealing with multicast is a real pain in the neck to deal with in your network infrastructure unless you only want it on one subnet, which restricts you just as much as traditional broadcast.
multipath is either something you leave to the routers, or use a protocol such as SCTP or, hope multipath-TCP will come to your OS in the near future, or you manage it in the application.
It's unclear what you mean by server to many, in this context it sounds like what you'd use a zmq socket to fan out messages for.
The queue mechanism in TCP/IP are for the transport layer, not for implementing application policy.
> Length-prefixed message framing winds up being 10-100 lines of code in almost any language/environment.
Over the years, I've worked on several different systems that wrote those "10-100" lines of message framing from scratch, and had to fix subtle, hard-to-track-down bugs with those. It's a conceptually simple thing that's very easy to have subtle bugs in edge cases. Edge cases that are difficult or impossible to produce in development systems, that do happen in production systems once you're running high volumes. An example of this is sockets pausing and in the middle of sending the multi-byte length, and needing to fiddle with certain parameters on the sockets that control heartbeat and other minutia.
It's certainly simple to write something that works well, but also very simple to write something that works well but will fail in subtle ways under certain kinds of circumstances.
With (dirt simple) length-prefix framing, and blocking reads, pauses and such are non-issues. e.g. blocking read for 2 length bytes, blocking read for N bytes of payload. If your read fails for any reason, or you've timed out, then you give up and close the connection.
Your application protocol needs to handle timeouts (some sort of retry, preferably with some notion of idempotency).
The problem with:
> > Length-prefixed message framing winds up being 10-100 lines of code in almost any language/environment.
is that it's not really a response the ZMQ feature. With ZMQ you don't have to reimplement for every application and platform.
Can you elaborate on why pausing on sending is particularly tricky when sending a multi-byte length header compared to say pauses on any other part of the payload?
It's particularly tricky when dealing with async code, where you can't simply say "block here till you have 4 bytes." If you're just getting in events that say "you received n bytes and here they are."
All networking code should work even if it receives 1 byte at a time. Use a buffer, and have some sort of abstraction responsible for packetizing the input. The output of that module is a fully formed frame ready for interpretation.
The only points of yours I agree with are the claims of 'price tag of zero' and 'mind-blowing performance'. The rest seem to be apples/oranges comparisons and being intentionally obtuse, e.g. as to what 'portable' and 'community' mean.
> Sockets are just as portable [...] almost every single language and runtime (Python, Ruby, Java, OCaml ...) provides a portable socket API.
It's not portability if you have to learn APIs at varying levels of abstraction for each language you need to port to.
> Length-prefixed message framing winds up being 10-100 lines of code in almost any language/environment.
That is work to do in every single language you wish to work in. You are acknowledging the value that ZeroMQ provides in not requiring you to carry out this work.
>> support for every bloody language anyone cares about
> Just like sockets.
Except with the aforementioned portability (APIs at a consistent level of abstraction), which is not something raw sockets provide.
>> loads of internal consistency checks
> Library correctness isn't a unique feature.
Not sure what that means. ZeroMQ's claimed value-add here is in providing correctness in various languages, that you would not get otherwise when using raw sockets.
>> huge community
> I don't think you can get 'huger' than the community around sockets.
People writing socket code in C don't go to SocketConf and meet people writing socket code in Python. They don't idle in #socket on IRC. They don't swap blog posts about the cool 'socket patterns' they wrote today. It's not a community.
>> and seamless support for inter-thread transport as well as TCP and multicast
> Inter-thread transport of already-serialized messages at the transport protocol layer doesn't make a ton of sense from an efficiency perspective.
It's a feature nonetheless. That you think it doesn't make sense 'from an efficiency perspective' does not invalidate that feature.
>> protection from memory overflows
> This has essentially nothing to do with a networking library. Plenty of environments have safe/efficient zero-copy chained byte buffer implementations/libraries.
But you don't get that with raw sockets in every environment, which is the point.
The other essential ingredients of a creation myth are lies and deception. ØMQ is nothing at all like BSD sockets despite very insistent attempts from its early designers to make that. Yes, the API is vaguely socket-like. APIs are not the same as semantics. ØMQ patterns are weird and wonderful and delicate but they are not, and I'll repeat this, even marginally close to the BSD "stream of bytes from sender to recipient" pattern."
Indeed. The original "sockets on steroids" story was wrong, though sincere. Sockets are the API but the actual machine underneath is nothing like a BSD socket. ZeroMQ has in the last years moved away from the "it's a BSD socket" metaphor as it is a tediously limiting API in many ways, and created the unnecessary confusion that I wanted to pick on in this story.
I think you are missing the fact that 0MQ builds on top of sockets. Of course you can do all of the same things using just plain sockets but then you end up implementing parts of 0MQ. Like all libraries, 0MQ is a set of preimplemented features that you can just use in order to work at a higher level of abstraction and not worry about corner cases so much.
It's not true. I checked http://zguide.zeromq.org/page:all and it would only take 332 pages to print it all out. And to understand ZeroMQ you only need to read the first few pages and skim the rest. That is enough to see that ZeroMQ is a serious attempt at letting you use the same design patterns that you would use with Message Queuing over top of plain sockets, i.e. there is zero Message Queue system behind the curtain. 0MQ is useful because these design patterns make it easier to build correct and powerful applications that leverage network connectivity.
I have built applications that use both AMQP messaging with RabbitMQ and ZeroMQ for the parts where an MQ broker was not necessary or where it would impact performance.
The arguments swirling around ZeroMQ and sockets are the same ones that swirl around threading and higher abstractions. We now know that it is hard to write correct programs using threading unless you refrain from using locks and either have all state immutable or you use lock-free access techniques. There are many libraries (even for Android and iOS) that encapsulate threading with a task-oriented layer that communicates between tasks/threads using queues.
Sometimes you have to make a decision NOT to do something that you CAN do, because of the greater good of the work.
It's no different than any significant technology that has few antecedents. Once you know the background and cast away assumptions and fallacies, it's much easier of course.
I don't find it that disingenuous. I recently used 0MQ on a project, and quite frankly it would have taken a lot more code to do what 0MQ provided out of the box.
0MQ implementation is built on Sockets. I can build the same features on top of Sockets, but why would I want to if it works well?
Side note: I'm interested in looking deeper in to nanomsg http://nanomsg.org/index.html -- which is a re-write of 0MQ by the original author.
Renaissance? Open source has never been less healthy. All the previous social constructs around properly documenting, testing, and releasing stable versions of your code have been swept away.
Instead we're faced with the constant churn of semi-functional code, users working in silos and then showing up with patches well after it's too late to give them direction, animated GIFs instead of careful engineering discussion.
Github optimized being lazy, and this was appealing, and in doing so they broke most of the technical and social structure that held together open source's ability to produce reliable, stable, well-documented software.
I've watched stable projects either wither and die or become commercialized, and now instead we live in a world of rolling mostly-broken hacked out releases (if there are releases at all), a confusion of forks (which one is the 'real' one?), while animated GIFs and "oh snap" responses permeate our bug trackers.
Since when were bureaucratized quality standards part of Open Source?
---
"GitHub optimized being lazy" -- translation: GitHub enabled more people to get involved with Open Source.
There are no-fewer quality-obsessed developers participating in the community as a result of GitHub. There are, however, a lot more people involved, and a lot more code being "churned". The suggestion that the community is suffering as a result is a dubious claim that you offer no real evidence for.
It sounds to me like you miss the "good old days" when the club was more exclusive.
> There are no-fewer quality-obsessed developers participating in the community as a result of GitHub.
There is natural attrition of participants in any project; what keeps (or kept) so-called "quality obsessed" developers in abundance were the social structures -- and social currency -- of the communities built around open source projects.
In exchange for stature, learning, and intangible satisfaction, contributors would learn project guidelines, interact with project members, learn to meet the required levels of quality, and over time be subsumed as committers and trusted members of the community. This approach sustained open source for roughly 20-25 years.
However, github's social network structure supplants the traditional communities, instead creating a wholly Github community in which the previous social construct (and social economy) can no longer truly thrive, and instead, the community and social focus is redirected and reinvested in Github itself.
The similarities to the reward mechanisms and value feedback mechanisms of social networks like Facebook are quite strong.
> It sounds to me like you miss the "good old days" when the club was more exclusive.
This seems to be a recurring theme; it sounds to me like justification for cognitive dissonance borne out of a situation where two choices exist:
1) Subscribe to the notion in which one would be a junior contributor in a broad pre-existing world of established engineers, or
2) Ignore the experienced engineers and create a community of self-evaluating peers, writing off the old model as "exclusive" rather than "experienced".
I expect the truth is found in-between those two poles, but reality has trended strongly towards number #2.
I never disagreed that the overall quality of the code has gone down; I meant to suggest that such an observation misses the point.
Open Source is now much more accessible, and I think that's a good thing.
It used to be that if you wanted to own a car, you needed to basically have the knowledge of a mechanic. Now any "idiot" can own and operate a car. Is that such a bad thing? Cars are for getting you from A to B, remember?
There is arguably more mediocre code out there in the public eye now, thanks to GitHub. Is this bad? I'm not sure. But don't tell me that GitHub has made it more difficult for you to make software of the same quality as the stuff from 20 years ago.
Furthermore, why do I need to "choose" one of the options you gave? I don't care if I'm "junior" or "senior".
TL;DR: I just want to get my work done like everybody else. It's a matter of practicality; not honor.
Then you missed out on an intelligent and frankly important critique. He managed to put in words what I have been thinking for a while. I was skeptical after the first two sentences too...
I disagree on both counts. Actually, I find the assertions in that post callous and destructive. This cathedral that the poster is referring to never existed. Open source has never been healthier, and Github is a very big part of the reason why.
The parent makes very salient points, I think you'd do we'll to understand rather than brush then away because they don't comport with the conventional echo chamber wisdom.
I suppose you might be right, but I definitely don't feel that way myself. If it wasn't for GitHub, I don't know if I would've made an effort to get involved with the projects I use. It's made it insanely simple to find a project, get documentation and a list of open issues in one place, with a consistent UI across projects. It's also been a pleasure committing fixes for projects I use - as mentioned above, being able to discuss the fix in a code review style environment, with the original author is hard to beat.
Projects I've published myself have been a breeze to maintain, because pull requests are really easy to manage. I can review changes with the submitters, pull the changes myself to tweak if I need to, and auto-merge when changes are simple enough. It also acts as a nice portfolio for potential employers.
I guess I feel like OS in general is benefiting from the likes of GitHub, not suffering. Just my two cents.
> Instead we're faced with the constant churn of semi-functional code, users working in silos and then showing up with patches well after it's too late to give them direction, animated GIFs instead of careful engineering discussion.
I've been paying attention to this stuff since around 1998, and except for the animated GIFs, this has always been the case. The difference is that we've had 15 years for the abandoned cruft to accumulate, and Google has gotten a lot better at finding it.
Circus? you could barely call it a sideshow.
I remember the glory days when we wrote perfect algorithms by hand and mailed them by post to each other. We called it Mathematics.
I've watched beautiful concepts come to life only to choke on the reality of bits.
It's very easy to be a part of the the problem when you're not contributing to a solution. It's also very easy to say a lot about nothing. I mean that in that you source no projects that have gone the way you described.
>Github optimized being lazy, and this was appealing, and in doing so they broke most of the technical and social structure that held together open source's ability to produce reliable, stable, well-documented software.
And yet, here we are, years after Github optimized being lazy and broke most of the technical and social structure of open source, and we still have hundreds of thousands of usable and awesome open source projects available to use and contribute to. The internet and the apps built on it still run just fine, people are getting more done with technology than ever before, and more people are getting their code out to the world than before Github.
I think that you're either overly cynical and negative, or you're upset because Github has taken away implicit social power you used to have or you're pissed off cause you have to deal with the plebs who use your obviously brilliant software in ways that aren't correct (i.e. ways you didn't think) then have the audacity to file bugs on it in ways that are wrong (i.e. ways you don't like).
1) The internet and the apps built on it still run just fine.
There is very little maintainership and investment in core difficult technology development. Most core projects that make up the foundation of the internet subsist on the oft-dwindling maintainership of what you seem to consider to be a legacy generation of engineers.
Outside of areas where companies hold direct commercial interest, many core technology projects are withering or stagnate. There are an infinite variety of new JavaScript frameworks, however.
2) Hundreds of thousands of usable and awesome open source projects available to use and contribute to
We're reinventing wheels at a prodigious pace, but your comment demonstrates and underlying shift in the opensource mindset that Github has invoked. Whereas open source was previously something to be produced as a stable, reliable entity, and consumed by users, it has instead become an expensive participatory process for all comers, in which stability and reliability and even documentation is discarded in favor of quick fixes and local patches and increased expenses for the entirety of the ecosystem.
3) More people are getting their code out to the world than before Github.
It's the conceit of every generation that they exceed the previous, but this statement (and the implication that this is due to Github's introduction) is simply not true.
> We're reinventing wheels at a prodigious pace[...]
What you see as waste, I see as valuable experience. In school, did you just read books and take tests? Or did you spend a lot of time solving problems that had already been solved, deriving equations you could have looked up, writing programs you could have downloaded...?
People learn by doing. You don't sit down and design the Next Big Language on your first try. You invent a lot of shitty, unoriginal little languages while simultaneously studying what's out there, and maybe eventually you get to the cutting edge where you can create something novel and better.
You're both arguing by anecdote here. It seems to me self-evident that Github has many more projects on it -- not just forks of existing projects, but original projects, period -- than its predecessors and competitors do. This just about definitionally implies that it has a lot more crap. While it would be hard to prove that Github has a higher percentage of crap on it than its predecessors and competitors, that's certainly plausible.
However, you're essentially taking it as a given that the absolute number of worthwhile projects has dropped thanks to GitHub. If there's convincing evidence of this, I'd honestly like to see it, along with a plausible theory as to why that would be the case. What does, for example, Sourceforge get right that GitHub doesn't? (At least from my anecdotal experience, Sourceforge is in fact full of under-documented, unfinished and effectively abandoned crap to more or less the same degree that GitHub is.)
> However, you're essentially taking it as a given that the absolute number of worthwhile projects has dropped thanks to GitHub.
Not just dropped -- they're drying up. I can only speak from anecdote (nobody has paid me to run a study), but while I've seen no dip in usage of my libraries, and I've seen my projects explode with half-baked forks on Github, I've seen mailing list participation and worthwhile code patch submissions drop to very nearly 0.
> What does, for example, Sourceforge get right that GitHub doesn't?
SourceForge essentially died out for modern projects upon the release of Google Code in 2006.
However, what (traditionally) SourceForge and Google Code did right -- and, what projects did in their own hosting for decades before and after that -- was place the project's community in the forefront, and the code in the background.
This meant that documentation, releases, mailing lists and other constituents of a vibrant community project were placed in the forefront, with the code being something that one worked on as part of the community.
By contrast, Github made projects secondary. The code was (originally) always attached to an individual account name. The primary project page was the code itself. Forks existed at the same namespace hierarchy as the projects they forked.
The result was that Github sucked community energy into Github itself, and in doing so, began to redefine the community social constructs in a way that allowed users to maximize social and personal rewards while minimizing work necessary to conform or participate in the project's community.
Although I disagree with almost everything you've said in this thread, I appreciate the different perspective and your points are certainly reasonable (ie. have given me something to think about). However, this:
>> 3) More people are getting their code out to the world than before Github.
> It's the conceit of every generation that they exceed the previous, but this statement (and the implication that this is due to Github's introduction) is simply not true.
has me scratching my head. I would have assumed "there are more people writing code now than five years ago" and "Github has enabled/encouraged/caused/what-have-you proportionately more programmers to publish their code" to both be true statements, leading to an obvious conclusion. What do you think I'm missing?
I think you're both looking at this the wrong way. The projects that "wither or stagnate"? Without Github, they likely wouldn't be publicly-accessible at all. The professionals will always produce professional code, the amateurs will always produce amateur code, and what Github did was to make the amateur code accessible. You can't make the amateur code into professional code, but that by no means translates to it being valueless. You just have to recognize it for what it is.
In short, the fact that stripe.js is delivered from stripe DOES NOT MATTER, because the user CAN NOT reasonably validate this behavior.
I know you're not dumb over at Stripe; I have a hard time believing that you're not willfully lying. After all, "disrupting" onerous industry security standards is to your competitive advantage.