Slashdot is powered by your submissions, so send in your scoop


Forgot your password?

Comment Re:What is a browser anyway? (Score 1) 158

It should in my opinion have resource urls for each message, that's a design flaw that they get away with because its a closed web app used by one person with no information sharing. I their other apps like calendars they use stateless Uris for each doc though for obvious reasons.

Others who have tried this on the open web, like twitter and their crazy hashbang, have been roundly condemned for it and usually given up as its throwing away one of the biggest advantages on the web.

Comment Re:What is a browser anyway? (Score 1) 158

The problems with HTML/web arise because it is stateless, browsers differ in their implementation, and the only language available on the front end is js, which is not terrible, but not beautiful either, and content is not always separated from code.

The many advantages of HTML/web come from the fact that it is stateless, most operations are idempotent and cachable, URIs can be shared, and that it's so simple even humans can create it by hand (and getting simpler with html5), readers get to control presentation and parse content, writers get to use any language on the server, content is easy to separate from code, there is no one way to do things or awful widget library, and browsers are constantly pushing the envelope.

Personally I don't want a browser experience just like a native app, there are several aspects of web apps which I'd like to keep - urls, fast updates, stateless operation, control over presentation, open data, and many from a dev perspective, chief amongst which is i don't need to rely on a platform vendor at all, and deal with their annoying toolkit and their currently blessed technology of the year.

The only thing I'd change about html dev is a better front end language (ideally a sandboxed vm shared by all browsers on which people can port whatever language they want) and a faster protocol like spdy, otherwise it's really not bad compared to mobile or desktop app dev, the advantages far outweigh the disadvantages.

Comment Re:Review Ruby for the perl enthusiast please (Score 3, Informative) 121

Perl's speed is pretty similar to Ruby, it's nowhere near the Java VM nowadays, plus Ruby is available on the JVM if that's what you prefer to use. But the parent was talking about system admin scripts and little one liners run on the command line. If you're expecting them to be 'webscale' you're talking about something else entirely. I don't know about you but my system admin scripts are not expected to scale past the few machines I work on and run by precisely one user at a time, they're not user-facing scripts and therefore performance is not critical - they could be in any language really, I don't really use one-liners but it is quite possible to do them in all those languages, even Python.

Finally, re Twitter, if you try to reinvent a messaging server using a CRUD web app (a la twitter), you can expect all kinds of pain, even if you write it in enterprise ready Java in the first place. I imagine their problems were more down to entirely the wrong architecture, though now that they are one of the biggest sites on the internet, things like language choice will become very important for them. It's interesting though that a site like Facebook compiles PHP to C++ and then to one big binary in order to stay up and still use one of the slowest languages available - if they wished twitter could easily have done something simliar with Ruby or moved to using the ruby on the JVM, but the new people brought in to make it work were probably coming from Java backgrounds and as it need a rewrite, they thought why not, and why not indeed, it's worked out pretty well for them. They were still on Ruby 1.8.7 till the end I think, which was pretty insane given the improvements in Ruby 1.9 and points to serious problems with the older code.

Comment Re:Review Ruby for the perl enthusiast please (Score 2, Informative) 121

Apart from the maths libraries, multithreading, UTF support (only just in - enjoy the bugs!) cross platform GUIs (TK or Fox. WTF if Fox?)
Yep, half the speed of perl and a web toolkit more obscure than PHP.

Ruby has maths libraries (but not as extensive as Python here IMHO), threading, has had Unicode and UTF support for years (since 1.9), and has good support for the best scripting language UI if you ask me (HTML displayed in a browser with the built in web server). I suppose if your idea of 'serious programs' is desktop apps using the platform GUI through some glue code, then you're out of luck (frankly I wouldn't use Perl OR Python for that either, just use C, C++ and/or the platform language of choice). That's a silly definition of 'serious' though.

Re the speed and web toolkit, you clearly don't know what you're talking about there, plenty of options on Ruby, none of them obscure or difficult, and speed is pretty good nowadays, certainly good enough for almost all applications save extensive number crunching, it's really not a problem in the real world.

Pick your tools to suit the particular thing you're building (i.e. don't pick a scripting language to build a desktop app), but why limit yourself with silly misconceptions about tech? It's only a scripting language, comparable to many others and suitable for most of the same sort of problems.

Comment Re:Review Ruby for the perl enthusiast please (Score 1) 121

That's not really true, you can easily write code without OO setup in ruby, in fact you could write code without defining functions if you wish for one liners. e.g. here's a little one liner to count the words in a file.

ruby -ane 'w = (w || 0) + $F.size; END { p w }' test.txt

It can be used very like perl if you wish.

Comment Re:Review Ruby for the perl enthusiast please (Score 4, Insightful) 121

1. Ruby is not a toy not suitable for 'serious' programs, it's very similar to Python in fact, it's not as strong on science or math though as python because of libraries available in Python, if that's what you mean, say that, it's far more convincing.
2. Python could easily replace Perl for system admin tasks - come up with specific criticisms if you have met with any roadblocks - you would likely find similar problems with Ruby to Python if you somehow couldn't manage sysadmin or text scripting with Python.
3. Ruby, Python and Perl are actually quite interchangeable and could all be used for 'serious' tasks, or for short admin or text processing - all 3 are ideally suited to these things, and frankly the differences are not huge, Perl is slightly gnarlier, Python slightly stricter, Ruby slightly more anarchic, all 3 would get the job done easily.
4. WTF has Rails got to do with any of this? Troll much?
5. Why should we waste our time trying to convince someone with such trenchant and at the same time wildly inaccurate preconceived ideas?

Comment Re:Overraction (Score 2) 117

Most other technologies don't have this flaw as a core feature, you have to code it that way. So you might want to revisit your "QED".

Most other technologies do have exactly this kind of exploit (I think this is more serious than the article states, it's a remote execution flaw, not SQL injection as you seem to assume from reading the summary), and many have and will continue to suffer from SQL injection flaws as they find their safeguards weren't quite what they thought they were. Here's a hole in the Java from the day after (note that I don't think that makes Java immediately unsuitable for any use):

Security is a process, i.e. you have to keep continually on top of it and react quickly to disclosures. It's not something you can just assume because you chose 'secure' technology, or audit once and forget about, and it's not something which any particular technology has a monopoly on. It's quite possible to build secure sites with rails if you know what you're doing, do your own parameter checking on top of what rails provides, and keep on top of security updates. Perfect security probably isn't attainable with any language, but I'm sure you weren't implying that it was. Curious that you seem to think Rails is particularly insecure though, have you ever used it?

Which tool in particular did you feel would work for this purpose? All the major languages or frameworks I can think of have had serious security problems in the past, none are a priori secure.

Comment Re:Overraction (Score 1) 117

Perhaps it'll mean they get more money devoted to securing the site after this has blown over - time spent testing the site and looking at security is probably more important than the specific technology used (almost every major framework has regular security problems like this), contrary to the righteous flaming and trolling for tech which is bound to erupt in the wake of your post.

The best answer to this would be to not use a system that is known to not be secure to begin with. That's a massive failure on the developer's part.


Comment Re:Overraction (Score 5, Interesting) 117

This one is quite a serious flaw, and the data this website in question deals with is very important data (citizen IDs), so I'm not surprised they're taking it seriously. The service being down for a day or two is probably better than millions of ids getting hacked. Perhaps the fix breaks something on their website, and they have to fix that before they can take it back up again? It has produced issues like this I think:

Most sites (like Slashdot) really don't matter if they are hacked and could just stay up, but something dealing with identity like this deserves special attention, and I'm sure they have good reasons if they have taken the site down while they look at workarounds. Perhaps it'll mean they get more money devoted to securing the site after this has blown over - time spent testing the site and looking at security is probably more important than the specific technology used (almost every major framework has regular security problems like this), contrary to the righteous flaming and trolling for tech which is bound to erupt in the wake of your post.

Comment Re:Ruby Injection (Score 1) 81

Actually that's not true, since 3.0 at least the default style (from scaffolds for example) has been Post.find(params[:id]), many people don't use dynamic finders at all, as you can use where(...) and scopes instead.

Also, according to the advisory, the HMAC is required, that's really very unusual and important.

Comment Re:bug found, bug fixed, bug deal (Score 2) 81

If you publish the key used to sign sessions, people could fake session cookies and log in as someone else for example so this vulnerability would be the least of your problems. It's a problem all by itself, and is not something that is possible to do without publishing your entire app source on GitHub for example and forgetting to hide the passwords/keys which should be kept private (e.g db passwords, hmac). You can't publish it by mistake by misconfiguring your web server for example, it would have to be a deliberate choice to publish the entire app source on another channel including secrets.

So for the majority of sites it seems this vuln (and others requiring the secret key) is a non-issue.

Comment Re:bug found, bug fixed, bug deal (Score 5, Informative) 81

When it's a major security flaw?

According to the article, this is not in fact a major security flaw, unless you have made your secret session key (HMAC) for the app public, and are using old style finder methods like find_by_id(2) etc. For a start the attacker has to know your HMAC - this is randomly generated when creating a rails app, and is not supposed to be publicly disclosed, though if your app is open source and you forgot to change it and left it in a public repo, it is possible someone could find it. The vast majority of rails apps this is not going to apply to, and there are obvious reasons you shouldn't make your session signing key public anyway.

So it looks like this is a bug which the majority of rails users won't have to worry about, but it's good that they fixed it.

Slashdot Top Deals

"They that can give up essential liberty to obtain a little temporary saftey deserve neither liberty not saftey." -- Benjamin Franklin, 1759