2,429 karma · joined December 1, 2014
Zinc supplementation may of course help if you are deficient, but the study can't really tell if 'healthy' Zn2+ concentrations contribute anything to the inhibition of viral replication.
- https://fahrplan.events.ccc.de/congress/2019/Fahrplan/events...
- https://media.ccc.de/v/36c3-10597-tamago_-_bare_metal_go_fra...
[1] https://en.wikipedia.org/wiki/Michael_Foot#In_popular_cultur...
[2] https://www.newspapers.com/clip/39001580/foot_heads_arms_bod...
However, they could at least define expected and minimum capacity. They might omit it because the business in this – aside from capturing users in their ecosystem – is arbitraging wholesale GPU price against consumer monthly needs, along with scaling the free tier.
[1] "Why aren't resources guaranteed in Colab Pro?" on https://colab.research.google.com/signup
[1] https://en.wikipedia.org/wiki/Environmental_impact_of_aviati...
There seems to be a pretty active forum here: https://www.xcore.com
When I pressed them on this considering the supreme court decision Van Dale/Romme [4] (which is very similar to Bridgeman Art Library v. Corel Corp. [5]), they responded with the following:
"First of all the Supreme Court decision in Van Dale/Romme is not about photographs but about a collection of factual data. In this decision the Supreme Court determined when a work is protected by copyright. In our opinion the photographs that we offer on our website do comply with these criteria. The photographer had to make creative decisions in repect of lighting, illumination time, shutter speed, distance, angle etc."
"Secondly, the photographs are our property. We have invested in the making of these photograhps. Since the photographs are our property, we can decide when and how the photographs are used and by whom. We can set the terms and conditions. If you order photographs from our website, you are bound by our terms and conditions. If your use of the photographs violates these terms and conditions, you will be in breach of contract and we are entitled to take legal action."
"You or your client are free to make products with the paintings of the painter Van Gogh, but if you would choose to do so with our high res photographs and therefore want to profit from our efforts and investments you will have to comply with our terms and conditions. If you do not want to pay the requested compensation for the use of the photographs, we suggest you use some other pictures or photographs."
"Please note that our museum has to be self-sufficient. The exploitation costs of an art institute like the Van Gogh Museum are considerable and all our income is invested in the exploitation of the museum. The compensations we ask for the use of our photographs help us to keep the museum up and running."
They seem to admit that anyone would be free to make (high-resolution) copies of Van Gogh paintings, while at the same time claiming that they own the copyright on the high-resolution images files that they created and sell.
[1] https://www.vangoghmuseum.nl/en/collection/s0005V1962
[2] https://cdn.vangoghmuseum.nl/1/4/1791/1/beyXX73TgUY8hhFrzwKg...
[3] https://www.vangoghmuseum.nl/download/71396fdf-e8ce-4b37-90e...
[4] https://nl.wikipedia.org/wiki/Arrest_Van_Dale/Romme
[5] https://en.wikipedia.org/wiki/Bridgeman_Art_Library_v._Corel....
Gossip networks indeed don't scale very well when not all participants want to communicate with each other (perhaps simplified as "don't already have a social graph connection"). But nothing in the example of kernel development necessitates to involve the entirety of the world.
Gossiping can be done over a medium that inherently reaches only an interested subset of people, either by self-selection or moderation. Trivially, you could start a verifiable gossip network on top of the kernel development mailing list, where most interested people have subscribed themselves.
SSB instead implements pub servers, which can be designated to contain gossip with a common topic. If and when gossiping becomes inefficient, you simply shouldn't continue to gossip indiscriminately; centralize and federate a bit, but preferably don't become reliant on a central logistical point.
It's currently heavily focused towards The Netherlands, where citizens can obtain attributes such as name, home address and age. These attributes can then be selectively disclosed directly to a service provider, without the identity provider being able to see the transaction [3]. Multiple disclosures are also unlinkable as long as the attributes themselves are not identifying.
The fact that the identity provider is not at all involved with the transaction is an enormous privacy win compared to OpenID Connect, especially in the case of centralizing providers such as Apple – and less so in for example the domain of education single sign-on.
It's not currently using the verifiable claims data model, but it would very much fit it. It also doesn't use a 'blockchain', simply because it's not necessary to do so, and makes it all a lot less complicated.
[1] https://github.com/privacybydesign
[2] https://privacybydesign.foundation/publications/
[3] https://privacybydesign.foundation/meeting-slides/slides-8-3...
Unless of course it satirizes product satire, in which case it actually turns out to be a product.
It's currently heavily focused towards The Netherlands, where citizens can obtain attributes from the Dutch civil registry, such as name, home address and age. These attributes can then be selectively disclosed directly to a relying party, without the identity provider being able to see the transaction [4]. Multiple disclosures are also unlinkable as long as the attributes themselves are not identifying.
It's not currently using the verifiable claims data model, but it would very much fit it. It also doesn't use a 'blockchain', simply because it's not necessary to do so, and makes it all a lot less complicated.
[1] https://itunes.apple.com/gb/app/irma-authenticatie/id1294092... or https://play.google.com/store/apps/details?id=org.irmacard.c...
[2] https://github.com/privacybydesign
[3] https://privacybydesign.foundation/publications/
[4] https://privacybydesign.foundation/meeting-slides/slides-8-3...
We're looking for a part-time/freelance mobile developer with an affinity for security and privacy to work on our mobile app and associated software.
- We're primarily looking for someone strong on the frontend who can implement smooth interactions, and make a complex topic intuitively understandable in an interface.
- You'll be working on top of a cryptographic protocol and client that tries to preserve the privacy of the user in everyday tasks.
- We're keeping an eye on Flutter as a technology that offers performance and a well-rounded set of official components for mobile. Be sure to respond if you feel confident in this area.
- All our code is open source. That also means the code you write is yours to take anywhere.
- We pay a decent rate (or salary), but it will probably not be the top amount.
See my HN profile for contact information.
Also, for example, he said "[people talk about] senior R&D employees", but it is subtitled as "a wave of employees".
The three points above are accurate however.
Main points raised there:
1) This story is about four employees, who were not closely familiar to the core technology of ASML.
2) Looking at the circumstances, it seems far more likely that this was an action by ex-exployees with commercial motives, rather than government-sponsored spying.
3) ASMLs core technology simply remains in The Netherlands. An anecdote: 15 years ago ASML came with the most advanced lithography scanner of that time. It was copied in China to the last screw, but the device simply didn't work, because they lacked intricate knowledge on its actual operation.
[1] https://www.npostart.nl/nieuwsuur/16-04-2019/VPWON_1297076
Reporting each and every condition, however unlikely to be caused by the subject of study, is a necessary part of a study into adverse effects. And for good reason, because it allows later research into surprising causal links, by evaluating mere correlations from different studies.
It doesn't mean the participant thought the adverse effect had anything to do with fasting.
- There is no composition of images, but only inheritance
- Shell scripts can't define any environmental variables that will survive beyond the script itself
- Docker doesn't have any way to take or template values from other Dockerfiles
That means that you might be able to separate RUN logic out into shell script (like the method deck-build proposes), so that you can compose multiple tools into the same image. Still any ENV variables that your tools might need (if only a simple $PATH) need to be manually copied into the composing Dockerfile and maintained when changes occur.
I think that's a broad generalization, perhaps of your own experiences. There are enough people on the cutting edge that you can constructively talk with.
But remember it's still a meritocracy: 'they' might listen to you, but will only take you seriously if you present your own work to them.
All the examples of decentralized software mentioned in the article are fully open source. They don't need to "give up control", because they are not necessarily in control.
It is of course true that they run the most used implementation of the software, and that the project is centralized around that. That's mostly a result of these projects being run as meritocracies; any person or group who wishes could aid in removing that initial organizational centralization. The original authors also simply know the most about running their own software in production.
Insurance companies may indeed pay more or less for 'well designed' vaccinations programs, and may incentivize vaccination in general in some locales as a long-term cost reduction program [2].
[1] https://seattlemamadoc.seattlechildrens.org/pediatricians-co...
[2] https://vaxopedia.org/2017/09/24/that-3-million-vaccine-bonu...
You make quite serious accusations en passant without much basis, other than that you find the tone of the article to be serving as a threat.
I wouldn't say I'm very comfortable with the article, but I'd think members of the editor staff – which by design should be shielded somewhat from the influence of their owner – would have a hard time themselves to figure out which tone to cling to.
The quote you included seems very factual otherwise.
With a nifty and I think necessary touch of themselves still being in the dark; I very much doubt that the data they gathered can really reveal the author's identity, and the result they arrived on (Tom Dale) seems to largely originate from the "quotes one person far more than others" metric.
You could almost consider it an anti-metric: which intently pseudonymous author would dare to retweet their own nym? However, to counter this analysis you'd have to blend in with the average Twitter user in your niche, so it then comes down to a psychological game of "what would horse_js do?".
Your argument, and you see this nihilistic tendency often in privacy discussions, is also based on some strange notion that if your privacy has been violated once (and you didn't voice your disapproval), it may be acceptably violated again. I see no reason for this to be.
If it's an actionable thing I then categorize and schedule it, but I also have a large 'Maybe' list for unwieldy project ideas (52 items and counting).
For random daily or project notes I use a small shell script (and Dock application, via Automator) that creates a daily file and opens the containing folder in an editor:
touch "~/notes/$(date +%Y%m%d).txt"
$EDITOR ~/notes 1>&2 2>/dev/null &
As every Scuttlebutt node is equal to every other node, that makes it a distributed, rather than merely decentralized, protocol.
The comment you replied to didn't include that condition, and I'd be reluctant to state some arbitrary percentage – as you conjure up 5% – to be 'meaningful'. A larger keyspace is strictly more secure against an attacker trying to guess the key.