The best way is to zip all your photos with a password, rename the file to "Britney Spears secret sex tape 1080p DTS.mkv" and put it online on The Pirate Bay.
Probably the best advice of all. If after 6 month you have 1TB of digital data, you're probably doing it wrong. You won't have enough time in the remaining of your life to look at all that data, let alone sort it out to make it half useful.
Otherwise, just use external HDDs. Buy 4. Routine check every year. Two where you backup every week, one every month that you store at your parents and one another at you in laws.
Well... they stopped the project once it was up. Their goal was to demonstrate the Java technology, not to make a web browser as a sustained product.
Yes plugins were Java based of course, but I'm sure that could have worked. But let me tell you, by 200, we (linux & non windows users) were in sore need for a web browser. A Java-based one would have done it;-)
I use it to submit forms, so that I avoid the problem of having to refresh a page in which a user has made some input. In this regard, I save time and energy, and the user has a faster response. It's all a win.
I also use it to refresh some components in html pages. No DOM is needed there as it is as easily done by grabbing an HTML fragment from the AJAX request and putting wherever you need with the innerHTML attribute. Again, it saves bandwidth and time to code. Another win.
AJAX is a powerful tool that may need some tooling for some. Interpreting a JSON response is a one liner for example. No kludge in there. Manipulating the DOM is something very powerful too, but again it may need some tooling for some.
All in all, yes, browsers were once made to display static content. That was before DOM-based browsers. Things have changed.
But there are simple solutions for that problem. The fact that Chrome abuses some TCP feature is a Chrome problem, not an AJAX one. Nothing prevents a browser to set a keep alive in the HTTP headers and let a socket open to the server. This is an existing feature of HTTP, respect perfectly TCP, and was even designed for that very purpose !
I have to say I'm not familiar with that specific subject, but I fail to see a problem there.
Ajax conforms to the HTTP protocol pretty much like everything else. It is an http request sent by the browser basically indistinguishable from another regular http request to get an image or an html file. Nothing was done in the HTTP protocol for AJAX. What are you talking about exactly?
You can infer a lot from the "Java is dead" crowd, like they probably don't have a job in IT
Wrong, I do.
, or they don't use UNIX
Wrong, I do.
, like to say things are dead a lot
Uhhh, nope, I don't.
, etc.
Looks like you have a hard time thinking outside the box. You environment is not the environment of everyone working in IT and on unices. Surprise, you are not the center of the world.
You know, the issue here is not the browser. It's the HTTP protocol - it was simply designed for nothing else but static content. The number of kludges and patches you need to implement basic session handling and interactvity is getting ridiculous. Do we even have a RFC for cookies, for example?
The only flaw with HTTP is that it is stateless. It is also its greatest strength.
Back in the days, I was impressed by HotJava. This was a full blown web browser developed in Java. No Javascript. It worked well and, as expected, ran Java Applets natively.
I still don't know why they dropped the development...
I have to say I am actually surprised to see how many people still have a Java plugin for their browsers. I had a look at the analytics of my website and it looks like more than 80% of my visitors have one.
I heavily use Java on the desktop (Eclipse, etc) and on my servers (Tomcat) but I thought Java Applets to be dead for long.
You gotta start somewhere. The best way to start is at the source: The school system. How do you get to improve the school system with such uneducated politicians is the problem. But you can't focus on educating politicians. By the time you'll reach through their thick skulls, they'll be out of office and you have to start again with the newcomers.
I have to say though, being french, that I'm glad that you got the Olympics games instead of Paris. By these debt-crisis times, spending as much as you do (and as much as we would have done) for such a thing is kind of silly.
Note that I'm not saying we are better in this regard. We (as a nation) wanted it, and I'm sure we would have spent as much money as you do if we would have had them. Fortunately, we suck ass at marketing, so there is no way in hell we could have beat you to it.
Perhaps not in the days of nested tables, but CSS has grown up since then, and absolutely can be used to do page layout.
I'm really sorry, I know this will not come out well, but the only possible explanation I can see is that you've never used CSS. At least never used to do page layout.
Page layout is controlled by HTML and CSS. CSS can hide, show, left or right float something, but that is about it. And that's already great. Let's take a simple example: I have a layout with three columns: The left menu, the right menu and the content in the middle. On small screens (say, <800px), I want both my menus to be on the left, on top of each other, because there's little room for the content otherwise. How can I do that with CSS?
Short answer: I can't.
Long answer: I *could* by absolutely positioning my elements. But to position absolutely something just below something else, you have to know the size of the first element. So either it's static content and you know it, or you have to use JavaScript. That doesn't play well with content that comes from a database for example.
That's basic page layout. CSS is completely unable to do it all by itself. Layout in HTML is done by HTML AND CSS, because of the simple fact that the flow of elements in the page is defined by the order in which they appear in an HTML document, and CSS can do nothing about it.
So no, I am sorry, but while CSS can help a great deal for page layout, it cannot do everything. And if you want to change the layout on a media query, you're often left alone and have to resort to a few javascript on-the-fly modifications to the DOM to help you out. Unfortunately, there is no way to trigger a javascript on an activation/deactivation of a media query, so it means more hacks and tricks. That sucks, much like user-agent sniffing. But that's life.
I must have a problem expressing myself, for you are accusing me of not liking standards when I do know they are what makes the web today manageable. And I respect and love them.
Well, all major "things" in the internet, those who make it working and useful, have been brought to us with that "theoretical, academical process" you dislike. It's your right, of course.
Please cite me ONE of my sentences that can be construed to mean that I dislike that process. I bet you can't. I do like and respect that process. However I do believe that people should be allowed to use the implementations as they see fit. I don't believe everyone should be restrained from using anything that hasn't been published in a final state.
What you are pushing forward is known as "act soon, fix later" because "there's no time" or because "we need it yesterday". This is what I personally dislike a lot.
That's absolutely not what I am pushing forward. If something works in ALL browsers and is a part of a draft standard and is widely used, I think it's a safe bet that it won't disappear from browsers overnight. It's also a safe bet that it won't disappear from the standard. So I think it's a safe bet that you won't have to fix it later. As a result, I think it would be silly to not use said features, just because "but the standard is in a draft state".
You say all browsers support the "interim HTML5". Have you tried this site with ALL your browsers? Also the mobile ones? Each of them only partially supports one of the intermediate drafts. Which is a two level uncertainty. And what about this one? You surely know about the "cross browser" issues with Javascript. It started with two different implementations of a non-standardized scripting language. There are still hundreds of lines of code being run in almost all web pages just to cope with it. And if you think about the big mess all the current browsers are doing with the mature HTML4 and CSS2, you can imagine how messy the scenario will be with HTML5. Web sites will still need to support all those dialects and variants of the HTML5, if they want to show the intended way.
No, all browsers don't support everything, this is true. However there is a sizeable subset of HTML5 and CSS3 that is supported by all latest versions of all browsers. I find it silly to advise people not to use that subset. So I do and I advise people to use it.
Look, a stupid bug is not being fixed in any open source browser. It's about a core HTML4 element which has forced hundreds of HTML publishers to look for partial workarounds.
Sure, but the world is not all black and white. I'm advocating a particular shade of gray, that is all. Of course, don't use something that is broken in most browsers. And no, there will never be a time when all bugs will be fixed and all implementations will be alike. Hopefully, that will never happen. So we'll always have to cope with cross-browser compatibility issues. This is the reality of life. You may live in a w3c smelling ivory tower of cross-browser compatibility heaven, but I do build websites in the meantime. So I cope with it.
So, in my humble opinion, standards matter. And also a lot.
The Xoom has a dual core processor. I have an iPhone 3GS which is a piece of crap compared to that and my UI feels as snappy as the Xoom's (I know, I have a few friends with a Xoom) Every piece of Android I've seen on comparable hardware as the 3GS is laggy and feels just horribly slow.
People navigating with JavaScript turned off will be glad to see something. Plus, you AJAX-based mechanisms might work well with Chrome, Safari and IE8+, and you might not want to get to the trouble to troubleshoot your UI on older IEs. GMail has a basic html interface. Do you think they did it so that they would "guess" what the user want? No, they know people want their mail. But there is a limit to how much time you want to throw in to support 3% of your audience.
Plus, an HTML-only version is perfect for crawlers.
As I said, it looks like the best of both worlds to me.
Thanks for the link, very informative. I fail to see the rael-world application though.
I mean, if you go to the trouble of writing every "page" as an HTML fragment, why not go to the last mile and provide a pure HTML version of your site?
Let's say your site is called "foo.com". The help section would be "foo.com?help", then you render your links as being:
<a href="?help" onclick="loadPage('#help')">
The loadPage method would just call the data for "help" and modify the url to be foo.com#help. If javascript is inactive (Google, specific browsers that you'd rather have the pure HTML version displayed) would just have the "foo.com?help" displayed. It looks like the best of both world to me.
I have to agree that Android is very very slow. iOS is much more snappy in this regard. But if WP7 is really as optimized as you say it is, I might take a look someday. Not today though. My pain from my last Windows 6.5 is still way too fresh in my mind. I know they've redone it all, but I just can't get my mind to getting a Windows Phone. Not yet.
Slashdot Mirror
The best way is to zip all your photos with a password, rename the file to "Britney Spears secret sex tape 1080p DTS.mkv" and put it online on The Pirate Bay.
Probably the best advice of all. If after 6 month you have 1TB of digital data, you're probably doing it wrong. You won't have enough time in the remaining of your life to look at all that data, let alone sort it out to make it half useful.
Otherwise, just use external HDDs. Buy 4. Routine check every year. Two where you backup every week, one every month that you store at your parents and one another at you in laws.
Who said anything was dead?
Certainly not me.
Well... they stopped the project once it was up. Their goal was to demonstrate the Java technology, not to make a web browser as a sustained product.
Yes plugins were Java based of course, but I'm sure that could have worked. But let me tell you, by 200, we (linux & non windows users) were in sore need for a web browser. A Java-based one would have done it ;-)
It all depends how you use AJAX I guess.
I use it to submit forms, so that I avoid the problem of having to refresh a page in which a user has made some input. In this regard, I save time and energy, and the user has a faster response. It's all a win.
I also use it to refresh some components in html pages. No DOM is needed there as it is as easily done by grabbing an HTML fragment from the AJAX request and putting wherever you need with the innerHTML attribute. Again, it saves bandwidth and time to code. Another win.
AJAX is a powerful tool that may need some tooling for some. Interpreting a JSON response is a one liner for example. No kludge in there. Manipulating the DOM is something very powerful too, but again it may need some tooling for some.
All in all, yes, browsers were once made to display static content. That was before DOM-based browsers. Things have changed.
Not to mention the original poster wasn't talking about that at all. He finally answered and his grudge is against HTML and JavaScript... ;-)
But there are simple solutions for that problem. The fact that Chrome abuses some TCP feature is a Chrome problem, not an AJAX one. Nothing prevents a browser to set a keep alive in the HTTP headers and let a socket open to the server. This is an existing feature of HTTP, respect perfectly TCP, and was even designed for that very purpose !
I have to say I'm not familiar with that specific subject, but I fail to see a problem there.
But this is just a lack of optimization on the part of the browsers... It'll come in time. But it is not an "atrocity" like the GP was saying...
Ajax conforms to the HTTP protocol pretty much like everything else. It is an http request sent by the browser basically indistinguishable from another regular http request to get an image or an html file. Nothing was done in the HTTP protocol for AJAX. What are you talking about exactly?
You can infer a lot from the "Java is dead" crowd, like they probably don't have a job in IT
Wrong, I do.
, or they don't use UNIX
Wrong, I do.
, like to say things are dead a lot
Uhhh, nope, I don't.
, etc.
Looks like you have a hard time thinking outside the box. You environment is not the environment of everyone working in IT and on unices. Surprise, you are not the center of the world.
You know, the issue here is not the browser. It's the HTTP protocol - it was simply designed for nothing else but static content. The number of kludges and patches you need to implement basic session handling and interactvity is getting ridiculous. Do we even have a RFC for cookies, for example?
The only flaw with HTTP is that it is stateless. It is also its greatest strength.
I'd hardly call cookies 'number of kludges and patches' though. Ah, here is the RFC: http://www.ietf.org/rfc/rfc2109.txt
Back in the days, I was impressed by HotJava. This was a full blown web browser developed in Java. No Javascript. It worked well and, as expected, ran Java Applets natively.
I still don't know why they dropped the development...
I have to say I am actually surprised to see how many people still have a Java plugin for their browsers. I had a look at the analytics of my website and it looks like more than 80% of my visitors have one.
I heavily use Java on the desktop (Eclipse, etc) and on my servers (Tomcat) but I thought Java Applets to be dead for long.
What would the guy who authored and pioneered the scientific method know about God?
There. Fixed that for ya. Doesn't seem as smart as you thought now, he?
the written word isn't as black and white as folks wish it were.
That is only if you use colored paper or colored ink ;-)
You gotta start somewhere. The best way to start is at the source: The school system. How do you get to improve the school system with such uneducated politicians is the problem. But you can't focus on educating politicians. By the time you'll reach through their thick skulls, they'll be out of office and you have to start again with the newcomers.
Hmmm. I see. Next time, I'll try to read all the words before replying something silly.
I have to say though, being french, that I'm glad that you got the Olympics games instead of Paris. By these debt-crisis times, spending as much as you do (and as much as we would have done) for such a thing is kind of silly.
Note that I'm not saying we are better in this regard. We (as a nation) wanted it, and I'm sure we would have spent as much money as you do if we would have had them. Fortunately, we suck ass at marketing, so there is no way in hell we could have beat you to it.
Good luck.
Perhaps not in the days of nested tables, but CSS has grown up since then, and absolutely can be used to do page layout.
I'm really sorry, I know this will not come out well, but the only possible explanation I can see is that you've never used CSS. At least never used to do page layout.
Page layout is controlled by HTML and CSS. CSS can hide, show, left or right float something, but that is about it. And that's already great. Let's take a simple example: I have a layout with three columns: The left menu, the right menu and the content in the middle. On small screens (say, <800px), I want both my menus to be on the left, on top of each other, because there's little room for the content otherwise. How can I do that with CSS?
Short answer: I can't.
Long answer: I *could* by absolutely positioning my elements. But to position absolutely something just below something else, you have to know the size of the first element. So either it's static content and you know it, or you have to use JavaScript. That doesn't play well with content that comes from a database for example.
That's basic page layout. CSS is completely unable to do it all by itself. Layout in HTML is done by HTML AND CSS, because of the simple fact that the flow of elements in the page is defined by the order in which they appear in an HTML document, and CSS can do nothing about it.
So no, I am sorry, but while CSS can help a great deal for page layout, it cannot do everything. And if you want to change the layout on a media query, you're often left alone and have to resort to a few javascript on-the-fly modifications to the DOM to help you out. Unfortunately, there is no way to trigger a javascript on an activation/deactivation of a media query, so it means more hacks and tricks. That sucks, much like user-agent sniffing. But that's life.
Are you implying that 500,000 is a million?
I must have a problem expressing myself, for you are accusing me of not liking standards when I do know they are what makes the web today manageable. And I respect and love them.
Well, all major "things" in the internet, those who make it working and useful, have been brought to us with that "theoretical, academical process" you dislike. It's your right, of course.
Please cite me ONE of my sentences that can be construed to mean that I dislike that process. I bet you can't. I do like and respect that process. However I do believe that people should be allowed to use the implementations as they see fit. I don't believe everyone should be restrained from using anything that hasn't been published in a final state.
What you are pushing forward is known as "act soon, fix later" because "there's no time" or because "we need it yesterday". This is what I personally dislike a lot.
That's absolutely not what I am pushing forward. If something works in ALL browsers and is a part of a draft standard and is widely used, I think it's a safe bet that it won't disappear from browsers overnight. It's also a safe bet that it won't disappear from the standard. So I think it's a safe bet that you won't have to fix it later. As a result, I think it would be silly to not use said features, just because "but the standard is in a draft state".
You say all browsers support the "interim HTML5".
Have you tried this site with ALL your browsers? Also the mobile ones?
Each of them only partially supports one of the intermediate drafts. Which is a two level uncertainty. And what about this one?
You surely know about the "cross browser" issues with Javascript. It started with two different implementations of a non-standardized scripting language. There are still hundreds of lines of code being run in almost all web pages just to cope with it.
And if you think about the big mess all the current browsers are doing with the mature HTML4 and CSS2, you can imagine how messy the scenario will be with HTML5. Web sites will still need to support all those dialects and variants of the HTML5, if they want to show the intended way.
No, all browsers don't support everything, this is true. However there is a sizeable subset of HTML5 and CSS3 that is supported by all latest versions of all browsers. I find it silly to advise people not to use that subset. So I do and I advise people to use it.
Look, a stupid bug is not being fixed in any open source browser. It's about a core HTML4 element which has forced hundreds of HTML publishers to look for partial workarounds.
Sure, but the world is not all black and white. I'm advocating a particular shade of gray, that is all. Of course, don't use something that is broken in most browsers. And no, there will never be a time when all bugs will be fixed and all implementations will be alike. Hopefully, that will never happen. So we'll always have to cope with cross-browser compatibility issues. This is the reality of life. You may live in a w3c smelling ivory tower of cross-browser compatibility heaven, but I do build websites in the meantime. So I cope with it.
So, in my humble opinion, standards matter. And also a lot.
In mine too.
The Xoom has a dual core processor. I have an iPhone 3GS which is a piece of crap compared to that and my UI feels as snappy as the Xoom's (I know, I have a few friends with a Xoom) Every piece of Android I've seen on comparable hardware as the 3GS is laggy and feels just horribly slow.
It might be me though.
People navigating with JavaScript turned off will be glad to see something. Plus, you AJAX-based mechanisms might work well with Chrome, Safari and IE8+, and you might not want to get to the trouble to troubleshoot your UI on older IEs. GMail has a basic html interface. Do you think they did it so that they would "guess" what the user want? No, they know people want their mail. But there is a limit to how much time you want to throw in to support 3% of your audience.
Plus, an HTML-only version is perfect for crawlers.
As I said, it looks like the best of both worlds to me.
Thanks for the link, very informative. I fail to see the rael-world application though.
I mean, if you go to the trouble of writing every "page" as an HTML fragment, why not go to the last mile and provide a pure HTML version of your site?
Let's say your site is called "foo.com". The help section would be "foo.com?help", then you render your links as being:
<a href="?help" onclick="loadPage('#help')">
The loadPage method would just call the data for "help" and modify the url to be foo.com#help. If javascript is inactive (Google, specific browsers that you'd rather have the pure HTML version displayed) would just have the "foo.com?help" displayed. It looks like the best of both world to me.
Am I missing something?
I have to agree that Android is very very slow. iOS is much more snappy in this regard. But if WP7 is really as optimized as you say it is, I might take a look someday. Not today though. My pain from my last Windows 6.5 is still way too fresh in my mind. I know they've redone it all, but I just can't get my mind to getting a Windows Phone. Not yet.