> How would a company even determine if I'm worth hiring
> and going through all the work to get me a work visa
> if they can't even interview me in person?
No company will hire you without an in-person interview. Most companies will pay for your plane tickets and hotel for an in-person interview.
A note on in-person interviews:
You will probably be flown to Europe and do the interview in English. Most English speakers in Europe learned it as a second language. If you learned English from a local Somali school, your interviewers will not be used to your accent and may have a hard time understanding you. You should practice your accent until you sound close to British or American.
> Would they tolerate my crappy internet if they try to
> interview me over Skype?
Is your connection good enough to do a voice call at high quality? If it is, that should be sufficient.
Otherwise, you'll need to find a way to skip the initial phone interview. Most software companies do phone interviews to screen out candidates who are not capable of programming. A good substitute is a portfolio of personal projects on GitHub, showing experience with the programming languages you put on your resume.
> What if the position was for something mid-to-entry
> level and not some key position.
This will depend on the size of the company. I work at Google, and the legal department here will handle the immigration, visa, and permanent resident process even for regular low-level engineers. Smaller companies will be more selective.
> No company will hire you without an in-person interview.
That's not at all true... We (Silent Circle) have hired plenty of people without any sort of face-to-face conversations. It's not uncommon for someone to work for us for several months before getting the chance to meet some else in the company face-to-face.
The anti-GG side claims that no reasonable person would expect journalism about video games to be ethical or free of corruption. Therefore, the "true" purpose of GamerGate must be something more sinister.
1. Many of the gaming journalists GamerGate have specifically called out as unethical (Nathan Grayson, Ian Miles Cheong, Shanley Kane, Arthur Chu) are public advocates of identity feminism.
2. Gamer culture, in general, leans more toward equality feminism. Many of the gamer bloggers doing the calling out (Georgina Young, Jennie Bharaj, Angela Night) are public advocates of equality feminism. Christina Hoff Sommers, the founder of equity feminism (a related branch), has issued several pro-gamer videos.
3. Identity feminists consider equality feminism and equity feminism to be reactionary, misogynist, anti-feminist movements.
With these factors combined, you get a category 5 internet shitstorm. Wealthy white men are writing newspaper articles denouncing women as misogynists, because those women wrote blog posts calling out the journalists as corrupt.
The Jones act is for cargo. The equivalent for passenger ships (including cruise liners) is the Passenger Vessel Services Act, and it has a number of exemptions carved out for popular cruise routes.
For example, http://cruise.expedia.com/Itinerary5.aspx?item=849031 is a foreign-built foreign-flagged ship that departs from San Francisco, docks in Los Angeles, and has a final destination of Miami. This is permitted because the itinerary includes a port outside of North America.
Plus, the PSVA is implemented as a monetary fine. There are cruise lines that will let passengers violate PSVA for an additional fee.
> That's a no-go for many setups. It doesn't integrate well
> with how Linux distros usually start services (systemd,
> upstart, sysv init, ...)
Change the daemon config file to use a small wrapper script, which initializes the SSH environment and then execs the target binary. Assuming a reasonable setup, this should be trivial.
> At this point you could have used ssh right away, no?
> Any reason you used TLS + checking SSH agent instead?
It sounds like they take an SSH identity certificate from the agent, send it via TLS, and then the remote process verifies it. This would have fewer potential security issues than trying to lock down a user's SSH login shell.
> Change the daemon config file to use a small wrapper script, which initializes the SSH environment and then execs the target binary. Assuming a reasonable setup, this should be trivial.
Well, the point is that the ssh needs to have forwarded agent from somewhere else. If the host on which the service is run can initiate it, the whole security aspect is gone.
> This would have fewer potential security issues than trying to lock down a user's SSH login shell.
Locking down a login shell (usually be not running a shell in the first place) is a solved problem, and for example gitolite uses it has the base of its architecture. Yes, you have to be careful, but you must also be careful when manually validating certificates.
This sounds like a pretty standard bastion server configuration. The use of SSH is novel, usually I see the bastion address provided as a command-line option and a TLS certificate used to authenticate the client.
> When the world around you doesn’t give you feedback,
> and the best gauge you have of your own noise level is
> frustration on the faces of the people near you
People laugh at HN suggesting technical solutions to every problem, but this really does seem like something that could be solved (or at least mitigated) by a microphone, some small LEDs, and a gutted wristwatch. Light up more LEDs depending on how loud the sound is relative to the average level of the previous N seconds of recorded audio.
A web search for [wrist sound sensor] didn't find anything relevant, but this is probably because I don't know what such a device would be named.
edit: Following the trackback at the bottom reveals the author is a hardware hacker. I wonder if she has tried to build such a device -- if not, maybe it's much more complicated than it seems.
A similar tool, though not designed for exactly that purpose, is a sound level meter or a loudness meter. There are small handheld ones, but I don't know of any that could be worn on a wrist or that have a useful UI for a deaf person.
> every other language which uses a package manager has
> one that works out of the box without any hassle and
> without any sandbox tricks.
Trying to do any sort of open-source development without a library sandbox, in any language, is madness. OS package managers are completely unable to deal with multi-version dependency graphs. NixOS is no different, unless you want to install the cartesian product of the possible combinations -- how much SSD space do you have?
My experience with Haskell leads me to believe that "Cabal hell" is an artifact of certain library developers' API versioning philosophies. Namely, they release numerous libraries all depending on each other with tight version bounds, and change the API regularly. This behavior is fundamentally incompatible with dependency resolution in a compiled language.
Say you have four libraries:
foo-1.0 depends on bar==3.8 and qux==1.5
bar-3.8 depends on baz==0.2 and qux==1.5
baz-0.2 has no dependencies
qux-1.5 has no dependencies
Then tomorrow you want to release an API-incompatible version of qux and use those new features in foo:
foo-1.1 depends on bar==1.1 and qux==1.6
bar-1.1 depends on baz==1.1 and qux==1.5
What do you do here? There's no good choice. Two versions of qux can't be linked into the same binary, and the tight API versioning prevents Cabal from being able to construct a coherent package set.
Now imagine that instead of four libraries, it's O(50), and they're all changing regularly.
Writing lots of tooling and writing manifestos against Cabal sort of helps, for a bit, but it's a lot of work and is deeply unsatisfying for the kind of person who likes to make progress on other goals.
IMO the only practical solution is to loosen the dependency version bounds, and commit to maintaining API compatibility for several releases. I have never encountered Cabal hell when using packages with reasonable versioning philosophies.
> Trying to do any sort of open-source development without a library sandbox, in any language, is madness.
I agree, but there're some interesting differences in how different language tools implement a sandbox.
Python and Haskell (with Virtualenv and Cabal-dev/sandbox) have separate local repo/caches in which packages are installed (this is useful if you want packages in a reliable location to install executables)
Ruby and Clojure (with Bundler and Leiningen) have a common repo/cache with multiple libraries version, and the version resolution is handled inside the project itself (e.g. when you need to whip up a repl or build the project)
(I'm not mentioning rbenv or the like, since that doesn't handle version graphs by itself... but obviously it can be used just like Virtualenv)
IMHO, the second approach is better suited for a language (implementation) that has an explicit compilation step in which an artifact/binary is built, just like for Haskell/GHC
(then again, something like the first approach is still useful for executables and maybe also to try out different compiler versions)
> Two versions of qux can't be linked into the same binary
It might be possible, but yes... it's a world of pain
I think a big part of the issue is that - because of the way Haskell's cross-module inlining works - you need to generate different artifacts not just for each version you use but for each set of dependencies chosen for each set of flags set for version you use. I think this strips away much of the benefit of the second approach.
Pick a language where developers are not so cavalier with backward compatibility?
Java has Maven which allows you to exclude transitive dependencies for such situations, and in more than a decade of developing with the language, I've only had to use this functionality a handful of times.
Developers sometimes mess up and break backward compatibility but this should be an extremely rare event. That or the compiler itself is terribly implemented and creating incompatible binaries just by bumping up versions (looking at you Scala).
I was far from a model employee at Google - I continued to post on HN, I would challenge executives as to whether their actions were really in the best interests of users, and I would raise complaints I heard about elsewhere internally - and I don't feel like it hurt my career progression at all. I was promoted during my time there, and I largely got my pick of projects. When my old manager left the department, he told me that one of the things he and his superiors had really valued about me was my willingness to call things out that weren't working.
I do think that there's a right way and a wrong way to criticize your organization. As Ben Horowitz says, "Come from the right place." When I would say something negative about Google it's because I want it to be the best company it could be, and I'd often raise complaints internally rather than externally because that's where the decision-makers are. And if you want to be taken seriously, you also need to buckle down and contribute, and listen to considerations you may not have thought of. My manager said once that the folks who get fired are those who "Complain too much and contribute too little", and I can think of some prominent personalities on Hacker News who fit that description. Complain and contribute and you do fine.
When they are first shown the room, they would think to themselves "the food is north of the blue wall". After being spun around they might not know which way is north, but they'll figure it out as soon as they spot the blue wall.