Entries Tagged 'OT' ↓

OK, so 2 things:

1. If you send me a CV and they're hired to work on self-driving algos – machine vision/learning/mapping/navigation, I'll pay you a shitton of money. (Details over email.) These teams want CS/math/physics/similar degree with great grades, and they want programming ability. They'll hire quite a lot of people.

2. The position below is for my team and if you refer a CV, I cannot pay you a shitton of money. But:

We're developing an array language that we want to efficiently compile to our in-house accelerators (multiple target architectures, you can think of it as "compiling to a DSP/GPU/FPGA.")

Of recent public efforts, perhaps Halide is the closest relative (we're compiling AOT instead of processing a graph of C++ objects constructed at run time, but I'm guessing the work done at the back-end is somewhat similar.) What we have now is already beating hand-optimized code in our C dialects on some programs, but it's still a "blue sky" effort in that we're not sure exactly how far it will go (in terms of the share of production programs where it can replace our C dialects.)

As usual, we aren't looking for someone with experience in exactly this sort of thing (here especially it'd be hopeless since there are few compiler writers and most of them work on lower-level languages.) Historically, the people who enjoy this kind of work have a background in what I broadly call (mislabel?) "discrete math" -  formal methods, theory of computation, board game AI, even cryptography, basically anywhere where you have clever algorithms in a discrete space that can be shown to work every time. (Heavyweight counter-examples missing one of "clever", "discrete" or "every time" – OSes, rendering, or NNs. This of course is not to say that experience in any of these is disqualifying, just that they're different.)

I think of it as a gig combining depth that people expect from academic work with compensation that people expect from industry work. If you're interested, email me (Yossi.Kreinin@gmail.com).

All positions are in Jerusalem.

I wouldn't spam you with these job offers if didn't work :-) So, we're looking for senior IT people to work at our Jerusalem offices – managers and hands-on people alike. We have rapid growth, "Big Data" (it definitely is crash Excel - in fact, at one point it was close to physically crashing through the floor due to the storage servers' weight, but luckily that's been handled), "HPC" (biggish server farms, distributed build & tests, etc.), and many other buzzwords [1]. I don't know where IT ends and DevOps starts but I guess a good candidate could have either in their CV, so there.

If you have qualified friends looking for a challenging, well-paying job at a fun place, send their CVs, the sooner the better – we're in a hurry (rapid growth!), so early birds are more likely to get the can of worms. As always, "challenging" is a downside as much as an upside (a place where IT means Exchange, SAP and little else might pay very well for a more predictable and less demanding job.)

We value experience in building and maintaining non-trivial systems, and technical reasoning (X happens because of Y, Z is most efficient if you use it to do W, etc.) We also value experience in higher-level areas such as management and purchasing, and business reasoning (don't hook X and Y together since their vendors compete and will sabotage the project, Z beats W in terms of total cost of ownership, etc.) We do kinda lean towards thinking of technical aptitude as a cornerstone on top of which solid higher-level expertise is built. (We've seen managers snowed by vendors, reports, etc., which is a perennial problem in tech at large and isn't restricted to IT.)

If you'd like to hear more details, please email Yossi.Kreinin@gmail.com

[1] what we don't have is a heavy-duty web site/application, which might make the position less relevant for some.

Unlike most positions mentioned here, this one includes the possibility of working remotely (certainly from Europe and I think from elsewhere, too), with occasional visits to Jerusalem.

Functional safety experts with automotive experience are generally rare and in demand, meaning that

• they're probably gainfully employed, and
• I'm not counting on one of them reading this blog.

However, I imagine that a friend of a safety expert might be among my readers. If you're that reader, you can tell your friend the safety expert that we're very eager to hire them, and will go a long way to make an attractive proposition.

We particularly value experience at the chip/ASIC side of things (translating ISO 26262 requirements to actionable guidelines on hardening the design in question, together with a verification methodology and the required safety documentation.) We also value recommendations from designers who had to follow the expert's guidelines, as well as experience in presenting safety cases to customers.

A core function of an OS is dividing resources between apps: multiple windows per screen, files per disk, sockets per Internet connection, etc.

The machine's goddamned SPEAKER is one of those resources.

Now let's say you're working at your desktop. Your boss walks in for a chat. And now, midway through the conversation, your computer's goddamned speaker emits something like: "Major breakthrough reached at the G-20 meeting!", or "I came in like a wrecking ball!", or "Aaaah… ah! yeah, right there… AAAGH!!"

Your computer might have said it because you're watching news, or that other stuff, instead of working. Alternatively, perhaps some uninvited pop-up popped up an hour earlier - and then decided to self-activate at the worst possible moment.

Either way, it'd be nice to be able to shut the thing off quickly – say, right after "Hi, I'm Wendy" and before it gets to "yeah, right there." And not only that, but you might want to kill the app without giving focus to its window, because who knows what Wendy's up to in that window.

Now, closing a window or deleting a file is easy, because you have a visible handle to click on. Not so with sound, unfor-tu-nate-ly. Big mistake on behalf of OS designers, says I… BIG MISTAKE.

And that, folks, is the perfect use case for a "WTF is that sound" widget. I haven't figured it out down to an actual mockup or anything, but, ya know, it'd be a list of who the FUCK is using the GODDAMNED SPEAKER. "Who the fuck" might be a list of window titles – or maybe not, because you might not want a title like "Erm erm Wendy erm ahem". So it might be a list of app names without the window titles. Most importantly, if just ONE app is using the goddamned speaker, then there'd be just one red button that you press to KILL the fucking thing.

I'm hereby placing the idea in the public domain. Now go ahead and make {the world a better place, billions, an abandoned GitHub project implementing this dumb idea}.

P.S. I'm fine, thank you, but yes, the inspiration comes from real life, and no, it was neither Miley Cyrus nor Wendy, but a weird tune without words that ended as mysteriously as it commenced, and I still don't know what played it.

Update: no, it's not like a mute button. If we're seriously being serious about it, then pressing a mute button is like turning off the screen. When the boss walks in and there's a noise and you mute everything including the ambient music it's off, just like pressing the screen's off button would be off. More seriously, if you have umpteen apps and tabs and shit and something starts to emit sound and you don't know what that is, then a mute button doesn't help you, not if you want to listen to anything else at the same time which you might want to. So you need a "sound manager" just like you need a window manager. (Imagine having to guess which of the umpteen [x] buttons to close to make a particular window disappear. Sucks, right? Exactly the situation with sound, which, if it doesn't happen to be synced to video playing in some window, comes from fuck knows where – and even if it's synced to video, you must sift through windows to find that video! Why can't the window/tab/whatever at least have an indication of "sound is being emitted by the sucker who opened me"? Seriously, it's just dumb.)

I hate puzzles with a passion; I think of them as Gordian knots best untied with a sword, a machine gun or whatever else you can bring to bear on the problem.

The world of computer programmers, however – the world which I entered with the sole purpose of working for the highest bidder – is a world full of people who sincerely love puzzles. And if you visit this blog, perhaps you're one of these people.

If so, you might be pleased to learn about the recently launched Sokoban levels design contest, operated by gild – a great hacker, my long-time co-worker, an IOCCC winner, and a participant in Al Zimmerman's programming contests which he cites as inspiration for his own new contest.

The rules are precisely defined here; the general idea is to design Sokoban levels falling into different problem classes. Submitted levels are scored based on the length of the shortest solution (longer is better), and normalized s.t. the level taking the most steps to solve right now gets the score of 1. With 50 problem classes, the maximal overall score is 50. But with all the other cunning contestants submitting their own levels, your levels' score might be dropping every day or hour!

And I really mean every day or hour – even now at the very beginning there are several submissions per day. Judging by the rankings page, people spread around the globe are busy improving their Sokoban level-designing software and resubmitting better solutions. (Or they might be doing it in their heads; you don't need to submit any code, just the levels. I hear that occasionally a contestant using no software at all gets a rather good result in an Al Zimmerman's contest… What happens inside the heads of such people I don't know.)

There's also a discussion group, and if you're among the cunningest, most tenacious puzzle lovers who'll get to the top, you'll get – guess what? – a puzzle! Specifically, a gift card which you can use to buy, say, this Rubik's cube – or rather a Rubik's fuck-knows-what. I guess cubes are for sissies:

I personally think it's a bloody cool community/subculture to be in; a pity that I don't quite have the brains for it. (Could I hold my own if I really liked it? Or maybe I would really like it if I could hold my own? These are the types of questions it all brings to my mind.)

Anyway – if you're that sort of guy, it looks like a great thing for your brain to chew on. Good luck!

On behalf of easily the hottest computer company in Israel right now (self-driving cars, big noisy IPO, etc. etc.), I'm looking for people in the two areas I'm involved with:

• software infrastructure / host tools
• chips / hardware-software co-design

If you're a strong programmer, especially one who's also interested in math/vision/learning or low-level/hardware/optimization or both, you'll probably find enjoyable stuff to do. It looks like there's still plenty of room for growth, which usually means a lot of work to choose from. On the other hand, there's no risk of "wasting" your effort on a product which might never ship.

If you aren't a programmer but a hardware hacker (experienced in ASIC/FPGA or just straight out of school), we're hiring for these positions as well – I'll forward your CV to the relevant people.

People who work autonomously are a great fit, and they tend to like us - we gladly dial the extent of management down to near-zero levels when appropriate.

Also, I'd love to find people who tend to be at the center of things working with others – though there's always something in stock for people who'd rather spend time alone with a worthy problem.

Relevant experience – might be a plus of course, but not a must.

Send email to Yossi.Kreinin@gmail.com, and tell your friends. Seriously, one never knows and it's kinda awkward to sell vaguely described positions at a personal blog, but I think it can be a really nice opportunity.

Update: I should mention that we're in Jerusalem and while working from another location is not impossible, it's an extremely rare arrangement. So if you don't plan to relocate and send your resume nonetheless, I might have nothing to offer even though you sent a perfectly good one.

(It so happens that most resumes come from abroad. Blogging in Hebrew would make posts about open positions more effective, I guess; it turns out that people tend to mostly read in their mother tongue. I find it rather weird – I mean when it comes to computing where the terminology and even the code is in English, so writing about it in another language is invariably awkward. The fact remains, however, that most of my readers are from the US and the UK… Had the British Empire conquered four quarters of the world instead of just one, certainly language-wise life would have been simpler for us all.)

I've just unpublished it.

Yikes. You know what's a good metaphor for a draft? Someone's undressed self who in a less than fully awake state makes uncertain steps towards the toilet. That's a first draft of that person's publicly presentable self.

And publishing a draft? It's a bit like being photographed in this state. I mean, we all pass through that state every morning. Nothing to be ashamed of, then. And yet.

I think a lot of RSS aggregators never delete a published post, even if it then disappears from the up-to-date RSS stream of the original site. Bastards. Someone should spread their naked morning photos all over the internet and see how they like it.

Anyway, sorry, and the finished thing (10 times shorter without all the written-then-thrown-away bits) is coming up soon.

I accidentally published this before finishing it. I replaced the longish unfinished text with this in the hope of getting RSS readers to forget my blunder. Sorry for all the clutter.

"You have 59 posts and 103 drafts", says WordPress, and I guess it's right. SELECT COUNT() FROM table" doesn't lie, and then I've always had about 2 unpublished drafts per published post.

Let's try this: I'll give you this list of drafts and you'll tell me which of these you want me to write. I have a bunch, they're all fresh enough for me to still want to write them – I still remember what I meant to say – but help me prioritize.

So, here goes:

• FPGAs vs cellular automata: cellular automata are one example of trying to model computation using local rules, "because the laws of nature are local" or what-not. But real life is not like a game of life, and long wires are everywhere – from long axons to the trans-Atlantic cables we humans laid out right after learning how to do so. I'd write about how FPGAs, which are popular with people who like "locality" and "big flexible computing grids" and other such ideas, support complicated routing and not just simple connections to neighbors. (Which is why FPGAs are a real platform and not a pipe dream.)
• Mircoarchitecture vs macroarchitecture. I love this one, because it sounds like a somewhat original or at least not a very widely appreciated idea. Basically in hardware, there are two different ways to attack problems. Examples of micro vs macro are: out-of-order versus VLIW; SIMT vs SIMD; hardware prefetchers vs DMA engines; caches vs explicitly managed local memories; and software-driven processors vs FPGAs. Basically it's an implicit vs explicit thing – you can make hardware that cleverly solves the problem in a way which is opaque to software, or you can expose "bare" resources that software can manage in order to solve the problem itself. There are a whole lot of implications which I think aren't obvious, at least as a whole and perhaps separately – for example, one approach is friendlier to context switching than the other. This could be a good read for someone on a small team designing hardware – I could convince him to do macro and accept the drawbacks; micro is for Intel.
• Efficiency: shortcuts and highways. To get from A to B, you travel less – that's a shortcut – or travel more simply – that's a highway. (Highways are necessarily "simpler" than other paths – wider, straighter, less junctions – and they're expensive to build, so not every path can be a highway.) It appears to be a good metaphor for optimization and accelerator hardware, in many ways. For example, getting to the highway can be a bottleneck – similarly, transferring and organizing data for accelerators/optimized functions. There are other similarities. This should, in particular, be a nice read for someone good at algorithmic optimization (shortcuts) who is curious about "brute force" optimization (highways).
• "Don't just blame the author of this manual" – this is a quote from an actual manual that I like; the context is that the manual bluntly tells why a feature may likely do something different from what you think it does, and what you should do about it. Basically this spec is outrageous if you think of it as a contract – not much is promised to you - but very good as communication – you understand exactly what the designers were doing and what to expect as a result. The distinction between "specs as contracts" and "specs as communication" is an interesting one in general.
• Leibnitz management: I mention "the best of all possible worlds" together with the efficient market hypothesis, which is what some ways of putting the "efficiency" argument on its head remind me of. For instance, the market is efficient and therefore, if we spend $1M on software or equipment, they must be worth the money (the option of us being suckers and the vendor being sustained by suckers is ignored). Similarly, if you propose an improvement, you're told that it's not going to work since if it did, others would have done it already because of said "efficiency". And other similar notions, all  popular with management.
• "No rules" is a rule, and not a simple one: I guess I don't like rules, so I tend to think we should have less of them. It recently occurred to me that what we'd really want is not less rules but simpler rules and that it's not the same thing. For example, if you have no rules about noise, then one has a right to make noise (good) but no right for silence (bad), which is a trade-off that some like and others don't – but on top of that, it creates ugly complications so isn't a simplification compared to having a rule against noise (for example, I can make noise near your property to devalue it). Similarly, giving someone "a right to configure" takes someone else's "right to certainty" – be it config files or different device screen sizes or whatever – also a trade-off. Someone's right to check in code without tests takes someone else's right to count on checked-out code to work. Someone's right to pass parameters of any type takes someone else's right to count on things being of a certain type. So, not only choosing the rules, but choosing the amount of rules is a hairy trade-off. Which goes against of my intuition that "less rules is good" , all else being equal.
• Does correctness result from design or testing? – two claims. 1: correctness always results from testing, never from design; if it wasn't tested, it doesn't work, and moreover, contains some sort of "conceptual" flaw and not just a typo. 2: however, the very property of testability always results from sound design. If it's sufficiently badly designed, no amount of testing can salvage it, because good testing is whitebox testing or at least "gray box" testing and bad design is impenetrable to the mind, so it's a black box.
• Testing is parallelizable, analysis isn't – a complementary idea (perhaps I'd merge them). Suppose you have $10M to throw at "quality" – finding bugs. You could massively test your program, or you could thoroughly analyze it – formal proofs or human proofreading or something. Testing you can parallelize: you can buy hardware, hire QA people and so on. The insight is that you can't really parallelize analysis: to even tell that two parts can be analyzed separately, a lot of analysis is required, and then frequently things truly can't be analyzed separately, because if you understand the fact that listing a huge directory is horribly slow on your filesystem, this understanding is worthless in isolation from the fact that some piece of your software creates huge directories. So analysis can't happen fast even if you're willing to pay money – you have to pay in time. Two things follow: when something is shipped fast and works, we can conclude that it's made to work through testing and not analysis; and, pushing for testing is characteristic of the private/commercial sector where money is cheaper, whereas pushing for analysis is characteristic of the public/academic sector where time is cheaper.
• Buying code takes more knowledge then building it - because when you build it yourself, you can afford to acquire much of the knowledge as you go, but when you're making a purchasing decision and you lack some of the required knowledge, then you'll buy the wrong thing and will then acquire the knowledge through having things not work – much too late. I'd give A LOT of real-life examples from my own real life; it's quite the problem, I believe. (There's frequently no way around buying code, especially if you're making hardware, but I think it's still an interesting angle on "buy vs build".)
• Make your code serial and your data scalar: I claim that things that don't work that way are not debuggable and most people have a hard time with them. For example, type systems (C++, Haskell, Scala, even CLOS), vector languages (APL, Matlab before they had a fast for loop), Prolog (even though I think solvers are a great idea), Makefiles (even though I think DSLs are a great idea), lazy evaluation (Haskell).

There's more but let's see what about these.

I don't think SOPA will fly, ultimately. It benefits content companies at the expense of technology companies which by now seem to have deeper pockets. Technology companies will find a way to undo SOPA if it passes.

But suppose it passes and is consistently enforced. This threatens sites "enabling or facilitating copyright infringement" – what are those?

Standalone personal sites probably aren't threatened. You know what you publish, and if you publish copyrighted content, you can easily remove it. Gmail probably isn't threatened because data isn't publicly available. SOPA does threaten Wikipedia, because you're supposed to not link to "infringing sites" (which could be anything) – but it probably doesn't threaten them through the content actually on the site, since they're very careful not to use copyrighted content.

Which sites are threatened the most? Facebook, YouTube, blogging and social networking sites. Plenty of copyrighted content gets uploaded to these. If SOPA is trimmed to exclude links to "infringing sites", then it is mostly "social" sites which are targeted.

Are these sites a good development in the Internet world? It's definitely not how the Internet was supposed to look like. Instead of many individual sites, we now have a few huge sites keeping most of the published data, together with much personal information, with very little obligations to users. "They trust me – dumb fucks", as the Facebook CEO put it.

Wouldn't it be great if instead of big social sites, we had big hosting companies and many independent individual sites? Wouldn't it be great if the many independent sites were all using public protocols to exchange data – using the Internet network and not the Facebook network? Wouldn't it be great if no "social engineer" could oversee our communication?

Couldn't SOPA do just that – make it unaffordable to manage a proprietary network like Facebook on top of the Internet, giving us back a decentralized Internet? Facebook convinced hundreds of millions of users that it's fun to be on the Internet, read stuff, write stuff. Couldn't SOPA then force people out of Facebook and bring them to the actual Internet?

Hosting companies that make publishing easy – on your site, under your domain, with data under your full control and responsibility – could use the opportunity. It's well past time that running an actual site is feasible on this fabulous Internet network. With all these proprietary networks on top, what normal person runs a site today, or even knows what it means? Wouldn't it be great if they finally started?

And yeah, I realize it's not going to be like that. Facebook will manage to shoot this legislation down. If it doesn't, then it'll manage to work around its enforcement. And if it doesn't, any site with a link to any other site is probably threatened – definitely Wikipedia, Reddit, HN…

So yeah, it's going to be much worse. But I can dream, can't I?

(And couldn't you think of a way to distribute the hosting of user-generated contents – like news links or Wikipedia articles – and give a unified view at the client side? Then one couldn't target "the Wikipedia site" – there wouldn't be any – but only a specific portion. Wouldn't it be better for users, in some ways? )