There seem to be a couple of conversion glitches in the HTML page: leftover "\em" and "\supereject" in the text.
1,585 karma · joined January 21, 2012
I couldn't find any progress report after http://tromey.com/blog/?p=751 so I guess the project has been abandoned early.
According to the description of the "Remote Verification Protocol", I would be able to associate my GPG key with any identity / email address, provided I can reply to emails sent to that address (at least during the verification pass).
It's certainly an improvement (OpenPGP keyservers provide no verification whatsoever), but it's not secure in any way and does not address the strong anonymity concerns that are exposed in the intro...
Although it seems that MyPy has done a lot of progress since, most notably adopting Python 3 syntax for type annotations.
> Lustre runs the majority of the world's supercomputers. It seems a
> little unfair to dismiss them without at least giving a reason
> why. They have made some progress towards getting their kernel
> client upstream recently.
Also, there is no clear upgrade path between different versions: the recommended procedure is to dump everything to another filesystem and then reload after the upgrade. There is no replication handled at the FS level. When running Lustre on top of ext4, you have to use the Lustre's own versions of the ext4 utilities, which replace the ext4 utilities in the system...
In short: Lustre sacrified a lot of ops-friendliness for the sake of high-performance. This is quite the opposite choice that GlusterFS has made.
(Edit: formatting)
For instance, if you run a Redis server and turn off memory overcommit, you might not be able to background save.
I'm curious if this works in practice for you. The current OOM algorithm in Linux sums up the memory usage of a process and all its children. So there are good chances that the restarter process is killed first, and then the main software is killed too (when OOM killer realizes the last kill didn't free enough memory).
This is exactly the problem we're facing at work here: on a computational cluster, users sometimes start wild code that consumes all the memory, but the OOM decides to kill the batch-queue daemon first, because it's the root of all misbehaving processes. We have to explcitly set `oom_adj` on the important daemons to prevent the machines from becoming unresponsive because of a bad OOM decision.
On July 19th, 1992, a car bomb killed in Palermo judge Paolo Borsellino and five police officers escorting him: Walter Eddie Cosina, Agostino Catalano, Emanuela Loi, Claudio Traina e Vincenzo Li Muli. A sixth officer, Antonino Vullo, was injured.
Together with Giovanni Falcone, killed on May 23rd of that same year, Borsellino was one of the (Italian) anti-mafia squad.
Photo: D'Amelio street, in Palermo, where judge Paolo Borsellino was killed.
I don't think that "closed source / commercial alternatives" (IE in the browser case) have done any better on the bug side than the open source ones.
One of the reason people use OSS is that -despite all the flaws that JWZ points out about the bugfixing process-, bugs have historically been fixed faster and the community support is (again, on the average and historically) more responsive.
But I'm no expert, so I'll be grateful if someone with the knowledge could clarify.
A correct calculation gives a neutron production rate from (1) about
300 times smaller than what estimated in [1–3], for the value of the
mass renormalization factor β ≈ 20 considered there. In turn, it is
questionable that values of β can be realized, in particular for
bound electrons, so large as to give rise to useful nuclear
transmutation rates. A more detailed analysis of the attainable
values of β is needed to obtain more definite conclusions on this
interesting phenomenon, should it exist at all.
A blog post on Nature.com about a month ago explains better why they were on trial, which is not the misprediction that an earthquake was imminent:
The prosecution’s closing arguments [...] made it clear that
the scientists are not accused of failing to predict the
earthquake. “Even six-year old kids know that earthquakes can not be
predicted,” he said. “The goal of the meeting was very different:
the scientists were supposed to evaluate whether the seismic
sequence could be considered a precursor event, to assess what
damages had already happened at that point, to discuss how to
mitigate risks.” Picuti said the panel members did not fulfill these
commitments, and that their risk analysis was “flawed, inadequate,
negligent and deceptive”, resulting in wrong information being given
to citizens.
If you can read Italian, there are a few online newspapers have comprehensive explanations about the trial matter:
[1]: http://www.giornalettismo.com/archives/548491/terremoto-laqu...
[2]: http://newrassegna.camera.it/chiosco_new/pagweb/getPDFartico...
[3]: http://www.cattivamaestra.it/2012/10/sentenza-processo-aquil...
The prosecution’s closing arguments [...] made it clear that
the scientists are not accused of failing to predict the
earthquake. “Even six-year old kids know that earthquakes can not be
predicted,” he said. “The goal of the meeting was very different:
the scientists were supposed to evaluate whether the seismic
sequence could be considered a precursor event, to assess what
damages had already happened at that point, to discuss how to
mitigate risks.” Picuti said the panel members did not fulfill these
commitments, and that their risk analysis was “flawed, inadequate,
negligent and deceptive”, resulting in wrong information being given
to citizens.
So the whole thing looks more subtle (and sensible) than many news headlines report...
I'm not sure how a converter could "skip over stuff it doesn't understand while translating stuff it does understand": it may make sense to work on "small" translation units (e.g., a function or method), but the code that comes out of the translation of a unit should be -at least syntactically- correct in the target language. Indeed, the more mature Python-to-C translators (e.g., Cython) do restrict the Python that are allowed in the source file, and refuse to compile the entire file if your code contains unsupported syntax.
If you are willing to invest some effort into adapting a translator yourself, (besides Pyjaco! :-)) PJS and Py2Js are both very clean and easy to understand/patch. Although they are no longer developed, they might provide a good starting point to build the "simple minded" translator that you would like to have.
(Thanks for the remark on the blog layout - I just picked one of the standard styles and did not pay much attention to the details.)
Last year, I wrote a comparison of the ones I could find, but none of them actually was in very good shape: http://chargen.blogspot.com/2011/08/survey-of-python-to-java...
GC3Pie (http://gc3pie.googlecode.com/) is a Python library for running many-task workflows featuring interruptible execution, interfaces to SGE, PBS and LSF clusters, and composition operators to build dynamic task dependencies (so, not just DAGs). Disclaimer: I'm one of the developers.
Weaver (http://bitbucket.org/pbui/weaver) is a Python front-end for building workflows that can run on top of the Makeflow engine, supporting SGE, Condor and WorkQueue as execution back-ends. (See the comment by its author "pbui" on another HN thread: http://news.ycombinator.com/item?id=4047100)
NiPyPe (http://nipy.sourceforge.net/nipype/) is a Python workflow engine especially targeted at Neuro-Imaging processing (but the core framework is generic, as far as I understand).
I'm pretty sure this list is not exhaustive: many people seem to be re-writing the same core functionality, coming from different fields and/or with slightly different requirements.
Currently, it is mainly targeted at grid/cluster computing but it's evolving.
(Disclaimer: developer here.)
[1]: http://ikiwiki.info/
It's a parody piece, although the author declared that "Many of the sentences that I use in the article are from actual reviews." (quoted by B. Meyer review in [2])
[1]: http://dl.acm.org/citation.cfm?id=1106763 [2]: http://bertrandmeyer.com/2009/08/14/rejection-letter-classic...