I wonder if one has ever been successful in using the data access and protection laws (such as GDPR) to request access to his file and interview feedback.
2,783 karma · joined August 9, 2011
https://marti.us/ (personal webpage) https://marti.us/w/ (index of my articles)
github: martiusweb bluesky: @marti.us
I've got the impression that highly-compressed content is often so popular that bigger/higher quality files are hard to find.
There are different kinds of backups here:
* the ones that are part of the offer, where the provider gives you a convenient way to recover from your mistakes, this is a feature they provide when their services are operational (in this case, the snapshots feature).
* the ones they put in place to mitigate incidents and maintain their SLOs. If you accidentally delete a file, you don't have access to them, they are useless to you. These backups are a mean to reach their service level objectives. Nobody can offer you 100% guarantee that they won't lose your data in an SLO. If someones promises you this, just... don't believe it.
(edit: formatting, typo, mention snapshots in case 1)
I read this as:
* if you interacted with people on mailing list with your personal email address, it's OK to use your personal email address in the patches.
* if you are the maintainer of a project, use your own address (unless this is a google project, of course).
edit: don't get me wrong though, I don't like this clause, I just think it only matters in rare cases.
Worse being "your skills are to be used exclusively for the benefit of Employer". That means that you can't do freelance work, or open source contributions. In theory, you're not even permitted to fix your parents printer.
While I'd prefer not to think about all this and just code, I appreciate that there is an existing policy instead of a bad surprise in a few years.
The current policy, which is 100% public (https://opensource.google/docs/iarc/), is basically "let's assume that we own everything except what we don't, and let's figure things out before it's too late".
If you contribute to an existing open-source project on github, this is basically a non-issue and the answer to who owns the copyright has practically no effect. There are pre-approved licenses and a few banned licenses (agpl, wtfpl, public domain, etc), as well as pre-approved CLAs with major entities (Python, Mozilla, etc).
I think this matters in two cases:
1/ you want to start a new open-source project, you don't want google to have copyright because you think that a good open-source license will not protect you/your work from being stolen (!).
2/ you want to start a side project and maybe one day you'll turn that into a business, and you don't want to be Pied Piper vs Hooli.
This makes me think that it's not a feature on the roadmap of firefox sponsored by Mozilla, but an experimentation/side project.
As an example, asm.js, the technology which became Web Assembly has been invented by Mozilla folks.
I'm saying that employees of a company probably don't antagonize the others like that.
> Mitigation work is currently underway by our engineering team and is expected to be complete by Wednesday, 2019-11-13.
The fix/mitigation is being rolled out.
> Workaround: Users seeing this issue can downgrade to a previous release (not listed in the affected versions above).
There's a workaround for end-users (downgrading to a version which is not affected),
Also:
> the number of projects actually affected is very low.
(disclamer: I'm SRE at Google)
Especially if you can't or don't want to use memory mapping because it's hard to do well.
But more importantly, I think that the server can monitor file changes ahead of time with things like inotify, saving the time of stat()-ing files when the user wants to perform a build.
A minimum would be to have the recruiter explain why they thought the CV was worth a review and the engineer can then correct them.
Also, in the companies I worked for, recruiters where checking GitHub or LinkedIn when they needed more signal.
My intuition is that if my CV is ignored by a recruiter, it's because engineering is not involved enough in the sourcing process for the company, and that is a terrible signal.
While I sometimes enjoy watching trailers for other films in the "bonuses/special features", when I buy a film (whatever the price), what I want is to watch the film:
I put the disc in the player, I press play a couple of times after I chose the spoken language/subtitles, and then, I watch the film.
Even if you can skip them, I really dislike the sequence of trailers, ads, "FBI WARNINGs", more ads, "enjoy the full experience of ULTRA HD", THX deep note, yet more ads.
> Today, we’re rolling out the open-source version of the differential privacy library that helps power some of Google’s core products.
It's not a big deal for users of Homebrew or other package managers.
It's not the first time that I'm seeing reactions about this report to focus on veganism. I don't understand where it comes from: the word "vegan" is absent from the article and the IPCC report doesn't recommend a any diet.
I understand debate about this report and the impact of agriculture and breeding, but I don't understand why the debate is centered around veganism.
It indirectly helped my carreer: It gave me confidence that I could be an occasional contributor to OSS. I learned valuable things when doing each contribution.
I think that citing this example every time "hiring at Google/Big tech" is discussed on HN is useless.
We know that there are a lot of false negative and and lot of chance in the hiring process (so many things can fail in a process involving so many steps and people).
There are also legitimate rejections, like hm, bold statements ("90% of your engineers use my software"), fingerpointing or not being able to seek for assistance when you don't know something.
I discussed interviews with many people, and I'm convinced that solving the problem with the theoretically-optimal solution is not the only way to get a positive review. Being open about things I didn't know helped me: for instance "Hm, I'm not sure about how to do this exact thing, I'll use the function do_this_thing() and implement it later if I still have time, if that's OK for you" buys you time and allows to keep the discussion focused on the main problem.
> In the last 10 years I've never met a case where someone pointed out that "this code needs to be concurrent, but single threaded".
> Going back to concurrency - have I ever been constrained by the number of threads I can use? No, not even once.
Well, in the past 10 years, people have been working on the famous "c10k problem", about how a server software can handle a large amount of concurrent connections, since the model 1 thread/connection doesn't scale (the general purpose kernel scheduler will eat most of the CPU).
This is a real world problem.
> Do people use coroutines?
Yes they do, even if you claim they don't. I honestly don't know on which basis you can claim they don't.
> For me, this sums up the whole GIL and couroutines/asyncio debate. I think the main problem we have at the core of Python is that it's heavily inspired by C. But I think in this case it's Python's weakness.
I can't see a link between the GIL, C and coroutines.
One thing though, using an IO multiplexing framework when doing batch processing is probably suboptimal as using independent processes or queues will have the benefits you point: easier to read and understand, and less contention (kudos to my friend iksaif for the highlight). However, celery is a solution for some use cases, but will not work for many of them. For a similar queue-batch-work problem, executors can be a tool which fits someone needs better than celery (https://docs.python.org/3/library/concurrent.futures.html).
> I think that if we want to support full concurrency in Python, this is the way to go. Introduce primitives for fully lockless paradigm using queues and enable programmers to define queues.
Queues introduce head of line blocking (hence latency). You need several queues to handle independent and concurrent events in a timely fashion. This is why you need to multiplex.
> I think we never really wanted concurrent code, as programmers. I definitely never wanted coroutines and never needed to multiplex I/O.
Yes again, we do. That's how an interactive system works, that's how your computer works: one giant event loop handling concurrency between tasks and hardware inputs.
(update: words about concurrent.future executors)