BUG: Government occasionally shuts down #3
Comments
|
+1 |
|
I can confirm that this is reproducible. Have you tried rebooting it? |
|
👍 |
|
YES |
|
We could probably reassign this back to 🇬🇧 |
|
👍 |
|
My local installation of Government seems to be running as normal. |
|
My branch of the government is also shut down; can confirm that this is affecting more than just master. |
|
Looks like someone may have inserted some malicious congresspeople, can we issue a Pull Request to remove? |
|
|
This had me laughing out loud in the office. Thanks! |
|
I think it's time to fork a new repo again. |
|
Barack Obama, the lead developer should be assigned |
|
Could be a FOR loop issue with init.Republicans? |
|
If only contributors were allowed to rewrite history... |
|
The sysadmin says it's user error. Arrogant like all sysadmins. |
|
👍 |
1 similar comment
|
+1 |
|
@johnboehner closed issue #3 as "#wontfix" |
|
Typical proprietary bloatware. Trash it and find a simpler, lighter weight alternative. |
|
👍 |
|
php strikes again |
|
Can we elevate this bug to critical? |
|
It's a |
|
Sounds like a new distributed approach might be worth trying. |
|
Looks like new code added to the getter on |
|
Rewrite, this time using logic programming. |
|
+1 |
|
@VinSpee naw, @SupremeCourt verified tests are passing fine. |
|
Confirmed, was able to reproduce. I think there may be a locking issue with congressional members. |
|
I've done a root cause analysis. This bug stems from a race condition triggered when class inheritance passes public objects to a private subclass. It can be fixed by eliminating class-based inheritance, implementing rapid replication-on-demand from master to slave servers, and reverting commits during the past year that have been caused severe performance degradation. |
|
This is so horribly broken it should be rewritten from scratch to be honest. The democracy class is horribly broken. Every time you submit a value, it no longer accepts inputs for 4 years. What the class does during that time is mostly disappointing and the outcome doesn't seems to be affected too much by the value you submit. I recommend rewriting the entire |
|
|
|
The bug is being given the codename Spectre Orange. |
|
Also the version number is 45, not 44 |
|
^ this is why semver is important. Can someone please move this to the next sprint? |
|
Reading notes from @ wchurchill (prior PM on a parallel project) it appears to be related to it being "the worst system of government apart from all the others" and his research showed that a five minute conversation with the average user indicated they didn't understand the product. Further market research by @ ripley suggests "nuke the entire site from orbit. It’s the only way to be sure." The North Korean office is working on the necessary technology. |
|
The amount of technical debt in this application is astounding. I think you need to rip n' replace all services that interface with the original code base. The services seem totally disconnected from the intent of the original code authors and seem to be written to serve their own best interests and not the intentions of the original code. I suggest you replace the entire framework with one that actually works together for the betterment of the application. |
|
Needs more blockchain; call for papers open! |
|
I would advise against reimplementing from scratch because current code, with all its bugs, imperfections, and corruptions, have many checks and balances accumulated through centuries of use. Those checks prevent edge cases and adversarial attacks from internal and external sources or other corrupt or self-motivated processes. For many we even forgot that they exist, or we think that they do not exist anymore, because checks are preventing them from occurring. Sadly, current code is not well documented so it is impossible to reconstruct the list of all design and security decisions, use cases, bug reports, user experiences and general requirements which are present indirectly in the implementation. See this tale for more background information: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ |
|
did someone leave a few |
|
@mitar: the problem is that those checks and balances are, well, checking-and-balancing against old bugs that are no longer the case. For example, the institute of electors was implemented to solve the problem of XIX-century communication channels that were known for their low throughput, high latency and packet loss rates (see RFC 1149), and most consumer devices had trouble recognizing handwriting. No longer a problem: in year 2017, 99% of the user endpoints communicate over TCP/IP. Time to throw out the obsolete code, and implement at least direct democracy (although I would recommend moving on to XXI century and implement online/realtime democracy). |
|
https://followmyvote.com/online-voting-technology/blockchain-technology/
Vote with your phone. Vote early, vote often. I'd have to disagree with an earlier
post though in that there is still a significant user education problem.
Also, it is still very easy to install Trojans that trick users into voting on the wrong blockchain.
User education can help, but vigilance is important as well.
Trojan Horses have been used, for example, to take over the infrastructure of a city, and while it is unlikely these attacks will go away, better monitoring of critical subsystems is increasingly important.
…On Jan 23, 2018 3:06 PM, "Matt J. Sorenson" ***@***.***> wrote:
Needs more blockchain; call for papers open!
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#3 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFiiRvvC6CSV90Uogy5Rn1q2mQTEpvocks5tNjvigaJpZM4BFLPn>
.
|
Really? I think if you read Plato's Republic, you can see that most cases of issues with governance were already there. Things like corrupt institutions and individuals, concentrations of power, nepotism. Heh, even Ponzi schemes still happen.
Voting is just a very small part of whole governance application. Even story I linked before says:
So yea, we can optimize/improve that 1% of the whole thing. But rewriting the whole application, this leads to failure. But a voting feature, there is definitely some improvement to be made. Collaboration in general. Real-time, massive, online. |
|
# alias_method :new_name, :old_name
alias_method :direct_democracy, :mob_rule
Direct Democracy will likely introduce race conditions, and destabilize the system.
jon
blog: http://technicaldebt.com
twitter: http://twitter.com/JonKernPA
github: https://github.com/JonKernPA
… On Jan 24, 2018, at 12:44 AM, Mitar ***@***.***> wrote:
the problem is that those checks and balances are, well, checking-and-balancing against old bugs that are no longer the case.
Really? I think if you read Plato's Republic, you can see that most cases of issues with governance were already there. Things like corrupt institutions and individuals, concentrations of power, nepotism. Heh, even Ponzi schemes still happen.
Time to throw out the obsolete code, and implement at least direct democracy (although I would recommend moving on to XXI century and implement online/realtime democracy).
Voting is just a very small part of whole governance application. Even story I linked before <https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/> says:
A second reason programmers think that their code is a mess is that it is inefficient. The rendering code in Netscape was rumored to be slow. But this only affects a small part of the project, which you can optimize or even rewrite. You don’t have to rewrite the whole thing. When optimizing for speed, 1% of the work gets you 99% of the bang.
So ye, we can optimize/improve that 1% of the whole thing. But rewriting the whole application, this leads to failure. But a voting feature, there is definitely some improvement to be made. Collaboration in general. Real-time, massive, online.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub <#3 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAOfhaz0nBgmwCXZV_npWro0HoKs45vWks5tNsM_gaJpZM4BFLPn>.
|
|
@mitar: I'm not suggesting we rewrite the entire application, I'm suggesting we stop using the obsolete library that has long known vulnerabilities. I suggest |
|
for some reason |
|
Full rewrites have a terrible track record, prior examples in other projects mostly haven't worked and have lead to had system crashes or major corruption. Given the investment in use training, test cases and documentation any major change it likely to be very disruptive to normal system operation. Far better to iterate towards a solution to identified problems by piloting ideas in the state level modules. There are already "ranked choice / single transferable vote" models in test in several locales with positive results. On the finance and accounting subsystems the "cut all the taxes" PR seems to have caused major disruption in Kansas and was largely reverted. |
|
Unsure why this was closed, this seems to be happening again |
|
Any ETA on when this feature will be back? It is critical to the livelihood of over 800k people. Now may be a good time to consider a rewrite of this functionality. |
|
I think you have the wrong version. This should be a new issue under "fortyfive" However, as others have noted the version "fortyfive" is a major downgrade. It's development or lack thereof is under a whole new dev team that seems to be changing every few weeks. (Major turnover). Code is riddled with eligible gibberish. I would skip this version completely and wait for fortysix. |
|
Seriously, there are much bigger fish to fry! But now I'm wondering if this is an issue about security or aesthetics? In other words, do we need a fleet of DevOps to build this static firewall or could this be done with just CSS borders to emphasize the layout of the page? Or maybe there's something else (that we'll never know) in upper management that's being displaced into this shutdown this time around. |
|
I’d like to consider an emergency rollback to fourtyfour if at all possible. I know it is a real big lift, but it is a much more sustainable and scalable version. Or is there a way to disable or perhaps override fourtyfive? |
|
It’s obvious that continuous deployment is happening without continuous integration. And I think the logic to halt CD if there are bugs or if the quality scores are low, has been disabled.
It’s like 45 favors getting features out the door and getting rapid feedback (even if it is almost exclusively negative) vs pull requests and reviews and “focus group” marketing crap.
A Product Owner with a vision! Like it or not. At least there’s no executive oversight board clogging things up.
The amount of global, parallel development going on is mind boggling. Features being deployed in different data centers and replicated across sharded DB instances.
Lots of other system-level major components have been freed up to run with less entanglements and API regulation and to Get Shit Done.
But man there are lots of typos and bugs — must not be surrounded by automated tests.
Oh, and the problem with waiting for the next release is that it could be the same as 45. Might as well buckle up and hang on for the ride!
Now get back to coding something we can deploy at will!
Build me that firewall!
jon
blog: http://technicaldebt.com
twitter: http://twitter.com/JonKernPA
github: https://github.com/JonKernPA
… On Jan 25, 2019, at 2:45 PM, Riley ***@***.***> wrote:
I think you have the wrong version. This should be a new issue under "fortyfive" However, as others have noted the version "fortyfive" is a major downgrade. It's development or lack thereof is under a whole new dev team that seems to be changing every few weeks. (Major turnover). Code is riddled with eligible gibberish. I would skip this version completely and wait for fortysix.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub <#3 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAOfhc7JadFC3KCrcJiITyUnRUfWQP1Zks5vG168gaJpZM4BFLPn>.
|
|
What I find most disconcerting is that this issue was raised at all under this component. This is not the WhiteHouse's responsibility. The separation of concerns has bled over between components, each component is doing way too much of other components' responsibilities. As a result no one seems to understand what component is supposed to do what. This issue must be resolved in Capitol. The underlying problem is that Capitol is backlogged, putting out way too much more than what it takes in, resulting in a stack overflow fault. WhiteHouse v. fortyfive is using this as leverage, but ultimately Capitol hasn't worked properly in decades and it is getting worse logimarithically each year. Frankly I wonder if the whole thing should be rewritten. |
|
Looks like we have a patch for now. |
|
Patch didn't fix the root cause, the bug will return without an RCA and it's appropriate fix. |
|
Yes, the core routine logic is all screwed up. In fact it seems as if it
always produces a fallacy, even when it really doesn't need to.
I would suggest switching to a paraconsistent logical core. RM3 comes to
mind. This will shut down fallacies of relevance (straw man, appeal to
authority/wealth, ad hominem, vacuous truth, etc.), see here for a more
complete list:
https://en.wikipedia.org/wiki/List_of_fallacies#Relevance_fallacies
|
As a side-effect of the most recent patch, I believe, this error condition should now be obsolete |
and others
I noticed a bug over the past week or so and it seems reproducible:
Expected results: Government should be working.
I'm unable to debug or propose a fix since there's not an open, transparent stack trace. Conflicting error messages are being thrown as well.
Hope you can resolve this soon. It would seem that the U.S. Government would value 100% uptime in order to be a reliable and trustworthy source for the rest of the world.
Thanks! Love this project and would like to continue using it.
The text was updated successfully, but these errors were encountered: