Entries Tagged 'OT' ↓
August 28th, 2014 — OT
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.
August 27th, 2014 — OT
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.
March 23rd, 2012 — OT
"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.
December 19th, 2011 — OT
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? )
June 28th, 2011 — OT
Or, we'll hire if we find the right person.
If you live in Israel and are into things like:
- hardware/processor/programming language/library design
- compilers, debuggers, profilers, simulators, instrumentation
- number crunching/optimization
- parallelism/multi-core/distributed computing
…we might have a bunch of stuff to interest you. Benefits/drawbacks/features:
- Most projects are intended primarily for internal use – "infrastructure" if you like
- Lots of custom things, ranging from our own chip to our own distributed build server
- Plenty of production projects depending on your work
- Ability to do grand things singlehandedly guaranteed through understaffing
- Bleeding edge, "first/best" system in several categories
- Little management, especially if you don't really need any
- A "Worse is Better" spirit (reasonably pragmatic perfectionists are welcome though)
- Many long-term projects
- No downsizing during previous bubble burst
- Experience in any specific relevant area appreciated but not required
- Mostly C/C++, Python, and our own languages; if it matters, you can use any other language
- Mostly Linux, a bit of Windows, Eclipse usage share eclipsed by emacs & vi
- Nice people
A great place to work, if you ask me. If you're interested, send mail to Yossi.Kreinin@gmail.com
August 4th, 2010 — OT
A person's reputation tends to rise together with the age. The older one is, the more opportunities one had to do notable things, and to meet people who could appreciate those things and tell others about them. So this makes sense.
An online document's reputation also tends to rise together with the age. The older the document, the more documents link to it, and the more documents in turn link to those documents, raising the old document's PageRank. So this makes sense, too.
The paradox is that the older documents are written by the younger people. That is, it is one's younger version that wrote one's older documents. So the documents with the most reputation will tend to be written by people (or more precisely snapshots of people) with the least reputation; one's dumb young stuff may well pop up first in a Google search.
(Not that there aren't any counter-tendencies to cancel this effect at times; my old anxious, moronic report of an imaginary bug in ALL CAPS no longer shows up in my egosearches. So no, I'm not bitter. In fact, Google loves me more than I deserve – for instance, my review of Extreme Programming Explained has appeared in search results right after the Amazon entry for the book ever since I published it, and I've only skimmed through the thing. The only thing that bothers me in the SEO department is that the search for "C++ FQA" gets corrected to "C++ FAQ" – didn't expect that once the query got past the spell check barrier. I hope my collegue's riskily named DreamPie project will not experience a similar setback.)
May 12th, 2010 — OT, wetware
As a part of my continuous moral degradation and the resulting increasing alignment with the forces of Evil, I'm sharing an apartment with a gal who used to work in HR assessment. She recently got me acquainted to a friend of hers, BC, who works as a business consultant (names have been changed to protect the guilty).
BC's primary educational background is in applied mathematics. Having put the math they teach in CS departments to relatively few uses as a working programmer, I asked her about the uses of applied mathematics in business consulting. BC cited the following two examples.
The first example involves compensation and its dependence on key performance indicators, affectionately known as KPI and estimated by HR assessors. One way of looking at this dependence is to consider how it affects compensation over time as an employee's competence increases.
A psychological discussion is then possible on the relative merits of the different graphs plotting the compensation functions f(KPI). If f is linear (has a constant derivative), we make people struggle equally hard at every step. If f's derivative increases over time (for instance, when f is exponential), we make elevation hard at first and then increasingly easy. If f's derivative decreases over time (for example, if f is logarithmic), we make the last mile the hardest. And so on.
Through a psychological discussion of this sort, someone in the consulting company decided that what was really needed in some case or other was an S-shaped curve. The problem was that you couldn't just draw an S-shaped curve – the plotting had to be done in Excel according to a formula; an S-shaped curve which just blithely goes through arbitrary points doesn't cut it when you deliver a Compensation Model. But how do you make a formula to go up slowly, than fast, than slowly again? Exponents don't work. Logarithms don't work. A sine does look like an S, but it's a wrong kind of S, somehow. What to do?
Enter BC with 6 years of math studies under her belt. A compact yet impressive formula is spelled out, and – presto! – Excel renders an S-shaped curve. (I guess she used the sigmoid function but I didn't check.) The formula brought delight to management and fame to BC, and compensation payments issued according to its verdict keep adding up to scary numbers (BC's agency works with some really big companies).
The second example involves the compensation of managers. Naturally, a good manager near the bottom is worth less to the firm than a bad manager near the top, and therefore the compensation function should now depend on the manager's level in the hierarchy as well as his KPI (or better). Equally naturally, the numbers coming out of the compensation spreadsheet will under no circumstances arise through an externally conducted study of their psychological implications or any similarly unpredictable device. The numbers will result from nothing but the deep understanding of the organization possessed by the top management.
The development process of the managerial compensation function is thus complementary to that of the employee compensation function. Instead of producing numbers from a beautiful spreadsheet, what is needed here is to produce a beautiful spreadsheet from the numbers specified by the top management. The spreadsheet then promptly generates back these exact numbers from the input parameters.
The purpose of the spreadsheet is to relieve the top managers from the need to justify the numbers to their underlings. In order to guarantee that they are relieved from this need, the formula should not contain terms such as 1/(level^2), which could raise questions such as why not use 1/level, why not use 1/log(level) and other questions along these lines. Rather, the formula should contain terms which could raise no questions at all simply due to their size and shape.
BC faced this problem at an early stage of her career, and despite the natural stress, came up with an interesting Compensation Model, its key term being e raised to the power of something unspeakably grand, combining the trademark Gaussian look and feel with an obvious ability to deter the skeptics from asking questions. The only problem with that term was the very source of its utility, namely, the fact that it evaluated to 0 for all values of KPI and hierarchy level.
The deadline being close, BC told the manager of the consulting project in question about the status of her work and expressed her doubts regarding the delivery of the Computational Model. The manager told her that she just doesn't get it, does she, it's great, the right numbers come out and that's all there is to it and we should send it right away. And so they did, to everyone's complete satisfaction.
Her command of applied mathematics aside, BC is generally quite powerful.
For instance, she once got invited to consult some government agency about a project of theirs, while being on vacation and without it being explained to her that she was about to attend a formal meeting with the whole team. In order to maintain the reputation of the guy who somewhat clumsily brought her in, she had to improvise.
The project, worthy of a government agency, was related to some sort of war on corruption, the unusual thing being that they wanted to fight the corruption of other governments. Their weapon of choice was the training of representatives of another government, financed by the other government, in their supposedly superior methods of governance. While the general concept was impressive on many levels, the details were unclear.
BC had to speak, and she spoke based on a principle appearing in a book by some McKinsey alumni (she didn't tell its name nor generally recommended it): whatever you tell people, it should contain 3 main points. Possibly 4. But preferably 3. More is overwhelming and less is boring. So she said: "At its core, your project is about teaching people. It is therefore essential to clearly understand three things:
- Whom you're teaching,
- What you're teaching them,
- And how you're teaching it."
And they started writing it down.
I asked BC whether there was some way to unleash her on the company employing me so that she grinds a few bullet points into them (a handsome Compensation Model being as good a place to start as any). She said something to the effect of "it only works on the weak-minded"; it was apparent, she said, that the government agency in question had little previous exposure to consulting.
BC says she (still) believes that business consulting is meaningful and valuable, which sounds paradoxically at this point. But, looked at from another angle, it really isn't. Don't view her stories as ones undermining the credibility of business consulting but rather as ones building her own credibility as a person aware of the actual meaning of things and willing to sincerely share that understanding (how many people would instead say that they Developed Cutting-Edge Compensation Models?) If she says there's meaning to it, perhaps there is.
October 13th, 2008 — OT
- To comment, you no longer need to register, just type "y" to confirm you're a human. Thanks to Aristotle Pagaltzis for pointing out that the previous arrangement sucked.
- I've started another blog, mostly hosting images. For example:
I originally intended to have one blog for everything, but since you've probably subscribed for the technobabble, I'll reserve the channel for that.