503 karma · joined October 25, 2013
The things being done to these people in detention are horrible. We just translated an article about a 16-year-old boy beaten into a coma. When he awoke he said he was one of the lucky ones. ( https://www.voiceofbelarus.com/how-to-save-timur/ )
From consistently talking to multiple opposition members, here is my take on the current mindset:
Every single protester on the street is aware that the police are waiting for them to do anything that gives an excuse. Foreigners don't always understand the dictatorships use a two-pronged approach, one part being heavy-handed violence and the other being heavy-handed propaganda. Like it or not, there's always a percentage of the population that buys into the propaganda, either by being stupid or by being centrist.
The protesters are very intentionally being careful to not give any excuse. That's why you see 70-year-old grandmothers walking in the streets wearing pure white, they want the evidence to be obvious when the police shove down and beat grandmother's bloody. They also want it to be impossible for the state to spin them as violent criminals
In short, these people are brave as f*
Many do suspect this will end in all out violence, but everyone knows that would give Russia an internationally acceptable excuse to join the party. The current thinking is Lukashenko may make a mistake (it is widely reported internally that he is on heavy medication and typically takes an entire month away from office following the election period, which has been impossible with the constant mass protests). His family has begun to leave the country, excluding his young son who he takes with him everywhere.
The people are being careful to say, at least for the time being, they do not want him dead, they only do not want him in the country. They're trying to give him every opportunity to flee and leave them to repair their own country
If you want to help, the biggest thing you can do is continue to give them international recognition. Share it on social platforms. After the first wave of violence, the international outcry caused Lukashenko to order the police to temporarily stop the beatings. The protests have continues to grow, and the violence has started again (as we all know, dictators have a really small playbook of possible control tactics). International outrage is more effective than you might realize.
EDIT: For those unaware, IT has grown significantly in Belarus. It's debated why this is the case (e.g. perhaps the dictatorship just does not know how to extract value from a company where seizing assets just leaves you with an empty shell of a previously valuable company), but regardless multiple Belarusians are entering the world stage with a reputation for being competent/capable/innovative with technology. It's been a interesting emergence of a new skilled class. Right now, Lukashenko is squishing that with his actions. Shutting of the internet is one example. Another example is retaliation, such as what is being done to PandaDoc (a Silicon Valley-based company). Their founders are Belarusian. After a statement by the founders, the state retaliated by raiding their Minsk offices and arresting employees. For more info, see https://savepandadoc.org/en/
> 76 did not respond, and 140 reacted to the issues within 20 days. We evaluated all of the responses for 140 repositories in order to identify developer perceptions concerning cryptographic APIs.
Developer responses: * 46 - It's not really a vulnerability
* 32 - Request for more explanation
* 17 - Open a PR
* 15 - Repo no longer maintained
* 10 - Oracle JCA documentation is ambiguous w.r.t. issue raised
* 7 - I will get to it later
* 5 - It's a dependency, not my code
* 3 - Repo has vulns for learning purposes
A lot of these are fair plays for an open source maintainer. IMO the quotes from the maintainer responses are quite interesting. The authors have a bit of an axe to grind in their rebuttals to each point.The largest bullet ("It's not really a vulnerability") is a bummer, and it mirrors some of my own experiences with reporting security issues internally. With about half of my reports, the response is "because of X, this is not a problem", where X IMO boils down to "I cannot imagine how this could be abused, so I don't think it's a problem". Basically, send a proof-of-concept or GTFO. In some cases I have gone on to make a PoC just to get the issue resolved. In others I get too tired of arguing that the code is clearly broken and the fix is easy to apply and just move on.
Sometimes there is no help. For one of my customers I submitted a simple curl PoC. It broke into their stack and got sensitive data easily. They "fixed" the issue, but did not bother re-running the PoC. It still worked. I pointed out the fix was incomplete, and was told "that issue was already fixed". I re-submitted the PoC as a new issue, this time with a one-line code patch that resolved it (a broken regex that allowed partial matches). It's still pending.
It's not my intention to say "it's all bad developers" - in the work they also point out that the majority of developers trust and rely on the official Oracle JCA documentation. It was referenced commonly in the github issue responses. The authors point out that the JCA docs are quite incomplete, not mentioning typical constraints for common parameters (e.g. should "iterations" be 1, 10, or 10000? You don't know from the docs, it's just asking for an integer value).
I understand Google's business position, but it was a shame to let an entire market segment die overnight.
Sadly my Re2 preorder has been delayed so long I went ahead and ordered an iPad so I could get down to work. iPad, and especially the apple pencil, has been incredibly useful and I'm looking forward to a head-to-head comparison. No longer sure I'll be keeping my re2
The main issue was ECR has a slightly different authentication model than docker swarm. The whole '--with-registry-auth' only partially works when you are using ECR. Unfortunately, it works just enough that you think it's working, until all your tokens time out and a worker can suddenly no longer pull an image.
Our common failure case was an image becoming unhealthy or a node being drained. When that image would try to be restarted on a different worker, if that worker did not have the image it would try to get it from the registry. If the tokens were expired it would fail.
The only "fix" we ever found was to setup a cron job that forcibly deployed a new version of a "replicated globally" image every X minutes (where X was based on ECR token expiration). It kind of worked, but we still had occasional failures we could not identify.
I wish it worked better, because it was nice to use ECR. Frankly token expiration sounds much more secure too, but without direct support for token refresh inside the docker engine it's just hard to get everything to work
One big change in the last 2 years is documentation on "how to use this image" has become more common. Figuring out how to use an image used to take hours - inspecting it's internals, learning the config files for that specific tool, modifying just the lines you needed, or write/mounting a custom file/folder, etc. Now, many images have docker-compose examples, and many images have loader scripts that can read env variables and configure themselves properly. Having a good entrypoint.sh is a huge benefit to a docker image's usability, and having a docker-compose example is good documentation
Why did I switch back? The isolation finally became significantly more useful for me. Perhaps the range of my 'hobbies' increased - I started running many more technologies. Multiple tools had conflicting dependencies, or only supported super-old options (looking at you, Unifi Controller still depending on the EOL mongo3.4)
Yea, you are probably right on the money.
IME lots of folks struggle with DRY when trying to actually implement their services. In teams I work with, we frequently see attempts to build a shared library and have to re-hash the discussion every time
Not sure you read my post. I called it a "mangled over-engineered monolith"
Pretty sure that's the point OP was trying to make - they put in the effort to build microservices, and crappy tooling means they are instead stuck with an mangled over-engineered monolith
Discovered after ~10 years
I'm pretty good with TLS, but could use more hands-on time with openssl and PKI, especially a deeper understanding of certificate chaining issues. Would be interesting to know if the training is targeted at "total beginner" or "intermediate looking to be advanced"
This is interesting and will take some introspection, but perhaps I can improve these situations by fostering better communication. Thanks for taking the time to respond.
For those of us with less insane needs, they also exposed an API to grab the specific digits of interest - https://pi.delivery/
Copyright law is unchanged. If someone scrapes your blog and then re-uses your posts on their own blog, you still have possible copyright infringement claim
Not in my experience. The problem is not technical talent, it's culture.
That's not to say it's impossible to solve these issues, only that a culture of top-down "get it done" does not tend to mesh well with the rigid discipline needed to make a secure product. Ever had to say "no" to a general?
On any system built in house, there will be management feature requests which force security compromises. For example, "We must archive the data of this comms network - we have a legal requirement to do that!!" or "We need to ability to access user's data for internal/external investigations", etc.
Solving these issues in a secure manner is incredibly hard, and IME it can be incredibly difficult to explain to someone non-technical why "just do X" will harm the security posture. More often than not, a developer (with their salary paid by the boss) will be forced into "just doing X" by someone who does not truly understand how much that compromises the system. Boss will be happy, thinking they "pushed it through" and non-crypto developer will be happy thinking "it has some authentication applied so must be secure" while cryptographer will be largely ignored or misunderstood. (Note: not a cryptographer, but I am an expert in other domains and have worked with enough to see their pain first hand)
Most non-cryptographers on the project start to get confused, typically thinking all of the compromises are OK because they only open doors for the DoD and that is who the product is for, without having the training or knowledge to realize how problematic this thinking can be. IMO - listen to your cryptographer, you hired them for a reason.
Found it a bit sad to see this notice followed by a recent news headline saying the project was guaranteed to continue:
Continuation of the free database guaranteed
With the acquisition of the www.freedb.org domain
MAGIX also takes on all duties regarding the
worldwide freedb communityI opened the 'Why' tab and found blurbs I wanted to see more about. For example, security through smaller code+attack surface sounds interesting, 'no ops' (didn't grok the bullets here, but I was interested to know more), and higher performance are all interesting
The bullets were interesting enough for me to want more, so I opened the video.
Unfortunately, the video was really vanilla and didn't expand on these concepts at all. It shows how easy ops.city is, but gives me nothing more on why it is better than ten other technologies that have similar 'easy intro' videos.
What I was hoping for was a 5-10 minute video focused on benefits of your approach vs alternatives. For example, some talk or demo on improved performance, data on how much code/attack surface is reduced, comments on OS/kernel memory footprint (this is a problem for us - clients like using 500MB "tiny" VMs on public clouds that hang running cadvisor), etc.
I could leave your site to answer these questions on my own. I did this and found some promising looking links over on the nanovm website. But that is an awkward experience - leaving your site to try and understand your offering.
Perhaps I'm not your target audience. For context, I do a minor amount of devops as part of delivering initial R&D products to multiple clients. We are not ops experts, but we try to deliver future proof work, which involves us staying apprised of new approaches and making them available to clients when they are a fit.
Everyone in a shitty position has a right to speak up. You're absolutely right that some people cannot exercise that right - they can't risk losing what they have. That is unfair to every single person in that situation (and personally, I find this to be a shameful reflection on the world).
But using that to justify that other workers should stay quiet is equally wrong. It's using something wrong happening to one group of people to justify something wrong happening to another group. Even if you don't believe the moral reasoning, there's the pragmatic angle - this attitude leads to overall worse employee treatment. If 'better off' workers are shamed into not discussing poor treatment (because they should be embarrassed complaining about such trivialities), then minor poor treatment is allowed to escalate unchecked.
In my opinion, a better approach overall is to think "all of us have some rights, including good treatment by an employer and a right to a life not straddled by anxiety or debt". Anyone crusading against that is on the same side.
I totally agree that we are very, very far from a consumer (and perhaps even an enterprise) product. However, it does seem to me (based on scientific papers, news, and patent filings) that the Chinese take quantum networks seriously and are pushing hard to get a government network. IMO, this network would come with all the limits of new technology (slower than you would want, fewer guarantees, etc) but with all the advances of spending hundreds of million to be the first creating a new significant technology.
If you're aware of these points already, and still believe them to be wishful thinking, I would be curious what makes you say that
"Your nines are not my nines" - https://rachelbythebay.com/w/2019/07/15/giant/