HN user

benbataille

109 karma
Posts0
Comments39
View on HN
No posts found.

It's because I'm not really precise (but neither is Lennart). Technically, libdbus is a part of dbus. It allows two applications to communicate with each other using the dbus serialisation and abstracts the transport layer. You can use it over a Unix socket and then it's just a serialisation format like any application using IPC would need. Then, using dbus is no more stupid than anything else. Actually, it's pretty clever as there already is quite a lot of tools understanding this format.

However, libdus is not what people usually talk about when they talk of dbus. The core part of dbus and what could bother server administrator is the message bus daemon which allows any applications to expose their functionalities and talk to any others. Now, systemd can use the message bus to allow applications to ask for service activation. But, it's not required and you can run the init system without it.

That's again a myth. There is no dbus dependency. You can use dbus to do activation but you don't have to. Now, there is a dependency on libdbus which just means systemd is using the dbus serialisation format for its ipc (which, I repeat, don't have to happen over dbus).

No, prices are not stupid. You didn't think through the whole problem.

The issue of cost and incentive with this kind of revolutionary innovation is real. The problem is simple. When you innovate, you bear alone the fixed cost of development while your competitors can copy and bear only the marginal cost. That's the reason the patent system exists and normally that's fine.

But, for a revolutionary invention, patents might not be feasible. Imagine you find a cure to cancer. Do you really think every governments and public opinion are going to let you be the sole producer for 30 years while people are dying ? Impossible. This creates a disincentive to push money towards a cure for private investor. Now, the idea behind a price is that if you find the cure, the price is going to cover your fixed cost (ideally more) thus investing is competitive again. Technically, as it fosters competition and you will only reimburse the finder, it supposed to generate more research than just spending the price money. Putting money aside for this kind of price was one of the main goal of the Bill and Monica Gates Foundation when it was founded (I think, they went back a bit because people wrongly assume its wasted money).

1 Bitcoin today and 1 Bitcoin in six months is not the same at all because you lose all the value you could have add from this Bitcoin during the six months so you have to discount it. That's called present value of money and that's one of the way companies manage their investments.

Theoretically, you have to use the real rate of return of your money and discount it on the time period. Of course, estimating the real rate of return is an art in itself. Considering value of bitcoin has been shown to be highly volatile, doing any semi-long term investment with it is basically gambling.

Most people are completely unaware of what CS researchers are doing in France because they don't work on things which the public finds ultra-sexy. Most of what they do and are good at has direct industrial application.

They made some pretty interesting things in type theory, language design (OCaml), proof (Coq), static analysis and certification (B-method, Frama-C, CompCert).

All of these is useful if you want to do safe embedded softwares for your planes, flight control softwares, automatic metros or nuclear reactor monitoring systems (which they do) but it isn't really easy to explain to the general public.

There is also a supposedly quite strong numerical modelling group working on nuclear deterrence but most of this stuff is classified. Let's also not forget that France still is a major arm dealer so you have some R&D done by private defence companies. Nothing comparable to the USA but you still apparently have some development in targeting, surveillance and interception (well, France has a world covering array network, I hope they at least try to use it).

Now, there is nothing particularly exceptional here. The situation is mostly the same in all publicly founded laboratories around the world. What France doesn't have very much is people doing frivolous stuff like email sorting or social network aka start-ups but that's another problem.

> It's a top-5 program internationally, so I take it to be quite good.

Most of the international rankings are heavily biased in favour of English speaking countries and particularly the USA (especially ARWU). It's mostly fine in sciences where all the important publications are in English. It's clearly dubious in the humanities. Beware this kind of claim.

Does someone have read the original article ? I am curious about how the reader evaluation of potential risk was assessed. Was there a control group which didn't see any comment to compare variance amongst this group to the other groups variances ? How was the sampling done ? Were people with knowledge of science equitably balanced amongst groups ? How many of them was there ? At which level is the variance difference amongst groups significant ? 2000 subjects can lead to average results depending of the sampling.

The jsonline article does quite a lousy job with details.

I think you should probably read the links you post. They are close to claim exactly the contrary of what you say. As the Wikipedia article rightfully points, the difference is far less obvious than you make it seem.

The definition of an interpreter is generally broader than a main loop running instructions one at a time. For example, everyone seem to agree that Python is an interpreted language while python interpreter transforms the source code into an IR before passing that to its main loop. Truth is the line between what is a VM, an interpreter and a compiler is rather fuzzy.

The implementation of a process virtual machine clearly is an interpreter of a bitcode. Now, it's not entirely absurde to consider the couple JIT and VM taken together as an interpreter. Actually, this is clearly encompassed by the third point of the definition of an interpreter provided by Wikipedia : "explicitly execute stored precompiled code[1] made by a compiler which is part of the interpreter system".

To come back to the article discussion, I agree with the previous poster than the expression "source code VM" is kind of meaningless. Actually, the paragraph following is even plain wrong. The Dart VM executes bitcode not source file and Dart is JITed.

In the same way, I find it quite surprising that forty years after Hindley paper, people still confuse type annotated and statically typed but well, c'est la vie.

It's because of the way the premises are written in regard to the type environment in the rules and how things are unified. It's directly linked to free and bound type variables and yes, it's complicated to understand.

If you look at the [Abs] rule, you will see in the premise "x : tau". Here, by definition, tau is non qualified. It represents a unique type. It's necessary monomorphic. Concretely, it means x will be bound to a type variable in the type environment and this type variable will uniquely be unified.

On the other hand, the premise for [Let] is e0 : sigma, x : sigma. Contrary to tau, sigma is qualified (polymorphic). So, it can be unified to a different type variable in different expressions.

I completely understand why it fails you. The way qualifier affects the unification process is quite complicated. I finally understood it only after having to write my own rules when I was implementing a type checker for my master thesis.

If you don't mind the formalism, read carefully the Wikipedia article paying particular attention to how tau and sigma are defined and to the paragraph about free and bound type variables. If you want something more practical, look at the Peyton Jones book I gave a link to in this thread. Part 9.5 is the important part but it's difficult to get without having read the whole chapter (eventually chapter 8 too). It 's still complex but far less abrupt than the Wikipedia article.

No, this nonequivalence applies directly to the typing of the lambda-calculus which was the topic of the original papers by Hindley and proven by Damas.

On the contrary, the value restriction is a part of the extended rules used for the typing of ML. It was introduced because ML isn't pure, it supports references. The value restriction is there to prevent them having polymorphic type. The rule is simple : syntactic values are the only things receiving a polymorphic type. What is a syntactic value ? To quote Geoffrey Smith notes on SML97 "Basically, a syntactic value is an expression that can be evaluated without doing any computation".

All this iss done in order to ensure type safety. Actually, if references could have a polymorphic type, the type system would accept incorrect programs such as :

let r : 'a list ref = ref [] let r1 : int list ref = r let r2 : string list ref = r r2 := "a" let v : int = 1 + !r1

Which does not work because r, r1 and r2 are references to the same value.

Value restriction is a bit overkill. It rejects program which could be safely typed. Other solution to this problem exists. Actually, Standard ML used a different solution at the beginning (carrying information about the typed hold in a cell along) but it has other drawbacks. MLTon has a really good page about all that : http://mlton.org/ValueRestriction

Some research was done about relaxing value restriction. OCaml type system, for example, has less constraints than SML and MLTon (you can see this paper about that http://caml.inria.fr/pub/papers/garrigue-value_restriction-f...).

> Technically, [Let] is redundant because it is a combination of [App]+[Abs] : let x = e1 in e2 is equivalent to (λx.e2) e1.

This equivalence does not hold in the HM formalisation. It's well explained in the Wikipedia article : http://en.wikipedia.org/wiki/Hindley-Milner#Let-polymorphism

[Abs] is monomorphic while [Let] is polymorphic. Using the Wikipedia article exemple : \f.(f true, f 0) will not be typed while let f = \x.x in (f true, f 0) will be reduced to (bool, int).

I tend to disagree with you in the sens that Damas-Milner seems to me as the typical exemple of an algorithm which seems simple but actually have subtle implication and trade-off. Robinson's unification which is at the center of the algorithm is already made a bit tricky by quantification as soon as you have polymorphism. Then, some rules have actually deeper implication and trade-off than it seems (especially let).

For people interested in type checkers, there is a couple of really good chapters by written by Peter Hancock in a book available online : The Implementation of Functional Programming Languages by Simon Peyton Jones. They entirely cover the theory and there is a complete implementation in Miranda. Here is the link : http://research.microsoft.com/en-us/um/people/simonpj/papers...

> How is this any different than saying "Avoid the + operator at all costs, because behavior is non-trivial and varies from language to language".

I never ever remotely said that. You are putting words in my mouth and I don't like it. I just rightfully pointed that there actually is a semantic difference between the two mentioned lines. I never implied using any of them was wrong. I didn't even emit a judgement of value on either construct.

Now, I don't have problem per see against the conditional operator. It's just not as simple as some people like to pretend and it makes your code depends on some non obvious and not broadly known language feature for what is usually a minimal gain. So, yes, I do tend to avoid it in anything which is going to end in the hand of others (in the same way I try to avoid any un-obvious language idiom as much as possible). It's like nested comprehensions in Python, the slightly shorter code produced is just not worth the added complexity.

If it was that simple, people wouldn't have any issue with the conditional operator. The problem is there actually is a semantic difference between the two lines you wrote in most languages.

If-Then-Else is a statement. It doesn't return a value. It's just a branching operation between the two blocks.

The conditional operator is an expression. It returns a value hence it has a type. And that's where things start to be messy. Typing rules for the conditional operator are, well, not trivial and varie from language to language. Let's use an exemple from Java Puzzlers (Joshua Bloch and Neal Gafter) :

char x = 'X'; int i = 0; System.out.print(true ? x : 0); System.out.print(false ? i : x);

will print X88 but the same thing in C++

        char x = 'X';
        int i = 0;
        cout << (true ? x : 0);
        cout << (false ? i : x);
will print 8888.

And I am not even talking about the priority mess when you try to use a conditional operator in a conditional operator.

PTO is never going to stop issuing crappy patents. There is a huge conflict of interest there.

It's easy. Every time someone files a patent, the PTO gains the filing fees. If they don't check too much, people file a lot and they win a lot. If they check, it means first more cost for them, then less patent filed hence less money.

Now, what happens to them, when they accept bogus patents ? Answer : nothing. The PTO is simply not accountable for that.

No surprise they have no incentive to do their work properly.

Thank you, I missed that (I'm an idiot, it explains why the DCRI went after Wikimedia and not Wikimedia France at first). Wikimedia seems to think the law is with them. I'm not entirely sure but contrary to their layers, I'm not a specialist. What I wanted to convey is how silly the law is and how it makes Wikipedia French administrators easy targets .

While I agree the situation underlines a real problem, I don't think it lies where people think. If you read the text, you will realise that, even if they are really clumsy, the issue here is not so much the DCRI than French law itself.

Let's look closely at what is happening : 1 - The DCRI aks the Wikimedia Fundation to delete an article from Wikipedia because it's infringing article 413-11 of the French penal code. 2 - The Wikimedia Fundation refuses arguing the order should state which piece of information in the article is classified. 3 - As the Wikimedia Fundation is an american organisation, the DCRI turns itself towards its French arm, the French Wikimedia and its representative. 4 - Under pressure, the president complies and removes the article pointing that people putting it back will be breaking the law.

Well, actually, he is probably right. While I understand why the Wikimedia Fundation took a stand and refused to remove the article, as silly as it seems, the fact remains : In France, putting classified information online is illegal even you don't know they are classified.

Let's look at the article 413-11 : http://www.legifrance.gouv.fr/affichCodeArticle.do;jsessioni...

First, this article is aimed at everyone not mentioned in article 413-10. Article 413-10 lists the sanction for people which are legitimately depositary of a state secret. Thus, article 413-11 concerned anyone knowing a state secret without being mandated.

Now, there is three points in the article. The first one says that the mere fact of knowing classified information without being mandated is illegal (yes, even by accident). The second one that destroying, stealing or copying such information is illegal (yes, it's unnecessary considering that to do that you have already committed 1). The third (unnecessary too) states that sharing this information with the public is illegal too.

So yes, if the Wikipedia article contains classified information, Wikimedia France already broke the law and its legal representative is liable and yes it's laughable.

But now, the best part. Do you know why there is so unnecessary part in this law ? Because it was changed in 2009 ! Previously, article 1 only criminalised illegally acquiring classified information, not knowledge of it. But, you nailed it, transforming unknowing citizen into criminals was obviously a necessity to protect us against terrorists and the amendment was passed in a state of general indifference despite some warning from the press (for once).

So, if you want to blame someone, blame the French parliament and the French people. It's entirely our own fault (you can also do some lobbying if you happen to be French, the new government might hear you but I doubt it).

We have been in a post gold economy since the end of the Breton-Wood agreement. Hording gold is far from a wise investment. It certainly isn't a safe way to store value. First, history aside where it's value comes from is difficult to understand. There is literally tones of it lying around without any real use (far more than what is produced). Basically it's a safe haven because people decide to use it this way but the market could crash any day and has multiple times before and thus despite central banks holding so much of it they dwarf anything someone could decide to inject.

From my point of view, bitcoin is an even more stupid investment. As little as 5000BT makes the rate plummets. Nothing could stop a young Soros from pulling out a mini-black Wednesday. Add the fact that the market is completely unregulated and you have a pretty risky situation. I see Bit coin has a step backward. It's like current currency without any of the warranty provided by governments (security of trade is one of the main reason we instituted government after all). To the people who will argue that Cyprus is currently stealing its citizen, please think about what would have happen to them if there was no way to get a bailout and the banks actually collapsed.

Sorry for the ambiguity. It's certainly not a waste of money. I found "Types and Programming Languages" really good (for whatever that means, I'm far from being an authority in the subject). It seems to be wildly used as a textbook and is a reference in the subject. While I didn't read it, I expect the second one to be in the same vein.

While not being exactly about type theory like Pierce books (you can't waste your money on those), I really like the part about types in "The Implementation of Functional Programming Languages" by Peyton Jones (the chapters about type system are written by Peter Hancock). It's seen mostly from a technical point of view. The book notably contains a fully explained implementation of a type checker.

You can check it online while waiting for the Pierson ones: http://research.microsoft.com/en-us/um/people/simonpj/papers...

> Frankly, I don't understand why any of the movie/TV studios need Netflix when they can simply sell their own content direct to the consumer via Internet.

Because they remember what happened to them the last time they tried this trick (actually they don't remember that well but we will come to that). Let me explain, it all dates back from Hollywood infancy.

So, let's go back to the beginning of cinema at the very start of the past century. Edison just invented the kinetoscope which is seen as a novelty. Immigrants, mostly Jewish, looking for work see in the exhibition of such shows a way to make a living, bought projection material and funded the first cinemas, the nickelodeons.

Quickly, it appeared clear to the most entrepreneurial that to make customers come back, you need a constant flow of new movies to show. They decided to move to production and fled the east cost settling in California in order to avoid paying Edison for his patents (kind of ironic, isn't it ?).

Most of these people came from the distribution sectors. They understood its importance and quickly passed contracts with theaters circuit. These circuits actually predate cinema era . They were initially showing vaudeville. In the end, the biggest studios of the period ended in possession of their own movie theaters distribution circuit.

As long as studios were numerous, everything was fine. But, the formation of the MPPDA what will become the MPAA in 1922 by the then three majors studios started making some players uncomfortable and independents quickly accused them of forming a trust.

Then comes the 30's. Talkies become the norm. Productions costs skyrocketed. Early players like Warner won big and started buying smaller studios. By the end of the decade, Hollywood was entirely dominated by five really big studios.

As production costs were so high, these studios were in the habit of bundling movies when selling them to make a profit even on the not so stellar ones. As a non-negligible share of cinemas were owned by the productions company and thus buying blindly, others had to buy bundled too (generally the whole season) or be unable to show the blockbusters. The majors add shifted the production risk for them to exhibitors putting all independent in a difficult position.

Thankfully, it was another time. The federal government was still somewhat working and the studios were sued by the Department of Justice in 1938. It reached the Supreme Court in 1948 (see http://en.wikipedia.org/wiki/United_States_v._Paramount_Pict...) whose verdict went against the studios. Finally, they had to separate themselves from their distribution outlet and laws were passed ensuring a more fair market.

Now, the really funny part is that the way these same studios actually sell their catalogue to digital distributors is strangely similar to the bundles they used to sell to cinemas in the 30's. But, as they don't have their own distribution network, they don't fell under antitrust law.

TL; DR : Because they lost an antitrust case against the US government in 1948 for owning large part of the distribution circuit and using bundling practices not that far removed from the way they sell their catalogue to digital distributors.

I think your analysis is spot on.

Big companies don't want to house large IT infrastructure anymore. It seems too costly in the long run and benefits are difficult to explain to the board.

Consequently, you already see companies moving what was before considered core infrastructure to the cloud and the trend is probably going to increase.

Deploying a VM on EC2 or Azure is easy, quick and cheap enough considering you don't have to house as many talents as before in the IT department. As companies move to cloud based services, they don't deal with databases anymore, the people providing the solution (we don't even talk about software anymore, that's the current level of abstraction) does. Problem is amongst the cloud based service providers, few are Oracle shop.

That's the reason Oracle is now trying to position itself in the cloud through acquisitions (like Nebula today). Unfortunately, they are a bit late to the game.

Thank you for brilliantly proving his point. What you wrote just prove that you completely mixed what is a language and what is its implementation.

Of course C semantic uses a calling stack in its definition. Does that mean you need a physical stack to implement it ? Not at all, you can perfectly implement C in anything as long as you can simulate a stack. Just look at the JVM and Dalvik. Dalvik is register based while the JVM is stack-based and they both run Java.

java.lang is a standard library. It's only part of the language definition in a really broad sense. It's actually written in Java. Any complete Java compiler can and will compile it (with some modification for the purely JVM oriented functions). There is a lot of projects out there trying to compile Java on a target which is not the JVM.

> All languages are Turing complete, so it doesn't matter?

Precisely. The whole "my language is better" argument is completely void. Syntax is mostly a matter of preference. Semantic will make the structure of your program different but in the end there is no actual difference on what you can do only on how you will do it. Once again it mostly boils down to preference.

If you really need to argue about something go for my compiler/optimisation pass is better that at least does make sense. Note that there is no theoretical bound preventing an Haskell compiler to generate code equally fast than the one of a C compiler for any program.

> Do you program in assembly language then?

I did when I had to (quite a long time ago). While languages don't matter, compilers do when you need efficiency. While enjoying ML-based languages more, I also did some C. As I stated before, C compilers are better. Well, I even used my own little syntax-extension of C for a moment (if you don't have to share the code, you can do whatever you want with it).

Could everyone on HN just take a course in languages theory so we can all stop with these stupid trolls about the best languages which have been emerging for a week.

Hopefully it would allow everyone to realize that a language is just some syntax and semantic and that a compiler is just a program like another. Nothing sacred here. Hell you can even do imperative programming in Haskell if you wish. Coding an interpreter to do so is not particularly difficult.

With a bit of luck, everyone would understand at the same time that the compiler is building what is executed therefore the expression"speed of a language" is utter nonsense. You can only speak of the speed of the implementation which, yes, vary widely amongst compilers for the same language.

So, yes, Haskell semantics encourage functional programming, C semantics imperative programming, both are Turing complete and yes GCC is currently better at optimising C code than any Haskell compiler, nothing new under the sun. Can we all go back to a normal activity now ?

10 can be divided in third and quarter fine. It does 10/3 and 10/4=2.5. Well, 10/3 isn't round so people don't like it but neither is 1/3 of an inch. It's not because a lot of operations suddenly become doable with numbers that you magically lose the usage of fractions.

It certainly is illegal in France. Refusing to sell without a valid reason is an exception to contract liberty since the sixties (article L. 122-1 du code de la consommation). The former situation was seen as biased in favor of the sellers.

Whether alleged violation of the user term is a valid reason is open to questions. Without going to court, I strongly doubt it is.

>Actually, no it isn't and at scale it makes it even more expensive, because you need redundancy. We are talking about RAID and CDN, not to mention that at scale hardware breaks a lot more often.

That's related to reliability not scaling per see. Building a highly reliable system is far cheaper when you reach the scale of Google or Amazon because you can rationalize purchase. Actually, I bet price of hardware can totally be neglected next to admin and bandwidth cost.

> On the other hand I've got 50 GB worth of data uploaded on Flickr. You can't tell me that 50 GB of redundant on-demand storage is worth $25 / year, unless you live in some kind of fairy land.

I must live in fairy land. :-) You can buy 4 decent 1TB for 400$ that will allow you to cater for 20 users at 20$ per user. Conservatively you can expect them to live 3 years on average which brings the cost to 7$ per user per year. Add a 400$ server good enough to do software RAID. Let's say 5 years of life expectancy it adds 5$. It's 12$ per user plus network cost on a lan.

Flickr uses better material and pay bandwidth and admin. But they have economy of scale and can put far more than 20 50GB users on 1TB on average because a lot of them don't use them fully. I think they are above break even point at 25$/year.