martinced

This kind of stuff is precisely the reason why we make sure that every filename we create is only using a subset of ASCII (and no space of course). In our source code, in our builds, in the desktop app we're serving, etc.

Unicode characters entered by users should go in one place: the DB.

I smiled the other day when I read about the build script for Chromium: it clearly specificied that the source directory must not contain any space in its name.

Of course it shouldn't. That's experience.

Typically they're better when you can put them in context: you should run all these regularly on fully working servers which you know are operating normally so you have "something" you can compare your results to when the shit hits the fan.

Anyone who has spend a few days with Clojure realize how much more easier it is to reason about them and to work with them.

Immutable data structures combined the software transactional memory that Clojure provides are a godsend.

In a lot of case they're also much faster then the good old copy-on-write and because they're immutable you have lockless concurrency. This is huge.

But it gets better: if you really find a performance bottleneck due to the use of immutability, you can fallback to mutability / place-oriented-programming.

Exactly. That's the terrible stuff with all this "enterprisey" mindset: people are working on medium-sized codebase made of this special kind of hell that Java/C# + ORM ([N]hibernate) + XML + SQL is and these app often run into the 200K / 300 KLOC lines if not more. Yet what does these applications really do? Actually not very much. Yet these programmers are sure to be working on super-advanced stuff because their codebase is big.

When several companies reported a drop in LOC of 90% by switching to something else than Java then at one point you have to at least consider that maybe most of your Java codebase is hot air.

Sure a server does crash once in a while but it's not because they purposefuly did overload it.

The DDoS attempt trafic is dispatched left and right just like regular trafic and doesn't affect the normal behavior.

It's more like the single truck can hit any of the 1000000 flying bycicles.

: )

Would put a smile on my face too but... I decided to make part of the computation on the server-side so that my desktop software cannot be cracked without rewriting what the server-side does. My desktop app only makes sense when the Internet connection is up and doesn't "phone home" too often.

If users don't like that they can GTFO.

If pirates don't like that it puts a smile on my face ; )

Seriously:

"4. The editor should contain no implementation of Lisp."

Why do they do that? Because of course Emacs totally rocks in their last example, where you need to apply the same modification to various lines (in Emacs you'd probably use a macro repeating some search and replace using a quick Lisp substitution).

How do you even want to talk with people who argue for their own limitation?

Appeal to authority: I urge people to read "Beating the average" from pg.

Ah yes, I remember the days being a dev that didn't use VMs. It kinda sucked as a development environment that said: no easy way to test software on different OSes locally, no easy way to try other software which you don't necessarily trust in a confined environment (to see if it may be worth using, in which case you'd look into the trust issue more closely), etc.

If you're a dev and have "enough RAM" you're probably not trying hard enough ; )

VMs tend to use quite a lot of memory and tend to be very useful for knowledgable devs.

You asked and seemed so cocksure so these were my 2 cents...

The way I do it very simple: separate user accounts on Linux. That way you're sure there's no way they're going to interfere with each other. Of course it helps to be using an OS on which it's trivial to have multiple indepedent graphical sessions and which allow (if you grant that privilege) another local user to display it's app on your graphical session.

The "temp" / fake identity account is actually running inside a VM (KVM) because I use to surf on untrusted sites and is really a "throwaway" account / VM.

That kind of blog entry is kiddie stuff compared to what's easily doable under Linux.

Even if it was true, couldn't it have been organisms from earth ejected into orbit after a meteor strike and, thousands of years later or more, falling back to earth?

Now if we find a definitive proof of panspermia it would be the biggest discovery ever made by mankind so far...

On one day Google is close to dying and there are lots of alternatives out there and on the next day the very same people are writing that "SEO = Google pagerank ownage" as if Google was the one and only search engine which mattered.

So which is it? Are Google's days numbered or not?

There's a tendency which you may have heard of: mobile (smartphones and tablets) and there's a lot of push for making these supported and available to employees (the push very often coming both from the employees and from very high up the chain).

As a result mobile browsers support in large enterprise are becoming very often mandatory.

Why do you think large enterprise are supporting browsers at all? why do you think large enterprise are switching en masse to internal webapps instead of internal desktop apps? To free themselves from a particular technology vendor. It's the way they regain control. And you think they'd ruin all that by mandating "IE only"!?

This is not at all what I'm seeing in the enterprisey webapp world. On the contrary: the shift is to more platform, more standards, more openness.

I'd be using Firefox if they started to sandbox all the tabs. To me the argument that it's faster and use less memory because it's not sandboxed is a very poor one.

Actually that argument shows what is wrong with the mindset of many people in our field.

You should never trade security for a bit more perfs.

I love my MacBook and MacBook Pro but... I'm putting a little piece of paper on the webcam "just in case".

Oh and the difference between nowadays and BO in the 90's is that nowadays virtually everybody who has a laptop has a webcam. That's quite a big difference.

But really big enterprisey stuff with really big budget? It's all Oracle DB + Java on Unix there.

Just as all the really big infrastructures (Google, FedEx, Amazon, etc.) are all Unix.

I think you meant "on iOS", not "on mobile". Android has a huge share of the mobile market. And Android is pretty much Java (but maybe you don't consider the Dalvik VM to be a JVM running Java programs).

Also you make it sound like somehow .Net/Mono would be huge on iOS. Just to set things straight: most development on iOS is done in Objective-C.

>What problems do antibiotics cause, besides lessening their own future effectiveness?

Are you really saying us that antibiotics have no use?

If not you have answered your own question...

Now the concept is interesting: one could probably do the same in 3D (with random camera angles -- up to a limit) and then it would prove more problematic for AI because one would then need to be able to correctly pieces in 3D and their position on the board.

Yet HN has become the place for the status-quo. Where people are going to vote everything encouraging the status-quo (like articles about the benefits of C# and SQL) as if it was the holy gospel...

"Immediately, a SQL relational database is proposed as the solution."

For a start you're probably not trying to solve a problem involving big-data ; )

Ask the big data players who are using fast and gigantic key/value stores how did SQL work for them...

For smaller needs, then SQL offers, basically: ACID. Most companies do not care about what SQL can really do: they'll wrap everything into ORMs and perform business logic outside of SQL and in crazy models that aren't relational at all and then store back everything into SQL.

What most business care about is ACID, not being truly relational (which SQL DBs ain't anyway), not set theory.

The most saddening thing about traditional SQL DBs is that there's no basis for queries: the same query shall return different results depending on when the query is made (because most SQL DBs are "update in place" DBs / value-oriented DBs).

In the Real-World [TM] this is very problematic because when you can't reproduce a problem you have to try to reproduce the state the DB was in at a particular time and query from there. It is a gigantic time waster.

In my view for really big data needs SQL simply doesn't cut it while for smaller needs I still want ACID but I want something CRA ("create read append-only"), not CRUD.

I have nothing against using something like Datomic (which is CRA) backed with a SQL datastore.

But the "traditional" SQL DB that the herd --bent on never creating anything disruptive-- is using? Not for me.

CRUD is dead baby. CRUD is dead.

There are, today, people who've read and understood pg's writings who are using Lisp dialects (like Clojure) and CRA DBs (like Datomic, backed or not by SQL) to gain a competitive edge.

This kind of stuff is the reason why I come to HN. Not to read why the status-quo is acceptable (even if it's all most of the HN crowd knows).

Now the bad guys knows that they should just have tried a bit longer.

Now maybe that because you were DROP'ing / blacklisting IPs maybe they just ran out of zombies but still...

If I was the attacker and read your message and wanted to be bad, I'd just hammer you a bit more to put you in trouble.

Besides that there are some ISPs who do care about both keeping you online and fighting the low-life scums: the ISP XS4ALL from the Netherlands is (was at least) notoriously famous for that.

With all the exploits out there coming out on a nearly daily basis it's not exactly either as if having an army of a few tens of thousands of zombies was expensive...

Technically now ISPs could throttle the bandwith (or even disallow net access) to zombies boxen used in DDoS attacks in all the countries applying "x-strikes" rules.

So there may be light at the end of the tunnel.

It's not exactly as if DDoS was a fatality and nothing could be done about it.

Oh boy that one we're going to hear for a long time apparently :(

I know lots of people who paid $$$ for MBAs. And then they went on to make more $$$ than they would have without their MBAs. In a matter of two to three years they'd have make back what they paid their MBA.

How are they the "product" of the business school? To me they're the customer: they paid $$$ for the opportunity to then get $$$$$.

But it's sooooo easy to try to knock people down by repeating that "you're the product" mantra as if people were merchandise and the web is so full of people who just love to try to diminish others that I'm pretty sure we'll keep reading "you're the product" for a long time...

People do not realize that in some countries virtually all the citizen are carrying a Java SmartCard on them at all time (either an ID card or a medical security card). People do not realize that there are billions of devices running Java (like TV decoders) and that Java is even officially part of some specs (e.g. you cannot have a Blu-Ray player without having Java). In addition to basically power the entire banking infrastructure (it's damn near close to impossible to make an electronic payment without having Java involved in the process) and pretty much the entire corporate world, Java also powers a gigantic number of high-target websites (like eBay and FedEx).

And even in browsers, without needing applets, Java is also used to generate JavaScript (GWT and ClojureScript being to examples -- at this point ClojureScript still needs the JVM to compile to JavaScript).

And Android, of course.

Java is going to dwarf COBOL's legacy. Big times.

The real sadness here is that the writing was on the wall: any knowledgeable Java programmer knew, 15 years ago, that Java applets were an insecure piece of excremental technology.

You don't know how many time I've vomited on Java applet in Usenet's comp.lang.java.programmer years ago, saying how big of a mistake and loss of energy it was... Only to have the likes of Jon Skeet and Roedy Green defending Java applets tooth and nail.

And of course his "appeal to authority" consists in citing an article from the totally and utterly overrated Spolsky...

Dismissed.

I somehow doubt that the french person who registered java-0day.com is in compliance.

The idea isn't bad but it's a bad sad that everything is put together: mixing Java applets exploits with server-side exploit with regulard client-side / Java desktop exploits.

The problem is that there's a hole due to Java constructors being called (even when read-eval is set to false).

Here I'd say it's a bit different: it's kinda the whole of having read-eval set to true to be able to evaluate code. So when read-eval is set to false and yet rogue code happens to be called there's a serious issue. Basically the issue is that under the hood some Java constructors seems to be called and, if I understand the issue correctly, by knowing how Clojure works you can exploit Clojure / the JVM by crafting precisely what you want to pass to Java constructors (which shouldn't be called in the first place).

Here as I understand it it's not an "eval" exploit per se: it's Java constructors which are passed carefully crafted input.