If they are without JavaScript, you are stuck within the "power of expression" of HTML.
If they are without JavaScript, they're probably not the target market anyway. But suggesting that this limits you to HTML... really? I guess server side code doesn't exist?
If they are "powered" by JavaScript, the cross-browser compatibility and debugging/tracing on "what the hell is wrong" becomes quickly a nightmare...
Having done web development, frankly, no it doesn't, not if you know what you're doing.
everything is Runtime and interpreted, no strong typing,
Which means the application itself was much, much quicker to develop and easier to maintain. Also, I have to say, I've never once been saved by the type system that I can remember -- the kinds of bugs I run into, even if they're runtime, never arise because I was using an object of the wrong type. Not once.
a very loose "Object Oriented" programming paradigm,
Erm... What's "loose" about prototypal inheritance? What makes classical inheritance better?
No offense, but are you sure you actually understand the JavaScript object model? It may be that you understand it and dislike it, and prefer other models instead -- but most people who hate JavaScript for not being "OO enough", in my experience, don't really understand JavaScript at all.
managing the "context/status of the application" may - and will - create troubles due to the lack of concurrent programming,
Also means we don't need locking. That's right, web apps don't deadlock.
Why does everything have to be built on desktop apps dependent on the web or web browsers?
On the "web browser" front, what's your problem here? Do you have a pressing need to make an app work on a computer which has no web browser?
We've been doing desktops since dirt,
And we did shared servers long before that -- used to be a computer wasn't something everyone had on their desk.
The building blocks are well understood, highly developed and well documented.
The same can be said of the Web.
So why does it seem as if everybody wants to make us dependent on a 24/7 connection to the web,
Ok, how the hell did you get modded up with FUD like that? This is exactly the kind of FUD people used to spread about Linux -- untrue and you know it, so why say it?
Web apps can and do have offline modes, for the cases where it matters -- and there are plenty of desktop apps which require a constant internet connection. So on that count alone, there's no significant difference between a web app and a desktop app.
What's more, have you noticed how absurdly pervasive Internet access is these days? It's on airplanes. They won't even let you use your cell phone, but they'll give you wifi. Other than planes, anywhere you have a cell signal, you can have Internet. Granted, it's overpriced now, but this is also just the beginning -- and already, complaining about this is getting to be as absurd as complaining that you don't want to computerize your records/books/whatever because computers require power and paper doesn't. Internet is a utility.
You had more of a point with your subject line -- web services are indeed single points of failure. So are operating systems. Making something a web service means if it's at all decent, it's also now OS-independent, which means I've now lost the single-point-of-failure of Microsoft.
And don't get me started on clouds!!!
I agree, mostly because the term is so ill-defined. It has 2-3 different meanings, each as cloudy as the next.
Did events in Egypt not teach us anything about putting every thing on the web and in the cloud?
Events in Egypt taught us that when a government denies its people as fundamental a right as communication, the rest of the world will step in to help.
I can't imagine Photoshop or Maya being browser based.
There already are some photo-editing solutions, and WebGL is on the way.
Hell, their browser based help systems don't even work well...
That's not the fault of the browser -- there are plenty of browser-based help systems which work so much better than "on-line" help systems that I wonder why anyone does it that way. (Read "on-line" as "computerized help system, but still locally" -- the term probably predates popular use of the Internet.)
...because a website is a service, not an application.
So what do you call an application which is installed locally, but auto-updated? How is that different than a web application other than how the code happens to be cached locally?
An application is when you apply code to a discrete device.
...which seems like it's what happens every time I visit a website which runs code locally in my browser, unless it also happens to be constantly connected to some service.
Even if it is, there are local applications that also connect to services. Either way, I'm not seeing a useful distinction.
And my point is, if you choose to put yourself on "a form of dopamine addiction" by choice, that's far better than being prevented from doing so by force. Of course, better by far than either of these would be to actually go play some sports.
That many Americans don't seem to use their freedom for anything useful doesn't make them less free, it just makes them dumber.
I don't see why a website can't also be an application, and a bookmark does indeed seem to be the best way to "install" such an app.
I think Google's move here is to tap into the fact that people already have the concept of installing a traditional application, therefore a web app should be installable in the same way -- so rather than trying to educate people on how bookmarks could work here, they just offer people what they expect.
Huge data-centers don't screw around with that consumer grade crap.
So Google's data centers are small? From what I understand, they use 5400 and 7200 RPM drives, and with the amount of storage and redundancy they're working with, I can't see why they'd bother with anything enterprisey for the drives themselves.
Granted, for this application, you'd want faster drives, but this is a special case. Just how much does it take to stream raw HD video to disk? Even so, you'd expect the article to mention why the storage is impressive, and just having 100 TB of it... isn't, until we also find out what the throughput is.
I don't see how that could possibly be relevant. Would you rather not be free? In this case, would you rather be forced to sit zombified in front of a TV?
I can certainly agree that there's no particular reason anyone else should care about football, but I really don't see your point.
And if they want to stream game content to my system, that'd actually be innovation. Steam tried to do that originally, and it was almost awesome -- for some perverse reason, it would always pause downloads while playing a game, even a single-player game, so as not to lag you, but despite that, you could still have the next Half-Life level download in less than 30 seconds. Combine that with a huge local cache and I think it's a winner -- and Steam could pull that off.
The pricing model would be pretty cool, too, though I don't think that'd work well for me, as I tend to go months without playing any games at all.
However, streaming the game output to my system still just seems retarded. Even if it becomes feasible, it's still not something I ever want, even for multiplayer games. Whoever funded these guys needs to have it explained to them that "cloud" doesn't magically make something new and innovative -- sometimes, it just makes it retarded.
I don't really get what Iron adds, given I can disable everything relevant by unchecking a few boxes in the config panel. I guess if I was paranoid, I'd stick to Chromium...
When I set it to the same resolution, I got similar results. The only real disadvantage of the Google viewer was the fact that it was burning both cores.
I noticed a few other things, also -- the Google viewer was much, much easier to play with. I could drag it around (like Google Maps), I didn't have to wait for it to finish rendering before I could zoom further, it seemed to render in chunks. The Flash viewer was eventually faster once I got deep enough, but before then, it was pretty comparable, except it would zoom first, then start rendering, and become entirely unusable during the entire rendering process.
That doesn't tell me Flash is faster than JavaScript, especially when ActionScript's Tamarin engine isn't terribly different than modern JavaScript engines (and is capable of running JavaScript also). Instead, what it tells me is that these are very different implementations with different characteristics, which makes comparison difficult.
Chrome seemed to be running at least five or six independent processes. I only have two cores to test it with, though...
Also, while I doubt it has much of an effect, keep in mind that all major Windows browsers are 32-bit right now, mostly because Flash is 32-bit, which means the browsers are 32-bit, which means Silverlight is 32-bit, which means the browsers are 32-bit... My Chrome is 64-bit, but it can run a 32-bit Flash. Since this is native JS, it'll actually run in 64-bit mode.
I don't know, I was pretty impressed that, as slow as this was, it was still reasonable on about half of my 1920x1200 display. I don't know that a 486 could even drive that big a display.
No, the goal isn't moving "heavy lifting" into the cloud. The advantages of a web application are portability and storage on someone else's servers -- exactly the same advantages that Gmail has always had, and Hotmail had before Gmail.
The goal of pushing what HTML can do is to keep the advantages of the Web, but also bring the advantages of a fat client -- lower bandwidth, less server resources, and clients which use more resources, but also do more with them.
And the point of text is to make it transparent.
I don't see "laziness" anywhere -- in fact, as a hardware designer, I somehow doubt you have any idea what it takes to be a really good web developer. It's true, I don't have to worry about manual garbage collection, let alone voltages, heat, and all the other messiness of the hardware world, and I'm grateful that you take care of that. What I do need is a working knowledge of HTML, XML, CSS, JavaScript, HTTP, and all the different browser quirks involved in implementing that, in addition to some basic graphical editing skills, and on the server side I likely need at least one application language (Ruby, Java,.NET, whatever) along with at least one external DSL the database speaks (SQL). In order to synthesize these into a functioning application, I should also be familiar with the principles of REST, I can't really avoid SOAP as much as I'd like to, and I also have to think about OAuth and security in general (some security issues which don't even apply to standalone apps), HTTPS, HTTP Push (web sockets, comet, etc), how browsers handle caching, and random accumulated tricks of the trade, like CSS "sprites", JavaScript minification, better make sure we turn on gzip compression in the webserver...
This isn't meant to be me whining that my job is so hard, or even that it's necessarily harder than other application platforms -- I like to think it's easier. The point is that people don't make web apps out of "laziness" -- if laziness was truly a factor, I'd make a commandline app, throw it up as a source tarball, and say "You figure it out," and I will admit to doing that when I can't justify putting the effort in to making it usable.
No, the reason I'd make a web app is that I want something people can just use by typing a URL from any computer with a decent browser, without worrying about installing something, without needing to manage keeping their data backed up and synced across computers, and without forcing me to support some OSes and platforms and abandon others.
As for "inefficient and wasteful", sure, there's room for improvement, but have you done an honest comparison between modern JavaScript engines and other VMs? Or are you seriously suggesting that all apps, especially mobile apps, should be written in a language where buffer overruns are still a very real possibility? Because I'll take a little reduced battery life in exchange for stability, and especially from the improved battery life by avoiding some malware.
Considering I can't find a single offence these "evil corporations" have done that bothers me
How very noble of you.
Here's a thought: When the ISPs have the right to throttle or ban a protocol outright, that will eventually hit a protocol you care about. Also, throttling implies banning:
(I couldn't care less if my BitTorrent traffic is throttled, BitTorrent is something I'd rather download overnight anyway)
You clearly have no idea just how much torrent traffic can be throttled. Try a download that should take a few hours (or overnight) instead taking over a week. Do you care yet?
I'd much rather see Verizon and Comcast fight for my business than have the FCC tell me what their vision of the Internet should be.
Are you sure? Because Verizon and Comcast are both doing things we'd rather they stop doing. Who, exactly, am I supposed to be switching to? There isn't exactly a "Joe's Family Cellular" in my area to sell me Internet service, and where I have seen local ISPs, they generally have to buy their service from a larger ISP anyway.
I don't own stock in Verizon or Comcast, and without any other options, I have exactly zero leverage to get them to stop what they're doing. By contrast, I do at least have a vote -- I get to elect the people who appoint positions within the FCC.
When the free market works, I prefer it to government intervention. It's failing pretty badly here.
So this 'workaround' is great until they patch the law up in a few years' time.
At which point, we're stuck with NAT and all its disadvantages, rather than a far superior IPv6 option, because the technically inferior version happened to be more convenient legally until the law was fixed.
If you know anything about JavaScript or HTML, you should see clearly that the code snippet you cited should not have fixed it. Shouldn't have had any effect whatsoever, really. I mean, why should adding <div></div> to the bottom of a document change the behavior of, well, anything?
Just because it can be worked around in JavaScript doesn't mean it's not a Chrome issue.
They may have lost any sense of a moral high ground, but they didn't lose their humanity. Yes, there are some people you may never reach. If you stop trying, there will be _more_ such people.
It's not enough to decide this is an evil fuck deserving no sympathy. WHY did they do what they did? What motivates them? Was it a grossly inappropriate response to a legitimate offense? Even if the offense isn't legitimate, can we understand what the psychology of the situation is, and maybe empathize just a bit?
I laughed, too. I view them as an enemy, too, and if it came to it, I'd have no problem killing them myself.
But that doesn't mean they've suddenly become inhuman, a monster. As soon as you believe that, you lose any chance you might've had to fix the real problem, and to actually start to prevent this kind of thing.
That's par for the course in a culture where, as Harris says, "Your daughter has been raped, and what you want to do is kill her." If Egypt doesn't have that problem, they're definitely progressive by Muslim standards.
Actually, the glitching that opened a hole in the system was done first through OtherOS.
Well, here's what jonwil said:
The real kick-starter for the hackers was the desire to run OtherOS on the slim PS3 (which didnt support it even though there is no technical reason it couldn't, just Sony wanting to stop people buying PS3s for Linux only and not buying games)
So, basically, in the process of trying to re-enable that, they got just enough access to make Sony nervous, so Sony shut down Other OS.
In other words, the message, if Sony is listening, is that this entire thing could've been avoided by continuing to support Linux. Every device they don't support Linux on becomes a target. They didn't support it on the Slim, so that was the first target. Then they removed it, so now everyone's pissed off and the entire PS3 is a target.
Slashdot Mirror
If they are without JavaScript, you are stuck within the "power of expression" of HTML.
If they are without JavaScript, they're probably not the target market anyway. But suggesting that this limits you to HTML... really? I guess server side code doesn't exist?
If they are "powered" by JavaScript, the cross-browser compatibility and debugging/tracing on "what the hell is wrong" becomes quickly a nightmare...
Having done web development, frankly, no it doesn't, not if you know what you're doing.
everything is Runtime and interpreted, no strong typing,
Which means the application itself was much, much quicker to develop and easier to maintain. Also, I have to say, I've never once been saved by the type system that I can remember -- the kinds of bugs I run into, even if they're runtime, never arise because I was using an object of the wrong type. Not once.
a very loose "Object Oriented" programming paradigm,
Erm... What's "loose" about prototypal inheritance? What makes classical inheritance better?
No offense, but are you sure you actually understand the JavaScript object model? It may be that you understand it and dislike it, and prefer other models instead -- but most people who hate JavaScript for not being "OO enough", in my experience, don't really understand JavaScript at all.
managing the "context/status of the application" may - and will - create troubles due to the lack of concurrent programming,
Also means we don't need locking. That's right, web apps don't deadlock.
almost everything is asynchronous,
You say that like it's a bad thing.
Why does everything have to be built on desktop apps dependent on the web or web browsers?
On the "web browser" front, what's your problem here? Do you have a pressing need to make an app work on a computer which has no web browser?
We've been doing desktops since dirt,
And we did shared servers long before that -- used to be a computer wasn't something everyone had on their desk.
The building blocks are well understood, highly developed and well documented.
The same can be said of the Web.
So why does it seem as if everybody wants to make us dependent on a 24/7 connection to the
web,
Ok, how the hell did you get modded up with FUD like that? This is exactly the kind of FUD people used to spread about Linux -- untrue and you know it, so why say it?
Web apps can and do have offline modes, for the cases where it matters -- and there are plenty of desktop apps which require a constant internet connection. So on that count alone, there's no significant difference between a web app and a desktop app.
What's more, have you noticed how absurdly pervasive Internet access is these days? It's on airplanes. They won't even let you use your cell phone, but they'll give you wifi. Other than planes, anywhere you have a cell signal, you can have Internet. Granted, it's overpriced now, but this is also just the beginning -- and already, complaining about this is getting to be as absurd as complaining that you don't want to computerize your records/books/whatever because computers require power and paper doesn't. Internet is a utility.
You had more of a point with your subject line -- web services are indeed single points of failure. So are operating systems. Making something a web service means if it's at all decent, it's also now OS-independent, which means I've now lost the single-point-of-failure of Microsoft.
And don't get me started on clouds!!!
I agree, mostly because the term is so ill-defined. It has 2-3 different meanings, each as cloudy as the next.
Did events in Egypt not teach us anything about putting every thing on the web and in
the cloud?
Events in Egypt taught us that when a government denies its people as fundamental a right as communication, the rest of the world will step in to help.
I can't imagine Photoshop or Maya being browser based.
There already are some photo-editing solutions, and WebGL is on the way.
Hell, their browser based help systems don't even work well...
That's not the fault of the browser -- there are plenty of browser-based help systems which work so much better than "on-line" help systems that I wonder why anyone does it that way. (Read "on-line" as "computerized help system, but still locally" -- the term probably predates popular use of the Internet.)
...because a website is a service, not an application.
So what do you call an application which is installed locally, but auto-updated? How is that different than a web application other than how the code happens to be cached locally?
An application is when you apply code to a discrete device.
...which seems like it's what happens every time I visit a website which runs code locally in my browser, unless it also happens to be constantly connected to some service.
Even if it is, there are local applications that also connect to services. Either way, I'm not seeing a useful distinction.
And my point is, if you choose to put yourself on "a form of dopamine addiction" by choice, that's far better than being prevented from doing so by force. Of course, better by far than either of these would be to actually go play some sports.
That many Americans don't seem to use their freedom for anything useful doesn't make them less free, it just makes them dumber.
I don't see why a website can't also be an application, and a bookmark does indeed seem to be the best way to "install" such an app.
I think Google's move here is to tap into the fact that people already have the concept of installing a traditional application, therefore a web app should be installable in the same way -- so rather than trying to educate people on how bookmarks could work here, they just offer people what they expect.
Huge data-centers don't screw around with that consumer grade crap.
So Google's data centers are small? From what I understand, they use 5400 and 7200 RPM drives, and with the amount of storage and redundancy they're working with, I can't see why they'd bother with anything enterprisey for the drives themselves.
Granted, for this application, you'd want faster drives, but this is a special case. Just how much does it take to stream raw HD video to disk? Even so, you'd expect the article to mention why the storage is impressive, and just having 100 TB of it... isn't, until we also find out what the throughput is.
Given freedom, yes, some people abuse it.
I don't see how that could possibly be relevant. Would you rather not be free? In this case, would you rather be forced to sit zombified in front of a TV?
I can certainly agree that there's no particular reason anyone else should care about football, but I really don't see your point.
I did, out of morbid curiosity, and I learned something I didn't know: When Fox isn't trying to push an agenda, they're downright boring.
And if they want to stream game content to my system, that'd actually be innovation. Steam tried to do that originally, and it was almost awesome -- for some perverse reason, it would always pause downloads while playing a game, even a single-player game, so as not to lag you, but despite that, you could still have the next Half-Life level download in less than 30 seconds. Combine that with a huge local cache and I think it's a winner -- and Steam could pull that off.
The pricing model would be pretty cool, too, though I don't think that'd work well for me, as I tend to go months without playing any games at all.
However, streaming the game output to my system still just seems retarded. Even if it becomes feasible, it's still not something I ever want, even for multiplayer games. Whoever funded these guys needs to have it explained to them that "cloud" doesn't magically make something new and innovative -- sometimes, it just makes it retarded.
From the caption on the pretty picture in TFA:
Brain slice of the frontal cortex of a rat showing nerve cells before and after treatment with the iTBS protocol
When I read that, the very first thing I thought of was this ITBS, which pretty much just made learning more obnoxious.
I don't really get what Iron adds, given I can disable everything relevant by unchecking a few boxes in the config panel. I guess if I was paranoid, I'd stick to Chromium...
When I set it to the same resolution, I got similar results. The only real disadvantage of the Google viewer was the fact that it was burning both cores.
I noticed a few other things, also -- the Google viewer was much, much easier to play with. I could drag it around (like Google Maps), I didn't have to wait for it to finish rendering before I could zoom further, it seemed to render in chunks. The Flash viewer was eventually faster once I got deep enough, but before then, it was pretty comparable, except it would zoom first, then start rendering, and become entirely unusable during the entire rendering process.
That doesn't tell me Flash is faster than JavaScript, especially when ActionScript's Tamarin engine isn't terribly different than modern JavaScript engines (and is capable of running JavaScript also). Instead, what it tells me is that these are very different implementations with different characteristics, which makes comparison difficult.
Chrome seemed to be running at least five or six independent processes. I only have two cores to test it with, though...
Also, while I doubt it has much of an effect, keep in mind that all major Windows browsers are 32-bit right now, mostly because Flash is 32-bit, which means the browsers are 32-bit, which means Silverlight is 32-bit, which means the browsers are 32-bit... My Chrome is 64-bit, but it can run a 32-bit Flash. Since this is native JS, it'll actually run in 64-bit mode.
What resolution was your 486 rendering at?
I don't know, I was pretty impressed that, as slow as this was, it was still reasonable on about half of my 1920x1200 display. I don't know that a 486 could even drive that big a display.
Do you have a comparable Flash fractal viewer that performs better?
So let's see...
No, the goal isn't moving "heavy lifting" into the cloud. The advantages of a web application are portability and storage on someone else's servers -- exactly the same advantages that Gmail has always had, and Hotmail had before Gmail.
The goal of pushing what HTML can do is to keep the advantages of the Web, but also bring the advantages of a fat client -- lower bandwidth, less server resources, and clients which use more resources, but also do more with them.
And the point of text is to make it transparent.
I don't see "laziness" anywhere -- in fact, as a hardware designer, I somehow doubt you have any idea what it takes to be a really good web developer. It's true, I don't have to worry about manual garbage collection, let alone voltages, heat, and all the other messiness of the hardware world, and I'm grateful that you take care of that. What I do need is a working knowledge of HTML, XML, CSS, JavaScript, HTTP, and all the different browser quirks involved in implementing that, in addition to some basic graphical editing skills, and on the server side I likely need at least one application language (Ruby, Java, .NET, whatever) along with at least one external DSL the database speaks (SQL). In order to synthesize these into a functioning application, I should also be familiar with the principles of REST, I can't really avoid SOAP as much as I'd like to, and I also have to think about OAuth and security in general (some security issues which don't even apply to standalone apps), HTTPS, HTTP Push (web sockets, comet, etc), how browsers handle caching, and random accumulated tricks of the trade, like CSS "sprites", JavaScript minification, better make sure we turn on gzip compression in the webserver...
This isn't meant to be me whining that my job is so hard, or even that it's necessarily harder than other application platforms -- I like to think it's easier. The point is that people don't make web apps out of "laziness" -- if laziness was truly a factor, I'd make a commandline app, throw it up as a source tarball, and say "You figure it out," and I will admit to doing that when I can't justify putting the effort in to making it usable.
No, the reason I'd make a web app is that I want something people can just use by typing a URL from any computer with a decent browser, without worrying about installing something, without needing to manage keeping their data backed up and synced across computers, and without forcing me to support some OSes and platforms and abandon others.
As for "inefficient and wasteful", sure, there's room for improvement, but have you done an honest comparison between modern JavaScript engines and other VMs? Or are you seriously suggesting that all apps, especially mobile apps, should be written in a language where buffer overruns are still a very real possibility? Because I'll take a little reduced battery life in exchange for stability, and especially from the improved battery life by avoiding some malware.
What's the point of the canvas tag without an API?
Considering I can't find a single offence these "evil corporations" have done that bothers me
How very noble of you.
Here's a thought: When the ISPs have the right to throttle or ban a protocol outright, that will eventually hit a protocol you care about. Also, throttling implies banning:
(I couldn't care less if my BitTorrent traffic is throttled, BitTorrent is something I'd rather download overnight anyway)
You clearly have no idea just how much torrent traffic can be throttled. Try a download that should take a few hours (or overnight) instead taking over a week. Do you care yet?
I'd much rather see Verizon and Comcast fight for my business than have the FCC tell me what their vision of the Internet should be.
Are you sure? Because Verizon and Comcast are both doing things we'd rather they stop doing. Who, exactly, am I supposed to be switching to? There isn't exactly a "Joe's Family Cellular" in my area to sell me Internet service, and where I have seen local ISPs, they generally have to buy their service from a larger ISP anyway.
I don't own stock in Verizon or Comcast, and without any other options, I have exactly zero leverage to get them to stop what they're doing. By contrast, I do at least have a vote -- I get to elect the people who appoint positions within the FCC.
When the free market works, I prefer it to government intervention. It's failing pretty badly here.
So this 'workaround' is great until they patch the law up in a few years' time.
At which point, we're stuck with NAT and all its disadvantages, rather than a far superior IPv6 option, because the technically inferior version happened to be more convenient legally until the law was fixed.
If you know anything about JavaScript or HTML, you should see clearly that the code snippet you cited should not have fixed it. Shouldn't have had any effect whatsoever, really. I mean, why should adding <div></div> to the bottom of a document change the behavior of, well, anything?
Just because it can be worked around in JavaScript doesn't mean it's not a Chrome issue.
What's more, why is this explicitly clarified as a Webkit bug by Chromium developers if it's not a Chrome issue?
Seems like most people use TextMate. This sucks, but I have to agree. There are plenty of tools that work well enough with Ruby.
It does, however, fuel my hatred for Oracle.
They may have lost any sense of a moral high ground, but they didn't lose their humanity. Yes, there are some people you may never reach. If you stop trying, there will be _more_ such people.
It's not enough to decide this is an evil fuck deserving no sympathy. WHY did they do what they did? What motivates them? Was it a grossly inappropriate response to a legitimate offense? Even if the offense isn't legitimate, can we understand what the psychology of the situation is, and maybe empathize just a bit?
I laughed, too. I view them as an enemy, too, and if it came to it, I'd have no problem killing them myself.
But that doesn't mean they've suddenly become inhuman, a monster. As soon as you believe that, you lose any chance you might've had to fix the real problem, and to actually start to prevent this kind of thing.
That's par for the course in a culture where, as Harris says, "Your daughter has been raped, and what you want to do is kill her." If Egypt doesn't have that problem, they're definitely progressive by Muslim standards.
Actually, the glitching that opened a hole in the system was done first through OtherOS.
Well, here's what jonwil said:
The real kick-starter for the hackers was the desire to run OtherOS on the slim PS3 (which didnt support it even though there is no technical reason it couldn't, just Sony wanting to stop people buying PS3s for Linux only and not buying games)
So, basically, in the process of trying to re-enable that, they got just enough access to make Sony nervous, so Sony shut down Other OS.
In other words, the message, if Sony is listening, is that this entire thing could've been avoided by continuing to support Linux. Every device they don't support Linux on becomes a target. They didn't support it on the Slim, so that was the first target. Then they removed it, so now everyone's pissed off and the entire PS3 is a target.