We'll have to see if Apple has learned anything. I first heard about FireWire in maybe 1993. I went to work at Apple in 1995 and met with the people developing FireWire and there was lots of talk about having devices natively support it, yada yada. It didn't make it into shipping Apple hardware until 1999. Besides being late to market, Apple insisted on charging licensing fees to everyone who incorporated FireWire.
Had FireWire been out in 1996, they might have been able to get away with the licensing fees. Had they forgone the licensing fees in 1999 they might have kept USB a low-speed interconnect.
In order to succeed in today's market it will need to offer technical advantages over USB 3.0 and not come with a price premium. Having Intel introduce is a pretty strong first step. We'll have to see how the rest of it plays out.
Trading the search for the warning at least got you something. I do hate the whole "if you've got nothing to hide why don't you let me search" garbage. The right answer to that is - "There's nothing to find so you don't need to search the car" Your time is valuable and your privacy is valuable. That's why we require the police to justify searches.
Oh yeah, because all of those cars from the sixties and early seventies got such great gas mileage before they had to add the emissions control equipment. And the cars were so much lighter then too without seatbelts and air bags.
A meme that has been going around is that the size of the disk relative to the hard error rate is getting to the point where reading the entire disk once or twice guarantees getting a hard error. My experience with disks, though, is that they do not "wear out" by how many blocks you read from them. They do tend to wear out with age, vibration, heat, start/stop, etc. Is the hard error rate really based on number of bits read (and, it's also not a guarantee you will get a hard error - it's the minimum) or is it an estimate based on expected usage vs age? Or is it not related to the media at all but instead a measure of how many bits you can transfer over the link without an error?
This meme is really getting silly. Long rebuild times are a problem but we're still talking about days for devices that have typical life spans of years.
There's a difference between telling your boss "your password" and giving the master passwords to your boss.
He didn't have to say the password in front of the other people in the room. He could have written it on a piece of paper, demanded a receipt for it, and demanded that his boss change the password to something he (Childs) didn't know so that he couldn't be accused of breaking things afterwards.
Childs was being a dick. I don't think he was being a year's worth of jail time dick, but I would have canned him. If this was not government that's where it would have stopped. Unfortunately someone has the ear of the DA (Kamala Harris, who is an idiot) and managed to convince her of this terrible danger and it went public and now the bureaucrats can't back down without losing face.
Childs is going to wind up a rich man at the end of this and the taxpayers of SF will wind up footing the bill for the City's IT management's and DA Harris' incompetence.
What's ridiculous is not seeing a difference between software and hardware. The FSF is the Free Software Foundation for a reason.
What's the difference? Free as in beer doesn't work so well for hardware but the whole point of the FSF is to give you the ability to modify your computer to meet your needs.
Hardware can be "free as in speech" and older hardware tended to be, at least as far as the interface definition went. Modern hardware is orders of magnitude more complex than early 90's hardware and the documentation for hardware interfaces has largely gone the way of the dodo - partly for competitive reasons but also partly because the cost of producing that documentation is high and the number of consumers for it is small.
Open source drivers show how the hardware is interfaced with and are very useful to the subset of people who like to tinker with their hardware.
False comparison. As I said, 99% of the time the one in the toolkit is the right one to use. However, when you are using the wrong sort algorithm you will know it and your users will as well because the performance will be extremely bad or the app will run out of memory or some such.
It's a solved problem for data sets that completely fit in memory and fit the assumptions of the toolkit's library.
99% of the time the toolkit's sort function is the right one to use. Knowing how that sort is implemented, what you are trying to sort and the characteristics of different algorithms is what lets you know when you're in that other 1% of the time where you need to start writing your own sort routine.
I totally agree with this. I own a small business (California C corp) and I was behind on filing some forms. When I started looking at the penalties they can levy on the business it is really a joke. As long as I, as the CEO, don't engage in any criminal behavior there are very few real penalties.
This now adds a ridiculously complicated system that will have legal penalties if you "tamper" with it. What happens if you add a part to your car shields the GPS antenna and it can't get a fix anymore? If you bust the electrical system and the tax tracker no longer gets powered.
We don't need any mandated, you can't touch this, systems in our lives.
The report is wrong anyhow. This is no longer a tax. This is now a fee. The government should not be in the business of collecting fees for usage.
And as I said the situations are not at all parallel. When GNU was started (and I remember because I was very interested in Unix at that time) there was no worry that AT&T would be able to kill it, except if there were copyright infringements.
Computer software was not even copyrightable until 1980. Prior to that, if you got a copy, you would be able to copy it. The Unix source code was protected by "trade secret" before then. GNU got started in about 1983.
The whole regime of patents, copyrights and other "intellectual property" did not really apply to the software world at that time and there was not nearly the level of paranoia about them.
Hmmm...that was a very interesting and disingenuous comparison that he made.
AT&T had a monopoly in telecommunications, not in computers. AT&T did not have a long history of embrace, extend, extinguish as Microsoft has. AT&T did not have a history (successful, at least) of using its monopoly to create new monopolies in other areas unlike Microsoft (for example, Microsoft leveraging their OS monopoly into a office suite monopoly).
At the time that GNU was started, software was not patentable. Cloning a copyrighted system only opens you to legal problem if you actually copy the code. Cloning a system with patents will leave not just the cloner but also any users open to patent infringement lawsuits.
The two situation are not as parallel as the glib comment would make it.
So, your arguments are fine and logical but let's be practical.
I like to watch movies. Movies are very expensive to produce. Paying the producer of the movie to watch it is one way to pay for the production of movies. You're arguing that this business model is fundamentally broken. Do you have an alternative?
Well, I used to work for a supercomputer manufacturer many years ago. I'm more of an OS/C weenie than a Fortran weenie but I did get dragged into the Fortran side of things on occasion. We put a lot of effort into the Fortran compiler, especially the vectorizing Fortran compiler because many of the customers were physics/math types and they had lots of Fortran code that needed to run faster (we used to call it "dusty deck" code, implying that it had come from a deck of punchcards). So, part of it is just circular - Fortran runs fast on math because people use it for math problems.
Vectorizing Fortran was significantly easier than vectorizing C/C++ because Fortran lacked pointers (apparently they've been added since then), it had real arrays (C arrays are really just pointers with syntactic sugar) and real math functions. I think Fortran FOR loops are more regular as well which makes extracting the vector operations easier. You can do some truly grody stuff in C. For example, this is valid C:
#include <stdio.h>
int main(int argc, char ** argv) {
doit(1);
doit(2); }
int doit(int y) {
int x = 0;
switch(y)
{
for (; x < 20; x++)
{
if (x < 1)
{
case 1:
printf("y = 1, setting x = 1\n");
x = 1;
continue;
case 2:
printf("y = 2, setting x = 10\n");
x = 10;
continue;
}
printf ("x = %d\n", x);
}
} }
Don't ask me why someone would want to code it this way but you can (I've seen it done) and it makes the parser that checks for vector conditions harder (breaks reverse engineering tools too). Even with a simple for loop in C, it's possible to initialize and increment the counter in all kinds of different places. I think Fortran has less flexibility.
Also, C math handling at the time was not really up to snuff. Things like numeric exceptions were not well handled. This extended even to the OS level at times. I recall having to fix the floating point exception handling in Solaris when we ported it to our hardware (we had a SPARC based supercomputer).
I don't know where things stand today. When I saw the article title suggesting the high performance code be written in Python I cringed but I'm not really sure of the state of the art of Python. Python has never struck me as a "fast" language, though.
I think the answer for the Mac is "Don't change the font size" - I'm not a Mac UI guru but my app doesn't let you change the font size and a quick look at some other apps didn't show up any preferences for changing the font. Typically when we localize apps we have to resize any controls where the new text is too large or too small for the existing control.
If a panel is resized, the Interface Builder UI has the typical struts and springs style layout control.
I think that there's two types of UI's. There are the ones that just need to be functional and then there are the ones that need to look really polished. It's like when I toss together a web page to show information internally. A table or two here and maybe an ugly color for highlighting. Swing's BorderLayout and GridBagLayout are kind of equivalent. You can't get things exact to the pixel but you can put something together quickly. Then, there's the polished up web pages and UI's where we get the graphic designers involved and there's lots of graphics, etc. and all of the pixels need to fit exactly together. You can code those by hand but something that lets you lay out the controls and graphics *exactly* where you want them can make it a lot easier.
Make a panel, say 100 pixels high. Put a row of buttons along the bottom of it, get them placed how you like. Then, drag in a panel that you want to be 50 pixels high, stretched across the top from the palette.
Oops. The panel is, by default, square and something like 100 pixels high. Oh, heavens, we couldn't have overlapping components, could we? Let's just make some space here so that that panel can fit in. Oh, those buttons were where you wanted them? I'm sure you can tidy them back up later.
Try this - make a new panel. Put a button up close to the right edge but with some space from the right. Now, put another button down below it but try to put it right up against the edge of the container. Oooh, let's move the above button a bit for you.
Those are pretty easy cases to show and I got them to happen using GroupLayout with Netbean 6.7 beta on Windows just now. There are other things it does that don't always reproduce, like if you put a component offset from the component above, sometimes it decides that it should move the component above so that the edges will match. Sometimes, if you put a component too close to the edge of the container it will resize the container. Try to size the container down, oh wait, some component has a big "space on the right" defined. Can't let you resize the container and I won't tell you why.
A drag-and-drop GUI builder should NOT mess with your component placement or sizing. It's too damned hard to get them all nudged into place. Sometimes the movement is not noticed because you're really focused on one part of the screen. Sometimes your finger slips off the mouse button and you put something in the wrong place. You shouldn't have to worry that things are moved around.
Interface Builder on the Mac largely does that right. Where you put a component is where it stays. It shows you guides for where it thinks components should go but you can ignore the guides. It doesn't resize components automatically unless you ask it to.
I agree with you that the problems are not really that difficult. They should have been part of the Java platform 12 years ago. That's what I have difficulty with.
I'm not sure that the holy grail of a cross-platform app is really very useful. Sure, for a small developer having something that also runs on the Mac is kind of nice, but Mac users are picky. If it doesn't look and feel like a Mac app they pan it so you don't gain much. Sun's has infected the Java community with that Write Once Run Everywhere meme but it's really a red herring. What they really want is "Write For Windows but it runs on Solaris too" but they won't say that.
Actually, that's not really fair, as server apps DO run everywhere. The difference is that you have a systems admin (or at least a wannabe) installing those and they can install the JRE/JDK properly and they can get the configuration pulled together.
I think that Sun's all-or-nothing approach to JRE deployment has been a major problem. You had to either give the user the complete JRE or you had to go through some kind of licensing dance with Sun. If they had just gone with a per-seat kind of license and let people imbed Java without any fuss it would be a lot more successful on the desktop in my opinion. I just love the new "install on demand" JRE idea. What bozo came up with that? Yes, my user wants to download an app and then watch things spin when the try to launch it while it download the rest of the junk it needs. Genius at work there. I know when I download something I want to download it and then run it. If it's going to take 15 minutes to download, let me know that up front when I start the download in the browser and I will go get a cup of coffee or something. It's almost as bad as installation processes that pop up a dialog box after an hour of installing asking you some inane question.
Sun really wants to put the Java brand front and center but it just doesn't resonate with anyone besides developers. I think the "Java App Store" will do about as well as the "C App Store" and the "C++ App Store" have done...oh wait, those other two don't exist, do they?
Can Java succeed on the desktop? I think it can but it needs to be easy to write NON-PORTABLE apps in Java - if I want to write something that shines on Windows and doesn't work on the Mac or Linux (or Solaris) it shouldn't be a big deal. Now that Sun has let go of the licensing on Java we may see. I think the language, the JVM, the platform, the variety of libraries available and the tools (except for the GUI builders) make Java a great development platform.
Yah. I haven't actually used Solaris since about 1999 but I was curious if Java worked any better on Solaris than Linux the other day and everything I found in the docs was just what you describe.
Slashdot Mirror
So, if you omit the year do you write it DD/MM, i.e. 11/9?
Yes, and they are welcome to write the date in the format that works best for them.
To make it sound special. July 4th is just another day.
While MM/DD/YYYY seems illogical, it maps exactly to the way you say it - April 1st, 2010 = 04/01/2010
Licensing fees were $0.25/system.
http://www.apple.com/ca/press/1999/05/FireWire.html
Sounds trivial but USB was free.
We'll have to see if Apple has learned anything. I first heard about FireWire in maybe 1993. I went to work at Apple in 1995 and met with the people developing FireWire and there was lots of talk about having devices natively support it, yada yada. It didn't make it into shipping Apple hardware until 1999. Besides being late to market, Apple insisted on charging licensing fees to everyone who incorporated FireWire.
Had FireWire been out in 1996, they might have been able to get away with the licensing fees. Had they forgone the licensing fees in 1999 they might have kept USB a low-speed interconnect.
In order to succeed in today's market it will need to offer technical advantages over USB 3.0 and not come with a price premium. Having Intel introduce is a pretty strong first step. We'll have to see how the rest of it plays out.
Trading the search for the warning at least got you something. I do hate the whole "if you've got nothing to hide why don't you let me search" garbage. The right answer to that is - "There's nothing to find so you don't need to search the car" Your time is valuable and your privacy is valuable. That's why we require the police to justify searches.
Oh yeah, because all of those cars from the sixties and early seventies got such great gas mileage before they had to add the emissions control equipment. And the cars were so much lighter then too without seatbelts and air bags.
A meme that has been going around is that the size of the disk relative to the hard error rate is getting to the point where reading the entire disk once or twice guarantees getting a hard error. My experience with disks, though, is that they do not "wear out" by how many blocks you read from them. They do tend to wear out with age, vibration, heat, start/stop, etc. Is the hard error rate really based on number of bits read (and, it's also not a guarantee you will get a hard error - it's the minimum) or is it an estimate based on expected usage vs age? Or is it not related to the media at all but instead a measure of how many bits you can transfer over the link without an error?
This meme is really getting silly. Long rebuild times are a problem but we're still talking about days for devices that have typical life spans of years.
If you read through the patent, it's basically the same as a mailing list that sends out digests. Trivial.
There's a difference between telling your boss "your password" and giving the master passwords to your boss.
He didn't have to say the password in front of the other people in the room. He could have written it on a piece of paper, demanded a receipt for it, and demanded that his boss change the password to something he (Childs) didn't know so that he couldn't be accused of breaking things afterwards.
Childs was being a dick. I don't think he was being a year's worth of jail time dick, but I would have canned him. If this was not government that's where it would have stopped. Unfortunately someone has the ear of the DA (Kamala Harris, who is an idiot) and managed to convince her of this terrible danger and it went public and now the bureaucrats can't back down without losing face.
Childs is going to wind up a rich man at the end of this and the taxpayers of SF will wind up footing the bill for the City's IT management's and DA Harris' incompetence.
Yah, but that's cuz she can see Russia from her house. We'd have to get the oil away from the Russians.
What's ridiculous is not seeing a difference between software and hardware. The FSF is the Free Software Foundation for a reason.
What's the difference? Free as in beer doesn't work so well for hardware but the whole point of the FSF is to give you the ability to modify your computer to meet your needs.
Hardware can be "free as in speech" and older hardware tended to be, at least as far as the interface definition went. Modern hardware is orders of magnitude more complex than early 90's hardware and the documentation for hardware interfaces has largely gone the way of the dodo - partly for competitive reasons but also partly because the cost of producing that documentation is high and the number of consumers for it is small.
Open source drivers show how the hardware is interfaced with and are very useful to the subset of people who like to tinker with their hardware.
False comparison. As I said, 99% of the time the one in the toolkit is the right one to use. However, when you are using the wrong sort algorithm you will know it and your users will as well because the performance will be extremely bad or the app will run out of memory or some such.
It's a solved problem for data sets that completely fit in memory and fit the assumptions of the toolkit's library.
99% of the time the toolkit's sort function is the right one to use. Knowing how that sort is implemented, what you are trying to sort and the characteristics of different algorithms is what lets you know when you're in that other 1% of the time where you need to start writing your own sort routine.
I totally agree with this. I own a small business (California C corp) and I was behind on filing some forms. When I started looking at the penalties they can levy on the business it is really a joke. As long as I, as the CEO, don't engage in any criminal behavior there are very few real penalties.
This now adds a ridiculously complicated system that will have legal penalties if you "tamper" with it. What happens if you add a part to your car shields the GPS antenna and it can't get a fix anymore? If you bust the electrical system and the tax tracker no longer gets powered.
We don't need any mandated, you can't touch this, systems in our lives.
The report is wrong anyhow. This is no longer a tax. This is now a fee. The government should not be in the business of collecting fees for usage.
And as I said the situations are not at all parallel. When GNU was started (and I remember because I was very interested in Unix at that time) there was no worry that AT&T would be able to kill it, except if there were copyright infringements.
Computer software was not even copyrightable until 1980. Prior to that, if you got a copy, you would be able to copy it. The Unix source code was protected by "trade secret" before then. GNU got started in about 1983.
The whole regime of patents, copyrights and other "intellectual property" did not really apply to the software world at that time and there was not nearly the level of paranoia about them.
Hmmm...that was a very interesting and disingenuous comparison that he made.
AT&T had a monopoly in telecommunications, not in computers. AT&T did not have a long history of embrace, extend, extinguish as Microsoft has. AT&T did not have a history (successful, at least) of using its monopoly to create new monopolies in other areas unlike Microsoft (for example, Microsoft leveraging their OS monopoly into a office suite monopoly).
At the time that GNU was started, software was not patentable. Cloning a copyrighted system only opens you to legal problem if you actually copy the code. Cloning a system with patents will leave not just the cloner but also any users open to patent infringement lawsuits.
The two situation are not as parallel as the glib comment would make it.
So, your arguments are fine and logical but let's be practical.
I like to watch movies. Movies are very expensive to produce. Paying the producer of the movie to watch it is one way to pay for the production of movies. You're arguing that this business model is fundamentally broken. Do you have an alternative?
Well, I used to work for a supercomputer manufacturer many years ago. I'm more of an OS/C weenie than a Fortran weenie but I did get dragged into the Fortran side of things on occasion. We put a lot of effort into the Fortran compiler, especially the vectorizing Fortran compiler because many of the customers were physics/math types and they had lots of Fortran code that needed to run faster (we used to call it "dusty deck" code, implying that it had come from a deck of punchcards). So, part of it is just circular - Fortran runs fast on math because people use it for math problems.
Vectorizing Fortran was significantly easier than vectorizing C/C++ because Fortran lacked pointers (apparently they've been added since then), it had real arrays (C arrays are really just pointers with syntactic sugar) and real math functions. I think Fortran FOR loops are more regular as well which makes extracting the vector operations easier. You can do some truly grody stuff in C. For example, this is valid C:
#include <stdio.h>
int main(int argc, char ** argv)
{
doit(1);
doit(2);
}
int doit(int y)
{
int x = 0;
switch(y)
{
for (; x < 20; x++)
{
if (x < 1)
{
case 1:
printf("y = 1, setting x = 1\n");
x = 1;
continue;
case 2:
printf("y = 2, setting x = 10\n");
x = 10;
continue;
}
printf ("x = %d\n", x);
}
}
}
Don't ask me why someone would want to code it this way but you can (I've seen it done) and it makes the parser that checks for vector conditions harder (breaks reverse engineering tools too). Even with a simple for loop in C, it's possible to initialize and increment the counter in all kinds of different places. I think Fortran has less flexibility.
Also, C math handling at the time was not really up to snuff. Things like numeric exceptions were not well handled. This extended even to the OS level at times. I recall having to fix the floating point exception handling in Solaris when we ported it to our hardware (we had a SPARC based supercomputer).
I don't know where things stand today. When I saw the article title suggesting the high performance code be written in Python I cringed but I'm not really sure of the state of the art of Python. Python has never struck me as a "fast" language, though.
I think the answer for the Mac is "Don't change the font size" - I'm not a Mac UI guru but my app doesn't let you change the font size and a quick look at some other apps didn't show up any preferences for changing the font. Typically when we localize apps we have to resize any controls where the new text is too large or too small for the existing control.
If a panel is resized, the Interface Builder UI has the typical struts and springs style layout control.
I think that there's two types of UI's. There are the ones that just need to be functional and then there are the ones that need to look really polished. It's like when I toss together a web page to show information internally. A table or two here and maybe an ugly color for highlighting. Swing's BorderLayout and GridBagLayout are kind of equivalent. You can't get things exact to the pixel but you can put something together quickly. Then, there's the polished up web pages and UI's where we get the graphic designers involved and there's lots of graphics, etc. and all of the pixels need to fit exactly together. You can code those by hand but something that lets you lay out the controls and graphics *exactly* where you want them can make it a lot easier.
So, try this.
Make a panel, say 100 pixels high. Put a row of buttons along the bottom of it, get them placed how you like. Then, drag in a panel that you want to be 50 pixels high, stretched across the top from the palette.
Oops. The panel is, by default, square and something like 100 pixels high. Oh, heavens, we couldn't have overlapping components, could we? Let's just make some space here so that that panel can fit in. Oh, those buttons were where you wanted them? I'm sure you can tidy them back up later.
Try this - make a new panel. Put a button up close to the right edge but with some space from the right. Now, put another button down below it but try to put it right up against the edge of the container. Oooh, let's move the above button a bit for you.
Those are pretty easy cases to show and I got them to happen using GroupLayout with Netbean 6.7 beta on Windows just now. There are other things it does that don't always reproduce, like if you put a component offset from the component above, sometimes it decides that it should move the component above so that the edges will match. Sometimes, if you put a component too close to the edge of the container it will resize the container. Try to size the container down, oh wait, some component has a big "space on the right" defined. Can't let you resize the container and I won't tell you why.
A drag-and-drop GUI builder should NOT mess with your component placement or sizing. It's too damned hard to get them all nudged into place. Sometimes the movement is not noticed because you're really focused on one part of the screen. Sometimes your finger slips off the mouse button and you put something in the wrong place. You shouldn't have to worry that things are moved around.
Interface Builder on the Mac largely does that right. Where you put a component is where it stays. It shows you guides for where it thinks components should go but you can ignore the guides. It doesn't resize components automatically unless you ask it to.
Heh - a fellow masochist!
I agree with you that the problems are not really that difficult. They should have been part of the Java platform 12 years ago. That's what I have difficulty with.
I'm not sure that the holy grail of a cross-platform app is really very useful. Sure, for a small developer having something that also runs on the Mac is kind of nice, but Mac users are picky. If it doesn't look and feel like a Mac app they pan it so you don't gain much. Sun's has infected the Java community with that Write Once Run Everywhere meme but it's really a red herring. What they really want is "Write For Windows but it runs on Solaris too" but they won't say that.
Actually, that's not really fair, as server apps DO run everywhere. The difference is that you have a systems admin (or at least a wannabe) installing those and they can install the JRE/JDK properly and they can get the configuration pulled together.
I think that Sun's all-or-nothing approach to JRE deployment has been a major problem. You had to either give the user the complete JRE or you had to go through some kind of licensing dance with Sun. If they had just gone with a per-seat kind of license and let people imbed Java without any fuss it would be a lot more successful on the desktop in my opinion. I just love the new "install on demand" JRE idea. What bozo came up with that? Yes, my user wants to download an app and then watch things spin when the try to launch it while it download the rest of the junk it needs. Genius at work there. I know when I download something I want to download it and then run it. If it's going to take 15 minutes to download, let me know that up front when I start the download in the browser and I will go get a cup of coffee or something. It's almost as bad as installation processes that pop up a dialog box after an hour of installing asking you some inane question.
Sun really wants to put the Java brand front and center but it just doesn't resonate with anyone besides developers. I think the "Java App Store" will do about as well as the "C App Store" and the "C++ App Store" have done...oh wait, those other two don't exist, do they?
Can Java succeed on the desktop? I think it can but it needs to be easy to write NON-PORTABLE apps in Java - if I want to write something that shines on Windows and doesn't work on the Mac or Linux (or Solaris) it shouldn't be a big deal. Now that Sun has let go of the licensing on Java we may see. I think the language, the JVM, the platform, the variety of libraries available and the tools (except for the GUI builders) make Java a great development platform.
Yah. I haven't actually used Solaris since about 1999 but I was curious if Java worked any better on Solaris than Linux the other day and everything I found in the docs was just what you describe.
Sad, so sad.