Disperse extremely rapidly- and cool just as rapidly as a result. There's probably a reasonable range of danger for flammability, but anything beyond a short distance is perfectly safe. I'd say the bigger danger would be that such a fracture in the glass would probably cause it to somewhat explosively shatter, and the glass fragments could pose a danger.
I'm pretty sure I didn't mention the word "law" a single time in my statement, so you're making assumptions that aren't valid. The parent made the rather nonsensical claim that uploaders are somehow wrong but downloaders are not; I pointed out that this doesn't really make any sense- it's the same ridiculous reasoning that has countries banning things that might, conceivably, be used for something nefarious regardless of their positive uses.
You're preaching to the choir about copyright law, although to be honest I think the problem derives more from the way the music industry is set up (specifically, the assigning of copyrights to the industry rather than the retainment of them by artists) in addition to ridiculous durations.
Err, that's really a completely false statement. That's the sort of thing that leads to banning things because they could potentially be used for something bad. Downloaders are just as in the wrong as uploaders are. I'm as anti-**AA as anyone here, but claiming that uploaders are somehow to blame while downloaders somehow aren't is really silly- either they're both wrong or neither is.
Moore's law does pertain to transistor density, but anyone who doesn't see the relationship between the two is just as silly. Increasing transistor densities invariably mean price drops for the previous generation of chips, and since the power/capacity of chips is growing more rapidly than the needs of devices, especially in the ultraportable segment, it is not at all surprising that the chip prices for those devices see a corresponding drop.
Moore's law may pertain to transistor density, but increasing transistor density indirectly affects the price of chips at lower transistor densities.
Good point. Running now gets me a 90 with the webkit nightly, and examining the earlier failure shows at least one test (69) which explicitly states may be a networking issue- something that seems highly likely given how overloaded the acid3 server was earlier in the day.
That's actually not true at all- the two capabilities are orthogonal to each other.
Smart Mailboxes are, in effect, saved searches with result sets that are updated in real time. That is, they are automatic sortings based on intrinsic properties of the messages in the account.
Labels, on the other hand, are user-applied attributes of a message rather than something intrinsic. They can therefor be used to create groupings that cannot be automatically created without actual semantic analysis of the content of the message.
They're both very useful, but neither one actually provides the capabilities of the other- and, in fact, they'd work together beautifully. If the search capabilities of smart mailboxes could take labels into account, they could provide much more effective sorting.
That applies only to off-CPU communication, which is not what was originally specified. A long in-cache computation could very easily happen simultaneously on multiple cores at once.
Also, not all architectures require such serialization for memory access anyway.
This is very, very wrong. Data-set partitioning is certainly one way of achieving parallelism in programming, but it is hardly the only way- nor is it applicable to all domains, as many problems have solutions with too many inter-cell data dependencies. In addition, threads provide a wealth of benefits to application developers by allowing multiple unrelated tasks to be performed simultaneously.
There is, and will always be, overhead associated with parallelization. It may sound great to say "oh, we can farm out parts of this data set to other cores!", but that requires a lot of start-up and tear-down synchronization. It's not at all uncommon for overall performance to be improved by doing something *unrelated* at the same time, requiring less synchronization overhead.
Are threads perfect for everything? No. But calling them the second worse thing to happen to computing is, as best, disingenuous.
As you know, multiple threads in a program do not actually execute concurrently - processing is still serial, it's just so fast that threads can appear to execute simultaneously - and it's not just about queuing execution either.
That holds only for multithreaded programming on a single core. As soon as there are multiple cores available, processing does, in fact, happen simultaneously.
The findings are relevant to silicon precisely because the macro-level tests have *not* shown fatigue cracks. Now, the article suggests that this may be a weakness in the macro-level testing methodology, but it doesn't change the fact that silicon was considered "special" because of it's structure, and now it appears not to be.
So, uh, you've actually got this completely backward. No one thinks it's a new type of stress, it merely wasn't expected that silicon would be susceptible to it.
Ahh... technically speaking, this could be very bad advice in the business arena. While I'm not a lawyer, AFAIK code is copyrighted at the act of creation, and simply by making it available for viewing the author is not automatically giving up those rights. While it is highly unlikely that such a code snippet would cause problems down the road, it is not impossible that it could.
Rewriting simply because it was written external to the company isn't a good thing. Rewriting because it was written external to the company and you're not certain of your company's license to legally make use of the code is an *entirely* different thing.
The author not attaching a particular license to the code is not a blanket license to do with as you will. The author may have intended that, but I don't believe it's true in the legal sense.
It might make more sense to go as you're suggesting, but given the mess that is current copyright law, a business ought to tread more carefully.
The Ratchet and Clank games actually have a pretty good reputation for actually being fun as well. I played the first one on the PS2 and found it thoroughly enjoyable- fun puzzle-platform-action. The high production values really did add to it, as well.
From what I've heard so far, this one's done the same, though I haven't been interested in throwing that much money down the drain to buy a ps3 just yet.
I still wouldn't call someone an idiot for it without knowing more details- especially given that the driver could be completely in control and yet be subsequently hit by another motorist. Or, on a similar note, another motorist with a similar problem passing you in the lane next to you could easily collide with you.
Clearly some of the incidents I mentioned can be recovered from, and my point was not that there's nothing one can do to personally mitigate some risk- it's just that the driver alone does not have 100% control of the risk of operating a motor vehicle.
our personal avoidance ratio clearly hasn't been high
Actually, it's been very high. And yes, certainly it is in part due to my own care in driving. At the same time, I'm at least aware that I'm not 100% in control of the situation, and that no matter the precautions I take at any given time it is entirely possible for the unexpected to occur.
As an aside, yes, I know you think you're clever for trying to be insulting in a patronizing fashion mentioning ineptitude or my presumed avoidance ratio. You're not; it's just symptomatic of the same arrogance that I was originally pointing out.
You're living in a fantasy world. It only takes one- and really, it doesn't even take an idiot. Ever had a blowout on the highway? Would you call yourself an idiot if a piece of debris you couldn't see caused one and sent you into a crash? Didn't think so. Doesn't change the good chance of death you have as a result.
Oh, and are you always the driver when you're in a car? Never let anyone else drive? Never taken a taxi, or a shuttle bus of some sort?
The numbers are very simple. Compare the number of plane trips per year and number of plane deaths with the number of car trips per year and the number of car deaths. The plane related incidents are almost statistically unnoticeable in this country. Car crashes, on the other hand, are one of the leading causes of death.
Nothing that goes on in a program is completely transparent, no matter how much people would like to claim it is. Garbage collection has its place. It also has its own set of faults and problems- and it's also not perfect, and it can be a crutch. You can, in a practical sense, leak memory just as easily in a garbage collected system as you can in any other.
Explicit control, reference counting, garbage collection- the important thing with all of them is that you have to understand your memory management model and how it interacts with your application. If you don't, you'll have problems with all three. There is no panacea.
It's a question of the type of memory issues that arise. If you have a minor memory leak in a simple function in the context of a good architecture, both finding and correcting it should be trivial. If you've spent proper time in the architecture to account for memory management, you should have architected in solutions to application-level memory management, leaving only low-level management to be a source of problems- where those problems are not difficult.
Basically, not all memory leaks are created equal. Correct architecture prevents the "hard" classes of memory leaks, leaving the "easy" classes that are really no more difficult to find/fix than anything else.
Or perhaps they're too busy thinking about clearly-defined objects, robust interfaces, clean documentation and the "big picture" then to worry about moving individual bytes around.
Actually, I'd say they're not busy enough- if they actually had been, proper memory management should simply fall into place on top of a clean architecture. If you're trying to shoehorn memory management back into something that didn't support it before, you're going to have issues- and this applies whether you're doing c/c++ style management, reference counting, or garbage collecting.
Yes, unfortunately iTunes sucks at that. For example, sooner or later, it ends up duplicating songs. And duplicating more songs. And duplicating yet more songs. All of a sudden, when I listen to a CD I have to listen to the same song three times.
I've never noticed that in all the years I've been using it, which is pretty much since it first came out. Any ideas on what causes it? I just strongly wonder if it's the same principle of trying to fight the software.
Linux and MacOS are no different in this regard. In fact, for every one of those Mac apps you like, there is a very similar Linux app--and then some.
I've been using Linux for over ten years now. They are very, very different. There are things for which I love linux for- and I use it on a daily basis, even if much of that is simply for valgrind- but the two operating systems are worlds apart when it comes to getting out of your way and letting you do everyday tasks without having to tinker. It's getting better, but much of the problem is a programmer mindset that is very appropriate when hacking command line tools, building infrastructure-level software, etc- and horribly inappropriate for UI design. I'm sorry, but anyone who claims that the available linux UIs are better than MacOS X for the majority of work is simply deluding themselves- and the moment you claim "but there are 18 million options you can customize to make it exactly how you want it!", you prove my point. Linux (including the applications available to the platform) is software written mostly for programmers, by programmers.
It's not merely the applications. There are certainly some individual applications that are getting there. It's the overal system integration, the seamlessness of the OS itself (counting the windowing system as part, since any user will consider it as such), its management tools- and, more importantly, the lack of a *need* for management tools.
Linux has been getting better, and a lot of very talented, dedicated programmers are doing a lot to improve it. But it's got a long way to go- and frankly, I think any of those talented programmers who looked at it objectively would agree.
I'm not trying to spin anything, and I'm definitely not claiming the software is perfect- or that it can cover every case. For the above, you're completely correct- iTunes insufficiently handles that particular case. I myself have been annoyed on occasion when it places something into the library when I open it, leaving me to promptly delete it after listening since I know I'll not want it in the future.
Your example isn't part of the set I was discussing earlier- you've got a task that iTunes doesn't allow you to accomplish, rather than making it difficult to insert meaningless steps into a task that it does allow you to accomplish.
That's true- but you're not seeing the point. Can I find specific music in a file manager? Sure. Can I find all of the songs with title, artist or album that contain the string foo? No, not really- sure, theres probably a command line tool that will let you look through id3 tags that way, but remember my point- we want to simply accomplish a task, not pat ourselves on the back for doing so in an esoteric fashion. The search box alone is more than a file manager would give me.
The others are the same. Shuffle? Repeat? Smart playlists? Playlist management in general? Two-click burning of a playlist? Not going to find those in a file manager. Sure, you could do them- and yes, I've written my share of scripts to do that sort of thing as well- but if I want to write a script I'll do it for something more interesting than "shuffle".
Geeks, and programmers especially, are very much in the habit of seeing tasks as a sequence of steps to accomplish a goal. The problem is that we often lose sight of the fact that its the goal that's actually important, not the details of the steps we take to get there. iTunes and the like are build for accomplishing goals, not for worrying about steps, and it can be difficult to shift your mindset to that- but it really is a lot easier when you do, and you'll wonder why you didn't sooner.
(Incidentally, the mindset has actually made me a better developer, too.)
Slashdot Mirror
Disperse extremely rapidly- and cool just as rapidly as a result. There's probably a reasonable range of danger for flammability, but anything beyond a short distance is perfectly safe. I'd say the bigger danger would be that such a fracture in the glass would probably cause it to somewhat explosively shatter, and the glass fragments could pose a danger.
You're a little confused.
Aqua is the set of widgets and such that make up the MacOS X user interface. It has evolved over the various versions of the OS, but it's still Aqua.
Quartz is the underlying PDF-based drawing technology that MacOS X uses to draw everything to the screen- including the Aqua UI widgets.
Referring to native Aqua is quite correct.
I'm pretty sure I didn't mention the word "law" a single time in my statement, so you're making assumptions that aren't valid. The parent made the rather nonsensical claim that uploaders are somehow wrong but downloaders are not; I pointed out that this doesn't really make any sense- it's the same ridiculous reasoning that has countries banning things that might, conceivably, be used for something nefarious regardless of their positive uses.
You're preaching to the choir about copyright law, although to be honest I think the problem derives more from the way the music industry is set up (specifically, the assigning of copyrights to the industry rather than the retainment of them by artists) in addition to ridiculous durations.
Err, that's really a completely false statement. That's the sort of thing that leads to banning things because they could potentially be used for something bad. Downloaders are just as in the wrong as uploaders are. I'm as anti-**AA as anyone here, but claiming that uploaders are somehow to blame while downloaders somehow aren't is really silly- either they're both wrong or neither is.
Moore's law does pertain to transistor density, but anyone who doesn't see the relationship between the two is just as silly. Increasing transistor densities invariably mean price drops for the previous generation of chips, and since the power/capacity of chips is growing more rapidly than the needs of devices, especially in the ultraportable segment, it is not at all surprising that the chip prices for those devices see a corresponding drop.
Moore's law may pertain to transistor density, but increasing transistor density indirectly affects the price of chips at lower transistor densities.
Good point. Running now gets me a 90 with the webkit nightly, and examining the earlier failure shows at least one test (69) which explicitly states may be a networking issue- something that seems highly likely given how overloaded the acid3 server was earlier in the day.
So I did finally notice. I only managed an 85 on the nightly WebKit that I grabbed, however, leaving me to wonder about the discrepancy there.
Interestingly, I'm not getting an 87 with Safari 3.0.4- I'm getting a 39.
That's actually not true at all- the two capabilities are orthogonal to each other.
Smart Mailboxes are, in effect, saved searches with result sets that are updated in real time. That is, they are automatic sortings based on intrinsic properties of the messages in the account.
Labels, on the other hand, are user-applied attributes of a message rather than something intrinsic. They can therefor be used to create groupings that cannot be automatically created without actual semantic analysis of the content of the message.
They're both very useful, but neither one actually provides the capabilities of the other- and, in fact, they'd work together beautifully. If the search capabilities of smart mailboxes could take labels into account, they could provide much more effective sorting.
That applies only to off-CPU communication, which is not what was originally specified. A long in-cache computation could very easily happen simultaneously on multiple cores at once.
Also, not all architectures require such serialization for memory access anyway.
This is very, very wrong. Data-set partitioning is certainly one way of achieving parallelism in programming, but it is hardly the only way- nor is it applicable to all domains, as many problems have solutions with too many inter-cell data dependencies. In addition, threads provide a wealth of benefits to application developers by allowing multiple unrelated tasks to be performed simultaneously.
There is, and will always be, overhead associated with parallelization. It may sound great to say "oh, we can farm out parts of this data set to other cores!", but that requires a lot of start-up and tear-down synchronization. It's not at all uncommon for overall performance to be improved by doing something *unrelated* at the same time, requiring less synchronization overhead.
Are threads perfect for everything? No. But calling them the second worse thing to happen to computing is, as best, disingenuous.
As you know, multiple threads in a program do not actually execute concurrently - processing is still serial, it's just so fast that threads can appear to execute simultaneously - and it's not just about queuing execution either.
That holds only for multithreaded programming on a single core. As soon as there are multiple cores available, processing does, in fact, happen simultaneously.
You didn't RTFA, did you?
The findings are relevant to silicon precisely because the macro-level tests have *not* shown fatigue cracks. Now, the article suggests that this may be a weakness in the macro-level testing methodology, but it doesn't change the fact that silicon was considered "special" because of it's structure, and now it appears not to be.
So, uh, you've actually got this completely backward. No one thinks it's a new type of stress, it merely wasn't expected that silicon would be susceptible to it.
Ahh... technically speaking, this could be very bad advice in the business arena. While I'm not a lawyer, AFAIK code is copyrighted at the act of creation, and simply by making it available for viewing the author is not automatically giving up those rights. While it is highly unlikely that such a code snippet would cause problems down the road, it is not impossible that it could.
Rewriting simply because it was written external to the company isn't a good thing. Rewriting because it was written external to the company and you're not certain of your company's license to legally make use of the code is an *entirely* different thing.
The author not attaching a particular license to the code is not a blanket license to do with as you will. The author may have intended that, but I don't believe it's true in the legal sense.
It might make more sense to go as you're suggesting, but given the mess that is current copyright law, a business ought to tread more carefully.
The Ratchet and Clank games actually have a pretty good reputation for actually being fun as well. I played the first one on the PS2 and found it thoroughly enjoyable- fun puzzle-platform-action. The high production values really did add to it, as well.
From what I've heard so far, this one's done the same, though I haven't been interested in throwing that much money down the drain to buy a ps3 just yet.
I still wouldn't call someone an idiot for it without knowing more details- especially given that the driver could be completely in control and yet be subsequently hit by another motorist. Or, on a similar note, another motorist with a similar problem passing you in the lane next to you could easily collide with you.
Clearly some of the incidents I mentioned can be recovered from, and my point was not that there's nothing one can do to personally mitigate some risk- it's just that the driver alone does not have 100% control of the risk of operating a motor vehicle.
our personal avoidance ratio clearly hasn't been high
Actually, it's been very high. And yes, certainly it is in part due to my own care in driving. At the same time, I'm at least aware that I'm not 100% in control of the situation, and that no matter the precautions I take at any given time it is entirely possible for the unexpected to occur.
As an aside, yes, I know you think you're clever for trying to be insulting in a patronizing fashion mentioning ineptitude or my presumed avoidance ratio. You're not; it's just symptomatic of the same arrogance that I was originally pointing out.
It takes two idiots to have an accident.
You're living in a fantasy world. It only takes one- and really, it doesn't even take an idiot. Ever had a blowout on the highway? Would you call yourself an idiot if a piece of debris you couldn't see caused one and sent you into a crash? Didn't think so. Doesn't change the good chance of death you have as a result.
Oh, and are you always the driver when you're in a car? Never let anyone else drive? Never taken a taxi, or a shuttle bus of some sort?
The numbers are very simple. Compare the number of plane trips per year and number of plane deaths with the number of car trips per year and the number of car deaths. The plane related incidents are almost statistically unnoticeable in this country. Car crashes, on the other hand, are one of the leading causes of death.
Nothing that goes on in a program is completely transparent, no matter how much people would like to claim it is. Garbage collection has its place. It also has its own set of faults and problems- and it's also not perfect, and it can be a crutch. You can, in a practical sense, leak memory just as easily in a garbage collected system as you can in any other.
Explicit control, reference counting, garbage collection- the important thing with all of them is that you have to understand your memory management model and how it interacts with your application. If you don't, you'll have problems with all three. There is no panacea.
It's a question of the type of memory issues that arise. If you have a minor memory leak in a simple function in the context of a good architecture, both finding and correcting it should be trivial. If you've spent proper time in the architecture to account for memory management, you should have architected in solutions to application-level memory management, leaving only low-level management to be a source of problems- where those problems are not difficult.
Basically, not all memory leaks are created equal. Correct architecture prevents the "hard" classes of memory leaks, leaving the "easy" classes that are really no more difficult to find/fix than anything else.
Or perhaps they're too busy thinking about clearly-defined objects, robust interfaces, clean documentation and the "big picture" then to worry about moving individual bytes around.
Actually, I'd say they're not busy enough- if they actually had been, proper memory management should simply fall into place on top of a clean architecture. If you're trying to shoehorn memory management back into something that didn't support it before, you're going to have issues- and this applies whether you're doing c/c++ style management, reference counting, or garbage collecting.
If a simple majority was sufficient, the measure would have passed.
They hold a majority, it's just a rather slim one- insufficient to override the republican no votes.
Yes, unfortunately iTunes sucks at that. For example, sooner or later, it ends up duplicating songs. And duplicating more songs. And duplicating yet more songs. All of a sudden, when I listen to a CD I have to listen to the same song three times.
I've never noticed that in all the years I've been using it, which is pretty much since it first came out. Any ideas on what causes it? I just strongly wonder if it's the same principle of trying to fight the software.
Linux and MacOS are no different in this regard. In fact, for every one of those Mac apps you like, there is a very similar Linux app--and then some.
I've been using Linux for over ten years now. They are very, very different. There are things for which I love linux for- and I use it on a daily basis, even if much of that is simply for valgrind- but the two operating systems are worlds apart when it comes to getting out of your way and letting you do everyday tasks without having to tinker. It's getting better, but much of the problem is a programmer mindset that is very appropriate when hacking command line tools, building infrastructure-level software, etc- and horribly inappropriate for UI design. I'm sorry, but anyone who claims that the available linux UIs are better than MacOS X for the majority of work is simply deluding themselves- and the moment you claim "but there are 18 million options you can customize to make it exactly how you want it!", you prove my point. Linux (including the applications available to the platform) is software written mostly for programmers, by programmers.
It's not merely the applications. There are certainly some individual applications that are getting there. It's the overal system integration, the seamlessness of the OS itself (counting the windowing system as part, since any user will consider it as such), its management tools- and, more importantly, the lack of a *need* for management tools.
Linux has been getting better, and a lot of very talented, dedicated programmers are doing a lot to improve it. But it's got a long way to go- and frankly, I think any of those talented programmers who looked at it objectively would agree.
I'm not trying to spin anything, and I'm definitely not claiming the software is perfect- or that it can cover every case. For the above, you're completely correct- iTunes insufficiently handles that particular case. I myself have been annoyed on occasion when it places something into the library when I open it, leaving me to promptly delete it after listening since I know I'll not want it in the future.
Your example isn't part of the set I was discussing earlier- you've got a task that iTunes doesn't allow you to accomplish, rather than making it difficult to insert meaningless steps into a task that it does allow you to accomplish.
That's true- but you're not seeing the point. Can I find specific music in a file manager? Sure. Can I find all of the songs with title, artist or album that contain the string foo? No, not really- sure, theres probably a command line tool that will let you look through id3 tags that way, but remember my point- we want to simply accomplish a task, not pat ourselves on the back for doing so in an esoteric fashion. The search box alone is more than a file manager would give me.
The others are the same. Shuffle? Repeat? Smart playlists? Playlist management in general? Two-click burning of a playlist? Not going to find those in a file manager. Sure, you could do them- and yes, I've written my share of scripts to do that sort of thing as well- but if I want to write a script I'll do it for something more interesting than "shuffle".
Geeks, and programmers especially, are very much in the habit of seeing tasks as a sequence of steps to accomplish a goal. The problem is that we often lose sight of the fact that its the goal that's actually important, not the details of the steps we take to get there. iTunes and the like are build for accomplishing goals, not for worrying about steps, and it can be difficult to shift your mindset to that- but it really is a lot easier when you do, and you'll wonder why you didn't sooner.
(Incidentally, the mindset has actually made me a better developer, too.)