Well, like I said, that was just my guess on the matter.:) (I knew saying the dll was copied wasn't exactly right, but I thought it was something like that.)
My take on it is that it will now be able to do it on non-x86 machines. I believe (correct me if I'm wrong) that the way that mplayer currently plays these files is by using the codecs copied straight from a windows install. So... now they can use codecs that were written to work on a linux platform.
Re:Comparing programming to "real world" endeavour
on
Software Craftsmanship
·
· Score: 1
I guess I didn't make my point very well. Of course there is nothing out there that is exactly like programming. No matter what examples people could possibly come up with, you can knock holes in it.
My argument is that that is counterproductive. The point is not to come up with one golden example that describes all we need. Instead, the trick is to understand what parts of other trades we do need to learn from. This includes house building, bridge building, book publishing, etc. If you can't find some common elements, then you aren't looking hard enough. (Or, more likely, you are looking too hard) Remember, they don't call them generalizations for nothing.
Re:Comparing programming to "real world" endeavour
on
Software Craftsmanship
·
· Score: 1
But it is attitudes like this that will cause you to repeat all of the mistakes already known by other professions.
This is still my main gripe against acedemics in computer science fields. They think they need vastly new methods of teaching for these "new fields." While some adjustments are indeed necessary, please don't just try to reinvent everything. You can still use existing methodologies and such, but you have to understand them yourself.
For instance, the dresser may be a bad example. But only because it is in a different scope. The dresser is part of a whole. Specifically, it is part of a place of residence. If you have a programmer and give him a huge unbreakable task (such as building a "project"), then don't be surprised when it doesn't turn out. Instead, realize that you should give individual programmers components of the whole program.
My point, I guess, is that you can always come up with examples that don't work. The trick is finding the ones that do work, and taking advantage of them.
I was always getting irritated to hell with people in academia who thought that CS was a completely new and unique subject that could not be taught with the same principals.
I do not believe CS is exactly like other fields, but to think that nothing can be learned from them borders on asinine.
Re:Beware of overusing patterns.
on
Design Patterns
·
· Score: 2
This reminds me of why I despised the CS department in college. They thought that they were a completely unique subject that had to be taught completely differently then any other subject. What was the result? They were having to learn lessons that every other department had learned years ago. That is the one thing I absolutely loved about the Design Patterns book, the fact that they took cues from other disciplines
So.. First off, There is no "real world." Anyone who uses that phrase is often about to explain an excuse for why they do something the way they do.
However, I was not saying that I think there is an exact point where planning ends and coding begins, but they should be at least sheilded from each other.
If somebody comes in with a whole new pattern of approaching a situation, perhaps they should realize they either never had a pattern (or plan) of approach before, or that they should finish the first approach. If it is the former, that is the problem. If the later, well, suck it up and finish it.
Too many times you get people who think they should immediately apply the latest and greatest approach to a project that is still in the implementation phase of an older approach. That is a horrible mistake for people to make.
I believe you grossly overestimate the army of geeks who will supposedly buy his product. Especially when you do not even know his market.
I am not one that claims all GPL followers are cheapskates, but I also realize that not many companies selling products have seen any benefit from having GPL'ed code.
The usual angle, that of selling support, may or may not apply in this position. You can't say without knowledge of what is being sold.
And finally, not many companies/individuals are up to the task of supporting all of the effort it takes to support an open source project.
Beware of overusing patterns.
on
Design Patterns
·
· Score: 5, Interesting
Maybe overusing isn't the correct term, but definitely blindly using. I have seen far too many times (in far too short a time) where people will just start tossing in as many "patterns" as they can.
Sometimes, as if to really horrify me, the reasons for including a pattern are to appease a manager!! This really frightens me, as the patterns are not discussed at the planning stage, but as an afterthought to implementation.
Which brings me to a question. I have always viewed design patterns to be something that are used during the planning phase of a project. All too often, I am seeing where people start trying to shoehorn a design pattern into a project because they just heard about how great of a job it does at something. Does this happen elsewhere, or just with the projects I see?
Isn't this the way LCD's work, as well? I know that CRT's act as you say, but I was under the impression that an image on an LCD could be kept without "refreshing" as well. The only problem is that the "changing" speed of a pixel on an LCD is rather slow.
That is why you (debatedly) don't get eye strain problems with LCD's. They aren't constantly blanking out in front of you. (Which, as anyone who has had to work on a screen stuck at 60hz will tell you, refresh rates suck in that area.)
You do realize they are considering a SCRIPTING language right? If your whole arguement was because of a VM, that is shot straight to hell.
Now, you can bring in such advances as precompiling the pages, but I still think you grossly underestimate the advances in current JVMs.
And if you don't think EJB's scale well, you fly in the face of the vast majority of experts out there.
The rest of what you said is right on, though. It will take time to design the site. It also takes a fairly high skillset. If someone doesn't know the "correct" way of doing stuff, then it will be a horrible app. Same goes in most languages, though EJB's do seem to be especially non-forgiving.
From where I look at this, the market is actually quite different.
I would say the vast majority of sites I have personally ever worked on have been internal projects. Using web standards to create a front end for an application is a very appealing idea. After all, if one decides to turn the application into a distributed app, there is a lot less work.
This is where I see the advanced topics of DHTML and JavaScript being used, not in the latest homepage of some stranger. Probably not even in the latest shopping site, which was probably designed years ago for ultimate compatibility.
As an aside, with Mozilla (the engine) gaining in popularity as an application framework, I can only see these topics gaining even more relevance.
:) Yeah, I got confused by your use of the word software at first. Looking at it now, you were obviously talking about design software. Oops.
Still, a few more questions. When I think of most async designs, I think of the ready signal as being a designed race condition where the ready signal is guaranteed to fail. The only difference between this and clocked designs is that this condition is determined by the module (not a global clock) and can vary. Is this wrong?
If not... then that part I get. However, I fail to see how there will not be some logic considerations when you move to a non-clocked system. First, since there is no deterministic way to know how long a module will take, there is no way to know what can be done in the wait period. That is to say, when a module "blocks", would it be advantageous to wait, or to do something else then check back?
The way I see it, there are four possibilities. 1) You wait, and the wait time was considerably shorter due to the async design. This is obviously a win on the async side. 2) You wait, but the wait time was the same as a sync design. I see this as detrimental. (Unless no work could have been performed in the wait time, obviously) 3) You complete another "ready" task and check back later, but the process was ready well before you checked back. Nothing really lost here, but what was gained? 4) You complete another "ready" task and check back later, and the process is "ready" shortly before you get back.
To me, with hyperthreading and lots of other new designs, 4 is the designed for solution today. So, in theory, you can keep the processor occupied at all times.
Now, my main comment, if the processor is busy at all times (in all places) what can be gained by going to async design? I do agree it is worth looking into, simply because it is there, but I am skeptical of those that think a magnitude of performance increase is possible overnight.
Also, I am only looking at this from a CPU perspective in this. I can see the obvious advantages of it elsewhere. (Esp. in regards to power.)
Software will having next to nothing to do with the race conditions in the processor. Instead, the race condition you pointed out will be the difficulty. That is, how can you ensure the "ready" signal is indeed slower then the computations that a module is performing? This is not an easy thing to do. Especially if you want it to report as soon as it is done. Most likely, a signal will fire after the longest time a unit could take. You do not have a speed up for the fast solutions, but you don't have to worry about complex logic on the ready path, either. Another solution would be handshaking, but then you may run into an explosion in the amount of logic.
Also, something I think would be a problem. Many of the current optimizations in out of order execution are almost custom fit to a clocked design. That is, the processor knows IO will take so many cycles, branches take a certain amount, etc. Now, currently (especially with hyperthreading) the processor is coming closer to keeping the execution units busy at all times. Do people really expect some magical increase when the clock is taken out? The scheduler will have to change dramatically. Right?
More likely, the processor would hold off on the program branching and send code for another process down the pipe. That way, you have slowed down (definitely) the process that is branching, as it is waiting for the branch, but you have allowed it to perform calculations on another process in the same time. Effectively making sure that you should never have to "flush" the registers.
So... they could eliminate the whole concept of branch "penalties" altogether.
Now is this how it is actually implemented? I don't know. There are already plenty of complications present in the processor, so changing this bit of logic is far from trivial. Still, since a branch calculation is a fixed amount of time that leaves part of the execution units free, I don't know of any reason this sort of scheme could not be implemented.
You missed my whole point of the CD price being irrelevent. It is merchandise for the movie. Just like how all of the other merchandise has a price placed to help offset the cost of the movie, so do the CD's.
If the movie had no merchandise behind it (CD included in this merchandise bag) then it would have to be sold at a much higher price to keep the same level of profit/revenue/whatever.
So... the Soundtrack has to make money not only for the cost of the soundtrack, but to help make money for the movie. The movie just has to support itself. Does that make sense? In a sense, you are paying a fee to support the movie and the soundtrack when you buy the soundtrack, but just the movie when you buy it.
Think of the people that buy action figures or cells from the movie. The movie is a sort of superset for those, but a lot of movies also makes most of the money off of the sales of those items. I would categorize the soundtrack in the same arena. Poeple that buy soundtracks are collectors, even if they don't realize it.
And again, I was never arguing about value or anything. I just think that comparing the prices of the two is somewhat of a flawed argument, as it ignores a lot.
I don't know if I really understand/agree with the argument that something is amiss when a soundtrack costs as much or more then a movie.
The soundtrack was most likely produced under the budget of the movie. It is then considered merchandise for the movie, and is used in making money for the movie. So... the movie can costs so little precisely because the soundtrack costs so much.
I'm not saying that things couldn't be more reasonably priced. But at the same time, I can't help but feel like the same as when I complain about gas prices going up. Sure, they are going up, but we still have it fairly well off. And, after all, cd's are a luxury item.
That doesn't make it right just because everyone is doing it.
Actually, isn't that exactly how language works? I'm not big on all language theory (or whatever it is called, though I do like word history), but I find it hard to believe that the rules in language are anything more the descriptive.
God could, if he wanted to, control our actions, and even our thoughts, but instead he has given us the ability to make choices for ourselves. What you do with that ability is up to you.
I find it amusing that we have spent so much of our time recently trying to do just the opposite. Life is becoming increasingly about control. If we do continue to limit our choices, how long before we have none left to make?
So, if this guy was able to guess someones password, I am VERY curious as to what it was. If you know anything about the person, it makes guessing easier. However, if you don't know even the owner of the account, how do you guess a good password?
My only hunch is that the password was something like 'abc123'. It cracks me up how many people have passwords such as that and are supposedly worried about security.
It is also funny to hear what some of my friends think are secure passwords. Among them being obscure Anime characters.
Note he said beginning rise, ending rise and not beginning high, ending high. The rise/fall of a signal are not connected.
Now, I am not saying the original poster is correct, as I don't know. However, what you said makes no sense. If the next rise happens as soon as the previous fall ends... then you are saying that the hold states of the clock are as fast as the rise/fall states. I HIGHLY doubt such a statement. This would essentially be saying that as fast as we can make a clock switch is how fast the clock goes. This is CLEARLY not the case.
I tried that, but I evidently didn't know how to save the correct license information.
So... after swapping the cpu's back and forth a few times, I finally just said screw it and deleted all of the files. That was the main headache. Remaking them was no big deal, even allowed me to rethink which files I really wanted on my (then) small hard drive.
Re:Breaking interoperability... again???
on
GCC 3.2 Released
·
· Score: 2
While I understand your point, it seems almost out of place here.
The ABI was changed for (hopefully) good reasons. These reasons probably included speed, ease of compilation/optimization, stability, etc. Further, it is safe to presume that these changes could not have been addressed successfully without changing the ABI. There comes a time when backwards compatible is more of a hindrance then not.
Finally, and perhaps this is a misperception of mine, I would think that most of the individuals using this software have access to the source code for the programs they use. So... they can recompile everthing. Not a trivial task, to be sure, but still possible.
Unfortunately, I rather liked the way media player ripped stuff. I have a lot of import stuff, and actually appreciate the unicode characters and such.
Plus, the heirarchy by which it will organize the files is quite nice. Will even show the album art in the explorer.
Of course, now I am getting bitten by another crap DRM problem. I bought a sony netmd player, and it wants me to use their crap program to upload songs to it. That is annoying.
So... anyone know of any other options for getting files to the netmd?
You don't even have to try to reload backed up data to get bit by this. Not too long ago, I upgraded my processor and was subsequently locked out of all the media files I made using Media Player.
I was less then pleased, for obvious reasons. It was just a minor headache remaking files using other programs and such, but it was a minor headache I could have lived without.
Slashdot Mirror
Well, like I said, that was just my guess on the matter. :) (I knew saying the dll was copied wasn't exactly right, but I thought it was something like that.)
So, what was significant about this?
I was going to post the same thing. :)
My take on it is that it will now be able to do it on non-x86 machines. I believe (correct me if I'm wrong) that the way that mplayer currently plays these files is by using the codecs copied straight from a windows install. So... now they can use codecs that were written to work on a linux platform.
I guess I didn't make my point very well. Of course there is nothing out there that is exactly like programming. No matter what examples people could possibly come up with, you can knock holes in it.
My argument is that that is counterproductive. The point is not to come up with one golden example that describes all we need. Instead, the trick is to understand what parts of other trades we do need to learn from. This includes house building, bridge building, book publishing, etc. If you can't find some common elements, then you aren't looking hard enough. (Or, more likely, you are looking too hard) Remember, they don't call them generalizations for nothing.
But it is attitudes like this that will cause you to repeat all of the mistakes already known by other professions.
This is still my main gripe against acedemics in computer science fields. They think they need vastly new methods of teaching for these "new fields." While some adjustments are indeed necessary, please don't just try to reinvent everything. You can still use existing methodologies and such, but you have to understand them yourself.
For instance, the dresser may be a bad example. But only because it is in a different scope. The dresser is part of a whole. Specifically, it is part of a place of residence. If you have a programmer and give him a huge unbreakable task (such as building a "project"), then don't be surprised when it doesn't turn out. Instead, realize that you should give individual programmers components of the whole program.
My point, I guess, is that you can always come up with examples that don't work. The trick is finding the ones that do work, and taking advantage of them.
I agree 100% with this!
I was always getting irritated to hell with people in academia who thought that CS was a completely new and unique subject that could not be taught with the same principals.
I do not believe CS is exactly like other fields, but to think that nothing can be learned from them borders on asinine.
This reminds me of why I despised the CS department in college. They thought that they were a completely unique subject that had to be taught completely differently then any other subject. What was the result? They were having to learn lessons that every other department had learned years ago. That is the one thing I absolutely loved about the Design Patterns book, the fact that they took cues from other disciplines
So.. First off, There is no "real world." Anyone who uses that phrase is often about to explain an excuse for why they do something the way they do.
However, I was not saying that I think there is an exact point where planning ends and coding begins, but they should be at least sheilded from each other.
If somebody comes in with a whole new pattern of approaching a situation, perhaps they should realize they either never had a pattern (or plan) of approach before, or that they should finish the first approach. If it is the former, that is the problem. If the later, well, suck it up and finish it.
Too many times you get people who think they should immediately apply the latest and greatest approach to a project that is still in the implementation phase of an older approach. That is a horrible mistake for people to make.
I believe you grossly overestimate the army of geeks who will supposedly buy his product. Especially when you do not even know his market.
I am not one that claims all GPL followers are cheapskates, but I also realize that not many companies selling products have seen any benefit from having GPL'ed code.
The usual angle, that of selling support, may or may not apply in this position. You can't say without knowledge of what is being sold.
And finally, not many companies/individuals are up to the task of supporting all of the effort it takes to support an open source project.
Maybe overusing isn't the correct term, but definitely blindly using. I have seen far too many times (in far too short a time) where people will just start tossing in as many "patterns" as they can.
Sometimes, as if to really horrify me, the reasons for including a pattern are to appease a manager!! This really frightens me, as the patterns are not discussed at the planning stage, but as an afterthought to implementation.
Which brings me to a question. I have always viewed design patterns to be something that are used during the planning phase of a project. All too often, I am seeing where people start trying to shoehorn a design pattern into a project because they just heard about how great of a job it does at something. Does this happen elsewhere, or just with the projects I see?
Isn't this the way LCD's work, as well? I know that CRT's act as you say, but I was under the impression that an image on an LCD could be kept without "refreshing" as well. The only problem is that the "changing" speed of a pixel on an LCD is rather slow.
That is why you (debatedly) don't get eye strain problems with LCD's. They aren't constantly blanking out in front of you. (Which, as anyone who has had to work on a screen stuck at 60hz will tell you, refresh rates suck in that area.)
You do realize they are considering a SCRIPTING language right? If your whole arguement was because of a VM, that is shot straight to hell.
Now, you can bring in such advances as precompiling the pages, but I still think you grossly underestimate the advances in current JVMs.
And if you don't think EJB's scale well, you fly in the face of the vast majority of experts out there.
The rest of what you said is right on, though. It will take time to design the site. It also takes a fairly high skillset. If someone doesn't know the "correct" way of doing stuff, then it will be a horrible app. Same goes in most languages, though EJB's do seem to be especially non-forgiving.
From where I look at this, the market is actually quite different.
I would say the vast majority of sites I have personally ever worked on have been internal projects. Using web standards to create a front end for an application is a very appealing idea. After all, if one decides to turn the application into a distributed app, there is a lot less work.
This is where I see the advanced topics of DHTML and JavaScript being used, not in the latest homepage of some stranger. Probably not even in the latest shopping site, which was probably designed years ago for ultimate compatibility.
As an aside, with Mozilla (the engine) gaining in popularity as an application framework, I can only see these topics gaining even more relevance.
:) Yeah, I got confused by your use of the word software at first. Looking at it now, you were obviously talking about design software. Oops.
Still, a few more questions. When I think of most async designs, I think of the ready signal as being a designed race condition where the ready signal is guaranteed to fail. The only difference between this and clocked designs is that this condition is determined by the module (not a global clock) and can vary. Is this wrong?
If not... then that part I get. However, I fail to see how there will not be some logic considerations when you move to a non-clocked system. First, since there is no deterministic way to know how long a module will take, there is no way to know what can be done in the wait period. That is to say, when a module "blocks", would it be advantageous to wait, or to do something else then check back?
The way I see it, there are four possibilities.
1) You wait, and the wait time was considerably shorter due to the async design. This is obviously a win on the async side.
2) You wait, but the wait time was the same as a sync design. I see this as detrimental. (Unless no work could have been performed in the wait time, obviously)
3) You complete another "ready" task and check back later, but the process was ready well before you checked back. Nothing really lost here, but what was gained?
4) You complete another "ready" task and check back later, and the process is "ready" shortly before you get back.
To me, with hyperthreading and lots of other new designs, 4 is the designed for solution today. So, in theory, you can keep the processor occupied at all times.
Now, my main comment, if the processor is busy at all times (in all places) what can be gained by going to async design? I do agree it is worth looking into, simply because it is there, but I am skeptical of those that think a magnitude of performance increase is possible overnight.
Also, I am only looking at this from a CPU perspective in this. I can see the obvious advantages of it elsewhere. (Esp. in regards to power.)
Not sure if you were serious or not...
Software will having next to nothing to do with the race conditions in the processor. Instead, the race condition you pointed out will be the difficulty. That is, how can you ensure the "ready" signal is indeed slower then the computations that a module is performing? This is not an easy thing to do. Especially if you want it to report as soon as it is done. Most likely, a signal will fire after the longest time a unit could take. You do not have a speed up for the fast solutions, but you don't have to worry about complex logic on the ready path, either. Another solution would be handshaking, but then you may run into an explosion in the amount of logic.
Also, something I think would be a problem. Many of the current optimizations in out of order execution are almost custom fit to a clocked design. That is, the processor knows IO will take so many cycles, branches take a certain amount, etc. Now, currently (especially with hyperthreading) the processor is coming closer to keeping the execution units busy at all times. Do people really expect some magical increase when the clock is taken out? The scheduler will have to change dramatically. Right?
More likely, the processor would hold off on the program branching and send code for another process down the pipe. That way, you have slowed down (definitely) the process that is branching, as it is waiting for the branch, but you have allowed it to perform calculations on another process in the same time. Effectively making sure that you should never have to "flush" the registers.
So... they could eliminate the whole concept of branch "penalties" altogether.
Now is this how it is actually implemented? I don't know. There are already plenty of complications present in the processor, so changing this bit of logic is far from trivial. Still, since a branch calculation is a fixed amount of time that leaves part of the execution units free, I don't know of any reason this sort of scheme could not be implemented.
Perhaps if someone else has some information?
You missed my whole point of the CD price being irrelevent. It is merchandise for the movie. Just like how all of the other merchandise has a price placed to help offset the cost of the movie, so do the CD's.
If the movie had no merchandise behind it (CD included in this merchandise bag) then it would have to be sold at a much higher price to keep the same level of profit/revenue/whatever.
So... the Soundtrack has to make money not only for the cost of the soundtrack, but to help make money for the movie. The movie just has to support itself. Does that make sense? In a sense, you are paying a fee to support the movie and the soundtrack when you buy the soundtrack, but just the movie when you buy it.
Think of the people that buy action figures or cells from the movie. The movie is a sort of superset for those, but a lot of movies also makes most of the money off of the sales of those items. I would categorize the soundtrack in the same arena. Poeple that buy soundtracks are collectors, even if they don't realize it.
And again, I was never arguing about value or anything. I just think that comparing the prices of the two is somewhat of a flawed argument, as it ignores a lot.
I don't know if I really understand/agree with the argument that something is amiss when a soundtrack costs as much or more then a movie.
The soundtrack was most likely produced under the budget of the movie. It is then considered merchandise for the movie, and is used in making money for the movie. So... the movie can costs so little precisely because the soundtrack costs so much.
I'm not saying that things couldn't be more reasonably priced. But at the same time, I can't help but feel like the same as when I complain about gas prices going up. Sure, they are going up, but we still have it fairly well off. And, after all, cd's are a luxury item.
Actually, isn't that exactly how language works? I'm not big on all language theory (or whatever it is called, though I do like word history), but I find it hard to believe that the rules in language are anything more the descriptive.
I find it amusing that we have spent so much of our time recently trying to do just the opposite. Life is becoming increasingly about control. If we do continue to limit our choices, how long before we have none left to make?
So, if this guy was able to guess someones password, I am VERY curious as to what it was. If you know anything about the person, it makes guessing easier. However, if you don't know even the owner of the account, how do you guess a good password?
My only hunch is that the password was something like 'abc123'. It cracks me up how many people have passwords such as that and are supposedly worried about security.
It is also funny to hear what some of my friends think are secure passwords. Among them being obscure Anime characters.
Note he said beginning rise, ending rise and not beginning high, ending high. The rise/fall of a signal are not connected.
Now, I am not saying the original poster is correct, as I don't know. However, what you said makes no sense. If the next rise happens as soon as the previous fall ends... then you are saying that the hold states of the clock are as fast as the rise/fall states. I HIGHLY doubt such a statement. This would essentially be saying that as fast as we can make a clock switch is how fast the clock goes. This is CLEARLY not the case.
Did I missunderstand you?
I tried that, but I evidently didn't know how to save the correct license information.
So... after swapping the cpu's back and forth a few times, I finally just said screw it and deleted all of the files. That was the main headache. Remaking them was no big deal, even allowed me to rethink which files I really wanted on my (then) small hard drive.
While I understand your point, it seems almost out of place here.
The ABI was changed for (hopefully) good reasons. These reasons probably included speed, ease of compilation/optimization, stability, etc. Further, it is safe to presume that these changes could not have been addressed successfully without changing the ABI. There comes a time when backwards compatible is more of a hindrance then not.
Finally, and perhaps this is a misperception of mine, I would think that most of the individuals using this software have access to the source code for the programs they use. So... they can recompile everthing. Not a trivial task, to be sure, but still possible.
Unfortunately, I rather liked the way media player ripped stuff. I have a lot of import stuff, and actually appreciate the unicode characters and such.
Plus, the heirarchy by which it will organize the files is quite nice. Will even show the album art in the explorer.
Of course, now I am getting bitten by another crap DRM problem. I bought a sony netmd player, and it wants me to use their crap program to upload songs to it. That is annoying.
So... anyone know of any other options for getting files to the netmd?
You don't even have to try to reload backed up data to get bit by this. Not too long ago, I upgraded my processor and was subsequently locked out of all the media files I made using Media Player.
I was less then pleased, for obvious reasons. It was just a minor headache remaking files using other programs and such, but it was a minor headache I could have lived without.
That has to be one of the most obscure quotes I could have imagined seeing.
:)
My favorite part of the scene, though, is his face when he sees that he has dropped the egg.