No offense, but the blog post is seriously missing a better (or any?) explanation of what's the new JIT all about.
At first I even thought my browser loaded only half the page...
That's all well and good, but you need to raise that with your IT department if it is an inconvenience rather than complaining to us.
It seems odd that github would be blocked especially given HN isn't unless your company has some sort of pathological fear of accidental IP dilution, so perhaps it is a mistake that will be quickly corrected once pointed out?
my coworker's previous employer blocked all code-sharing and question-and-answer sites for programmers because of a pathological fear of accidental IP dilution. it's a real thing.
That it is, although what they end up doing is making people work on their work machine as well as their cellphone. Source: me, working for a defense contractor with the same insane rules, but no "hand in your phone" rules on entry.
What’s wrong with him asking for assistance? You could’ve just ignored his comment lol, no need to be so rude. Im dissappointed anyone upvotes you. This is bad behavior, shouldn’t be promoted.
I didn't read it as a request for assistance, more a complaint that we weren't doing enough to assist by providing a link that would work in the specific circumstance that the poster finds themselves in (that we could not have known about ahead of time even if it was something we should be responsible for fixing or working around).
And I did offer assistance by suggesting the only practical way forward (unless you count HN banning github links because some of its readers can't access them as a practical way forward!): discussing the matter with the IT department. Especially as it _could_ be a mistake (externally sourced block lists being overly aggressive unbeknownst to them?) rather than a deliberate action. And if it is a deliberate action the poster may need to investigate what policy the block is part of to make sure they are not accidentally breaching it by other actions.
> no need to be so rude.
I used the exact same tone in my reply as I was replying to. A little passive-aggressive maybe, but if I was rude then so was what I replied to. I know two wrongs don't make a right, but then again neither does the first one on its own so I've not made the situation any worse.
Added: if you think I'm joking or being unfair, just look at the compensation tables for just about any government outfit. They top out around a salary that is considered average for software folks in some places.
I know that that is typical, but there are exceptions, and if you work for the right agency you can be paid well, so I don't want to make any assumptions.
If he's not paid well then I hope he realizes that by merely being aware of HN and GitHub puts him in the top 10% of developers and he can do a lot better than working at a place that restricts his ability to educate himself.
Oh, I'm a contractor and I'm paid decently, but the working conditions are terrible. I've been trying to find a job outside of defense/govt work for a long time, but either the pay isn't as good (the one or two times I managed to land an offer) or I'm not a "cultural fit." Not having a network outside of the govt bubble makes it hard.
Hi there, James. I'm a software engineer at Google. I've worked with many former government and defense contractors here whom I would consider some of the best engineers. Please send me your resume (or anyone else with a similar situation!); my email is in my profile. We have offices all over the US (but not Florida) so the bay area wouldn't be a requirement.
Man, I grew up in Brevard, and I wish I could work there, but unfortunately all the software jobs are for defense contractors. You'll probably have to work remote if you want to get out of the defense bubble.
1) Not work related typically really means “not whitelisted” so often sites that would be beneficial to the employee completing their jobs will also be inaccessible.
2) Since everyone has smartphones they will just access the same sites with their personal device which is more time-consuming.
Because, the ones who block stuff often don't keep up with what is work related. So in the end you have to write lots of e-mails until they notice that you are one of the few users that should be allowed to use the whole internet.
Eventually, one day they will find out that their blocking is too strict and that they should restrict the blocking to sites which actively try to attack the users computer...
So it is more of an execution problem, but as it fails quite often you could call it stupid to invest into such a feature.
I'm truly sorry that GitHub is blocked where you work.
Here's the pitch, taken from the repo's README [1]:
1) holyjit aims to be easy:
> As a user, this implies that to inline a function in JIT compiled code, one just need to annotate it with the jit! macro.
jit!{
fn eval(script: &Script, args: &[Value]) -> Result<Value, Error>
= eval_impl
in script.as_ref()
}
fn eval_impl(script: &Script, args: &[Value]) -> Result<Value, Error> {
// ...
// ... A few hundred lines or ordinary Rust code later ...
// ...
}
fn main() {
let script = ...;
let args = ...;
// Call it as any ordinary function.
let res = eval(&script, &args);
println!("Result: {}", res);
}
> Thus, you basically have to write an interpreter, and annotate it properly to teach the JIT compiler what can be optimized by the compiler.
> No assembly knowledge is required to start instrumenting your code to make
it available to the JIT compiler set of known functions.
2) holyjit aims to be safe:
> Security issues from JIT compilers are coming from:
> * Duplication of the runtime into a set of MacroAssembler functions.
> * Correctness of the compiler optimization.
> As HolyJiy extends the Rust compiler to extract the effective knowledge of the compiler, there is no more risk of having correctness issues caused by the duplication of code.
> Moreover, the code which is given to the JIT compiler is as safe as the code users wrote in the Rust language.
> As HolyJit aims at being a JIT library which can easily be embedded into other projects, correctness of the compiler optimizations should be caught by the community of users and fuzzers. Thus leaving less bugs for you to find out.
3) holyjit aims to be fast
> Fast is a tricky question when dealing with a JIT compiler, as the cost of the compilation is part of the equation.
> HolyJit aims at reducing the start-up time, based on annotation made out of macros, to guide the early tiers of the compilers for unrolling loops and generating inline caches.
> For final compilation tiers, it uses special types/traits to wrap the data in order to instrument and monitor the values which are being used, such that guard can later be converted into constraints.
> Moreover, the code which is given to the JIT compiler is as safe as the code users wrote in the Rust language.
> As HolyJit aims at being a JIT library which can easily be embedded into other projects, correctness of the compiler optimizations should be caught by the community of users and fuzzers. Thus leaving less bugs for you to find out.
