I thought there was supposed to be a law that would curb such practices i.e.:
1. Get a patent for something
2. Hide into a hole
3. Wait years for some other company to implement something related
4. Sue
5. ? (obligatory South Park refernce)
6. Profit!
Not sure if the law passed but there was some talk about it. The law was supposed to deter 2 and 3. SGI's claim for the patent is probably valid (unlike SCO's claims) but if they are so offended and can claim so much loss they should have sued right way when they found out about ATI's announcement. The fact that they waited means that they are becoming the new SCO -- a patent monkey. It seems that all S?? companies eventually end up sucking!
If he is found guilty we should all petition the judge to us hook him with a laptop in prison and let him continue working on his project. Murderer or not his filesystem works great, one could argue that it would hurt technology worldwide (I'm exaggerating here of course) if he could not continue developing his fs.
If he is guilty then let Bubba pound his ass every day in prison, but in between the "poundings" he can develop software.
Excerpt from hypothetical email from prison:
Sorry guys, gotta cut this message short, Bubba is back for more. For the holidays, please send more vaseline, and we need to do more testing on the new module, ok gotta go!
In fact, according to the current theory you would _have_ to be destroyed. It is impossible to make a copy of an entaglement without distroying the original. Now we are not even talking about transporting objects here, just information, so this is most relevent to quantum computing. The fact that copies cannot be made means that in the hypotheical QC circuit you cannot have a Y-split.
On a serious note sorry, didn't mean to mislead, what I meant to say is "the right tool for the right job".
Some sites (web applications) will benefit from Ajax, example: Google, Yahoo and other large portals are prime examples, but Ajax isn't the answer to everything like many of today's books and Ajax fanboys suggest. There is a place for rich clients -- with new Java native GUI l&f there is no need to have apps that look alien, they can look just like Windows or Gnome apps. I could see myself opening a custom Webstart Application to access my bank records or my email just as I can see doing it in a browser. Design and functionality -wise I think Java is a cleaner solution today (I know it wasn't the case a couple of years ago). Ajax has to jump through many hoops just to catch up with a basic UI capabilities that, like you said, have been there on the desktop since Windows 1.1.
As far as requirements go you say that Java applets require more stuff on your customer's side. But I say that all the customer needs is Java and a web-browser. Granted, JRE is not a small install, but in order to have Ajax, the developer has a hell of a time finding workarounds for various browsers that never quite seem to implement completely all the standards W3C standards.
And why shouldn't Mr. Sixpack get easier navigation, sazzier transitions, pre-loading of slideshow images and so on for his fishing trip pictures? -- Because Web and HTML was never intended to have sazzy transitions, flashing buttons and so on. Added flashiness != always equal better usability. For each site out there that has successfully used Ajax there is another site that made the user experience worse by slowing it down, or having it not work at all anymore on some browser just because they forgot to include an extra if(browser==Opera){...} among the code for many Ajax browser workarounds.
The right tool for the right job. Some sites will benefit from Ajax, some can just stay static, some will be better off as a Java Webstart application and many will just be somewhere in between.
I love Python, I wish JavaScript would be Python (i.e. a browser would come with an embedded Python interpreter and a library to communicate with the server). Then Python could also be used on the server...
For interface, I'd like full SVG 2.0 supported in all the browsers and standardized (i.e. no need for Flash) and for a way for my imaginary browser-embedded Python to manipulate the SVG interface in an easy, clean and Pythonic way...
An application developer may be able to deliver 100% of wanted functionality, but in a way that a user finds aesthetically displeasing.
Digressing to another topic, that comment reminded me about the Gnome/MacOSX vs. KDE/Windows approach to user Desktops. According to the experts in HCI (Human Computer Interraction) field, Mac OS X is more "user friendly" than Windows. Apple has invested a lot more in usability research and it payed off, the interface is easier to learn, it is simpler and more intuitive. I think they managed to deliver 100% desired functionality in a way that users find very appealing. Microsoft on the other side, did a crappy job on the UI and they trained hordes of users around the world (most computer users) to accept it as a default standard.
Enter Linux, the two competing GUIs - Gnome and KDE have addopted different philosophies. Gnome wanted to follow HCI guidlines, their interface is simpler, and I think, more user friendly. I don't think they blindly copied Mac OS X, it is just that both Apple and Gnome creators looked at what a good GUI should be like accoring to previous research in HCI.
KDE on other hand, addopted Windows' kind of UI as their "ideal" model. In other words, anyone who used Windows should find KDE more appealing (I did too at first). But in reality the layout, the ammount of preferences, the number of options visible to the user can also be confusing when compared to Gnome's and Mac OS X's simplicity.
So what is the point of all this? It is that sometimes users don't know what they "need" or "want". Now, I know, that sounds silly to say, but I have become convinced of it over the years. Many users will say that they want such and such a feature but they don't really need it (i.e. they shouldn't have it). So this means that the boss may say he wants Ajax because Google has it, and the job of a smart developer is to explain what Ajax really is and that sometimes it would be a waste of time and resources to jump on the Ajax bandwaggon without getting himself fired. Same went for me and Gnome. I hated it, at first but over time I got frustrated with KDE's large ammount of options and preferences. I couldn't find a specific option I wanted when I had to, so I started to use Gnome more and more and eventually un-installed KDE completely because I was simply more productive with Gnome.
Note that "knowing JavaScript" 5 years ago meant "I know how to write an even handler for onmouseclick to make the text blink".
Today, with Ajax in mind, "knowing JavaScript" means "I know and understand async. I/O & DOM, I know about XMLHttpRequest and I could re-implement Google Maps for you if you ask me".
All of the sudden JavaScript went from being used as a toy scripting language to a full-blown develpment language. Not saying if it is a good thing or bad thing but you can thank Google for it...
Interesting that you mentioned that. The other day I was in a bookstore and was looking through the computer books section. There are a ton of Ajax books out there. It seems like out of nowhere we have all these Ajax experts writing books about Ajax. I picked up a couple of them and as I was reading I kept thinking that "I could do that with Java applets" or "Java + WebStart can do that".
Yes, I know Java is not cool anymore because Google uses Ajax, and I acknowledge that when Java was being hyped as the "the new cool thing" 5-10 years ago, it was not up to par: limited and ugly graphics and UI, slow initialization, etc etc.
But a lot of those things have been polished in the recent Java 1.5 and will get even better in Java 1.6. UI got speedier, many bugs have been fixed, gc has been improved and most of all the performance in general is faster. At the same time, computers were much slower back then. Now it would be safe to say that just the average raw machine performance has more than doubled, soon we will be seeing multple cores on home desktop machines. So could this be another chance for Java rich clients in form of applets or Java WebStart applications?
One of the biggest benefit of Java is that the developer can stay in the same environment, on the front end and the backend. No need to know JavaScript, HTML, DOM, XML, and whatever the backend uses. Just use one language. This, to me at least, leads to 3 other benefits:
1) More consistency: a lot of Ajax code right of the bat deals just with different browser version and JavaScript versions, that's too many "if"s and "else"s to make it fun. With Java the developer has a clean slate work with, less workarounds means cleaner, more maintainable code.
2) Can use any communication mechanism between client and server, no need to stick to XMLHttpRequest 3) Easier to find developers. On the job application just put down one requirement - "Java". Instead, Ajax means "JavaScript"+DOM+XML+backend language(SQL,C++,Java etc)....
Yes, yes, I know, I don't really see Google or Yahoo re-developing their portals as Java applets or even worse Java Web Start standalone applications. But how many large web portals are out there? On the other hand, I can see applets used more often in specialized sites, industry-specific sites.
And let's face it, most sites can just remain static. Mr. Sixpack doesn't need DOM, JavaScript and XMLHttpRequest to display his fishing trip pictures online...
That's the first thing I thought of. When I was kid I used to have these large capacitors and once in while I had the fun habit of charging them up and discharging them with 'bang'. (Yes, I didn't get out much...) But anyway the "100lbs of TNT" that you speak of will still be right there, behind the driver's back, available to be discharged with a very loud bang.
But I think if they install fuses right into their capacitor or connect it to a sensor such that when the car flips over/has a major accident/falls into the water/gets attacked my monkeys the capacitor switches itself off (some internal fuse is shorted) it might not be too bad.
There is nothing wrong about relying puzzles if the company wants people to solve sudoku, play chess, or quickly find square roots of numbers in their head every day and don't really care about interpersonal skills, maturity, communication and other qualities. In other words the company will just get what it wants (even though it might not need what it wants!).
The question is therefore why would you want to work for that company, when you might end up working with a bunch of antisocial monkeys that can only quickly solve small puzzles in their head and that's about it? You are interviewing the company as much as they interview you, so if they just say here solve the 'crossword' and you are hired without looking at your references, GPA, other work or even talking to you, it would probably be a good time to politely thank them for the opportunity and move on to the next interview...
In general the white balance will calibrate your camera for the "0" -- the white point (I am making an analogy with traditional data acquisition equipment) but the problem with some digital cameras is that their color dynamic range (the gamut) is much smaller than that of color film. Therefore with film you might see more shades of, say, blue than you could with digital. Going back to the data acquisition world: you can have to 0-calibrated devices but one will be 8 bits while the other will be 16 bit. The second one will discern more values than the first (65536 vs. 256).
Again I am assuming that the lenses are the same and that one would use a good color film (say Velvia ) and a good digital sensor (say Sony's 10MP CCD sensor).
Sometimes it also depends on the web server. It also needs to advertise the MIME type of the file it sends. On Ubuntu, make sure to install Sun's Java that should associate.jnlp with the javaws executable.
1. In general the 10MP=approx=35mm film might be true for B&W photos. For color the MP count would have to be larger, somewhere around 15 or 16.
2. Also with film it is possible to get ISO 50 film (Velvia for ex.) to match its resolution and color range it will take even more MPs.
3. When talking resolution MP are not the whole story, the sensor size is just as important. A small sensor with a lot of MPs is bad news since the images will be very noisy. People don't usually take this into consideration and only look at MPs. A lot of super-zoom and consumer models now have managed to fit a 10MP in their body but the images are nevertheless much worse than the same MP count images from a DSLR with a larger sensor.
Firefox support is half-way there. I was able to create a small website in SVG with Inkscape. It worked alright in the latest Firefox...
Yeah SVG+Ajax would be a dream come true if SVG is supported _in_a_standard_ way in all the major browsers. Making users download plug-ins is a good way to not have very many users.
I wish SVG would take off at once. But the browser support is still lacking. I tried creating a small website in SVG using Inkscape only, it worked pretty well with Firefox but IE needed a plugin. But even Firefox still doesn't support the full 1.1 specification...
Java's WebStart solves this exact problem. We are not talking about Applets. These are more like full Java applications that the user can launch just by clicking on a link in the browser. The applications then load along with any necessary libraries and are cached on the users' computer. Optionally the user can even include it in the Start/Gnome/KDE menu.
I wrote a quantum computing 3D visualization program in Java3D. The user can just click on the link in the browser and Java3D native libraries will be automatically downloaded and installed on the users' machine (of course after asking the user for permissions to do it) after that my application can use the native OpenGL drivers for fast 3D graphics. So it is both an Internet application (although it presently doesn't talk to a server in real time but it would also be possible) and it takes advantage of the fast native OpenGL graphics and the rich Swing GUI.
The frontend is HTML+DOM+JavaScript. Unless you know of any good database access driver from HTML or JavaScript, or know any browsers with an embeded Python/Ruby interpreter you won't have _full_ unification of the front and backend. The closest to _full_ unification that I can think of is using Java applications where both the applet/WebStart application and the backend both run Java.
Java for Visualization
God help us all. I went there once on a trip... lost my granny, my dog got run over, and I came back with only 8 fingers.
That's what happens when you are not prepared for travel!
How good are you Java programming skills? What were your expectations? Have you tried WebStart?
I think Java still has a place for specialized rich clients. I have recently released a Java3D scientific visualization application that uses WebStart. It automatically downloads all the Java3D libraries it needs and caches them on the user's machine, then it is able to use native OpenGL drivers. All the user has to do is to click on the JNLP link in the browser. The application works on Windows, Linux and Mac with with all the popular browsers. I am not saying it was trivial to write it but it can be done, one just needs to know Java at more than the beginner level. Flash/JavaScript/SVG would not have worked for what I needed to do.
Will we see major web portals using Java applications as their interface? - Probably not. But that doesn't mean Java is dead and Ajax is a panacea for all the Internet problems.
HTML was designed as a document language, for the static display of information. It was never designed for any sort of interactivity other than hyperlinking.
SVG is designed to fix that. It is an open standard, it looks promising but unfortunately browser support isn't quite there yet...
But we wouldn't know...As soon as one dies he gets shredded and a replacement takes his place. Thousands of IT workers die everyday and most people don't even know it.
DC will kill you much quicker than AC of the same voltage/amperage..
I always thought the opposite was true. Here is a wiki quote that also supports that:
Low frequency (50 - 60 Hz) AC currents can be more dangerous than similar levels of DC current since the alternating fluctuations can cause the heart to lose coordination, inducing ventricular fibrillation,...
Slashdot Mirror
That is why professionals never use internal sound cards for A/D (yes, Creative is considered crap). For a more serious option check out this baby from Roland : ahref=http://www.rolandus.com/products/productdeta ils.aspx?ObjectId=758&ParentId=114rel=url2html-241 56http://www.rolandus.com/products/productdetails. aspx?ObjectId=758&ParentId=114>
I thought there was supposed to be a law that would curb such practices i.e.: 1. Get a patent for something 2. Hide into a hole 3. Wait years for some other company to implement something related 4. Sue 5. ? (obligatory South Park refernce) 6. Profit! Not sure if the law passed but there was some talk about it. The law was supposed to deter 2 and 3. SGI's claim for the patent is probably valid (unlike SCO's claims) but if they are so offended and can claim so much loss they should have sued right way when they found out about ATI's announcement. The fact that they waited means that they are becoming the new SCO -- a patent monkey. It seems that all S?? companies eventually end up sucking!
Scout Leader : "Well Billy, you were pretty good about not pirating but we do need to talk about you accessing the 'MILF hunter' website."
So next time they call start smiling and in a soft polite voice say "FUCK YOU" and hang up.
If he is guilty then let Bubba pound his ass every day in prison, but in between the "poundings" he can develop software.
Excerpt from hypothetical email from prison:
Sorry guys, gotta cut this message short, Bubba is back for more. For the holidays, please send more vaseline, and we need to do more testing on the new module, ok gotta go!
Thank you, I've heard that before ;)
On a serious note sorry, didn't mean to mislead, what I meant to say is "the right tool for the right job".
Some sites (web applications) will benefit from Ajax, example: Google, Yahoo and other large portals are prime examples, but Ajax isn't the answer to everything like many of today's books and Ajax fanboys suggest. There is a place for rich clients -- with new Java native GUI l&f there is no need to have apps that look alien, they can look just like Windows or Gnome apps. I could see myself opening a custom Webstart Application to access my bank records or my email just as I can see doing it in a browser. Design and functionality -wise I think Java is a cleaner solution today (I know it wasn't the case a couple of years ago). Ajax has to jump through many hoops just to catch up with a basic UI capabilities that, like you said, have been there on the desktop since Windows 1.1.
As far as requirements go you say that Java applets require more stuff on your customer's side. But I say that all the customer needs is Java and a web-browser. Granted, JRE is not a small install, but in order to have Ajax, the developer has a hell of a time finding workarounds for various browsers that never quite seem to implement completely all the standards W3C standards.
And why shouldn't Mr. Sixpack get easier navigation, sazzier transitions, pre-loading of slideshow images and so on for his fishing trip pictures? -- Because Web and HTML was never intended to have sazzy transitions, flashing buttons and so on. Added flashiness != always equal better usability. For each site out there that has successfully used Ajax there is another site that made the user experience worse by slowing it down, or having it not work at all anymore on some browser just because they forgot to include an extra if(browser==Opera){...} among the code for many Ajax browser workarounds.
The right tool for the right job. Some sites will benefit from Ajax, some can just stay static, some will be better off as a Java Webstart application and many will just be somewhere in between.
For interface, I'd like full SVG 2.0 supported in all the browsers and standardized (i.e. no need for Flash) and for a way for my imaginary browser-embedded Python to manipulate the SVG interface in an easy, clean and Pythonic way...
Ahh, it's nice to dream..
Digressing to another topic, that comment reminded me about the Gnome/MacOSX vs. KDE/Windows approach to user Desktops. According to the experts in HCI (Human Computer Interraction) field, Mac OS X is more "user friendly" than Windows. Apple has invested a lot more in usability research and it payed off, the interface is easier to learn, it is simpler and more intuitive. I think they managed to deliver 100% desired functionality in a way that users find very appealing. Microsoft on the other side, did a crappy job on the UI and they trained hordes of users around the world (most computer users) to accept it as a default standard.
Enter Linux, the two competing GUIs - Gnome and KDE have addopted different philosophies. Gnome wanted to follow HCI guidlines, their interface is simpler, and I think, more user friendly. I don't think they blindly copied Mac OS X, it is just that both Apple and Gnome creators looked at what a good GUI should be like accoring to previous research in HCI.
KDE on other hand, addopted Windows' kind of UI as their "ideal" model. In other words, anyone who used Windows should find KDE more appealing (I did too at first). But in reality the layout, the ammount of preferences, the number of options visible to the user can also be confusing when compared to Gnome's and Mac OS X's simplicity.
So what is the point of all this? It is that sometimes users don't know what they "need" or "want". Now, I know, that sounds silly to say, but I have become convinced of it over the years. Many users will say that they want such and such a feature but they don't really need it (i.e. they shouldn't have it). So this means that the boss may say he wants Ajax because Google has it, and the job of a smart developer is to explain what Ajax really is and that sometimes it would be a waste of time and resources to jump on the Ajax bandwaggon without getting himself fired. Same went for me and Gnome. I hated it, at first but over time I got frustrated with KDE's large ammount of options and preferences. I couldn't find a specific option I wanted when I had to, so I started to use Gnome more and more and eventually un-installed KDE completely because I was simply more productive with Gnome.
Today, with Ajax in mind, "knowing JavaScript" means "I know and understand async. I/O & DOM, I know about XMLHttpRequest and I could re-implement Google Maps for you if you ask me".
All of the sudden JavaScript went from being used as a toy scripting language to a full-blown develpment language. Not saying if it is a good thing or bad thing but you can thank Google for it...
Yes, I know Java is not cool anymore because Google uses Ajax, and I acknowledge that when Java was being hyped as the "the new cool thing" 5-10 years ago, it was not up to par: limited and ugly graphics and UI, slow initialization, etc etc.
But a lot of those things have been polished in the recent Java 1.5 and will get even better in Java 1.6. UI got speedier, many bugs have been fixed, gc has been improved and most of all the performance in general is faster. At the same time, computers were much slower back then. Now it would be safe to say that just the average raw machine performance has more than doubled, soon we will be seeing multple cores on home desktop machines. So could this be another chance for Java rich clients in form of applets or Java WebStart applications?
One of the biggest benefit of Java is that the developer can stay in the same environment, on the front end and the backend. No need to know JavaScript, HTML, DOM, XML, and whatever the backend uses. Just use one language. This, to me at least, leads to 3 other benefits:
1) More consistency: a lot of Ajax code right of the bat deals just with different browser version and JavaScript versions, that's too many "if"s and "else"s to make it fun. With Java the developer has a clean slate work with, less workarounds means cleaner, more maintainable code.
2) Can use any communication mechanism between client and server, no need to stick to XMLHttpRequest
3) Easier to find developers. On the job application just put down one requirement - "Java". Instead, Ajax means "JavaScript"+DOM+XML+backend language(SQL,C++,Java etc)....
Yes, yes, I know, I don't really see Google or Yahoo re-developing their portals as Java applets or even worse Java Web Start standalone applications. But how many large web portals are out there? On the other hand, I can see applets used more often in specialized sites, industry-specific sites.
And let's face it, most sites can just remain static. Mr. Sixpack doesn't need DOM, JavaScript and XMLHttpRequest to display his fishing trip pictures online...
But I think if they install fuses right into their capacitor or connect it to a sensor such that when the car flips over/has a major accident/falls into the water/gets attacked my monkeys the capacitor switches itself off (some internal fuse is shorted) it might not be too bad.
The question is therefore why would you want to work for that company, when you might end up working with a bunch of antisocial monkeys that can only quickly solve small puzzles in their head and that's about it? You are interviewing the company as much as they interview you, so if they just say here solve the 'crossword' and you are hired without looking at your references, GPA, other work or even talking to you, it would probably be a good time to politely thank them for the opportunity and move on to the next interview...
In general the white balance will calibrate your camera for the "0" -- the white point (I am making an analogy with traditional data acquisition equipment) but the problem with some digital cameras is that their color dynamic range (the gamut) is much smaller than that of color film. Therefore with film you might see more shades of, say, blue than you could with digital. Going back to the data acquisition world: you can have to 0-calibrated devices but one will be 8 bits while the other will be 16 bit. The second one will discern more values than the first (65536 vs. 256).
Again I am assuming that the lenses are the same and that one would use a good color film (say Velvia ) and a good digital sensor (say Sony's 10MP CCD sensor).
Sometimes it also depends on the web server. It also needs to advertise the MIME type of the file it sends. On Ubuntu, make sure to install Sun's Java that should associate .jnlp with the javaws executable.
2. Also with film it is possible to get ISO 50 film (Velvia for ex.) to match its resolution and color range it will take even more MPs.
3. When talking resolution MP are not the whole story, the sensor size is just as important. A small sensor with a lot of MPs is bad news since the images will be very noisy. People don't usually take this into consideration and only look at MPs. A lot of super-zoom and consumer models now have managed to fit a 10MP in their body but the images are nevertheless much worse than the same MP count images from a DSLR with a larger sensor.
I am assuming the lens is not a limiting factor.
Google webstart and JNLP
Yeah SVG+Ajax would be a dream come true if SVG is supported _in_a_standard_ way in all the major browsers. Making users download plug-ins is a good way to not have very many users.
I wish SVG would take off at once. But the browser support is still lacking. I tried creating a small website in SVG using Inkscape only, it worked pretty well with Firefox but IE needed a plugin. But even Firefox still doesn't support the full 1.1 specification...
I wrote a quantum computing 3D visualization program in Java3D. The user can just click on the link in the browser and Java3D native libraries will be automatically downloaded and installed on the users' machine (of course after asking the user for permissions to do it) after that my application can use the native OpenGL drivers for fast 3D graphics. So it is both an Internet application (although it presently doesn't talk to a server in real time but it would also be possible) and it takes advantage of the fast native OpenGL graphics and the rich Swing GUI.
The frontend is HTML+DOM+JavaScript. Unless you know of any good database access driver from HTML or JavaScript, or know any browsers with an embeded Python/Ruby interpreter you won't have _full_ unification of the front and backend. The closest to _full_ unification that I can think of is using Java applications where both the applet/WebStart application and the backend both run Java.
God help us all. I went there once on a trip... lost my granny, my dog got run over, and I came back with only 8 fingers.
That's what happens when you are not prepared for travel!
How good are you Java programming skills? What were your expectations? Have you tried WebStart?
I think Java still has a place for specialized rich clients. I have recently released a Java3D scientific visualization application that uses WebStart. It automatically downloads all the Java3D libraries it needs and caches them on the user's machine, then it is able to use native OpenGL drivers. All the user has to do is to click on the JNLP link in the browser. The application works on Windows, Linux and Mac with with all the popular browsers. I am not saying it was trivial to write it but it can be done, one just needs to know Java at more than the beginner level. Flash/JavaScript/SVG would not have worked for what I needed to do.
Will we see major web portals using Java applications as their interface? - Probably not. But that doesn't mean Java is dead and Ajax is a panacea for all the Internet problems.
SVG is designed to fix that. It is an open standard, it looks promising but unfortunately browser support isn't quite there yet...
But we wouldn't know...As soon as one dies he gets shredded and a replacement takes his place. Thousands of IT workers die everyday and most people don't even know it.
I always thought the opposite was true. Here is a wiki quote that also supports that:
Taken from http://en.wikipedia.org/wiki/War_of_Currents/