Settle down there. Its a matter of personal preference. I'll grant that Quarantine is probably one of Egan's easiest reads, since its essentially formatted as a noir dectective novel, but I don't think its neccessarily his best work. I'd personally say that I think Diaspora or Teranesia are better novels for interesting new ideas.
Re:Answer to title. (Actual experience)
on
Is Mac OS X Slow?
·
· Score: 2
Bzzt, sorry, thank you for playing, but that's not what I meant at all. By turn off all the crap I mean the flashy chrome attached to the UI in XP. Yes I know that you can switch to the command line or X11 in OS X, but I still want GUI navigation through files. I want the finder, I just don't want it to be slow.
Re:Answer to title. (Actual experience)
on
Is Mac OS X Slow?
·
· Score: 5, Informative
I love this technical discussion of why the Mac is considered to be slow but actually isn't. The asker is probably not as interested in a detailed technical minutae as the user experience.
I'm a professional software developer that had to port a large body of code from Windows to Mac. I've also done a signifigant amount of work on *nixes. The Finder interface in 10.0 and 10.1 is unbearably slow. I haven't had enough experience with 10.2 yet to make a call. The problem seems to be twofold, poor UI, and poor implementation.
You have to understand where I'm coming from. I'm no fan of Microsoft's practices or the stability or security of their code. And I am a big fan of OS X technology. A (mostly) user friendly operating system backended to a unix system, with all the unix tools and features I love. Plus I'm not railing on the hardware architecture or the OS core. Codewarrior on OS X beats the pants off Visual Studio on Windows in just about every category. But OS X's Finder, its front door as it were to someone like me, has some serious lacks.
I'm pretty fast in Windows explorer, I have to be navigating between hundreds of source files. I've learned just about all the shortcut keys and my hands move to wherever is fastest to accomplish a given task, mouse or keyboard. When I started working on the mac I was frustrated by the amount of mouse effort I had to expend. If my hands are on the keyboard and I need to do some UI navigation I don't want to have to use the mouse. I call that poor UI. I know there are probably keys there I don't know about, but they certainly aren't readily apparent in the help files. The tab between controls functionality windows has seems to be largely missing. I'm not incapable of learning new shortcut commands, I just need to be able to find out what they are without installing 4 third party applications that add them.
The seoncd part is that the finder is just damn slow. I don't care that its shiny and round and scales perfectly. I have a ~500Mhz G4 and thats more than enough power to make sure that simple tasks like moving files around and editing source code should never EVER have a perceptible delay. Sure, maybe Windows XP might be slow on an equivalently powered PC, but you know what? I can turn off all the UI crap that comes with XP. Not so with OS X. Its about as customizable as your grandmothers sofa, the one with the plastic covering you're not allowed to sit on.
At the risk of going (further) off-topic, I was not attempting to evaluate the moral stance of my own government. I personally do not support war war in Iraq and am not a fan of my president. I was merely trying to draw a parallel between what I perceieve as two evils.
It makes me wonder exactly what kind of mindset it take to stand there and lie like that. Is it self-delusion, or are they standing there with the proverbial smoking gun in their hand and a stupid smirk on their face saying 'What violations?' because they know the opposition is too much of a pussy to punch them in the face when they deny it.
"Someone needs to take them back to court for this.."
Microsoft and Iraq remind me of each other in this respect. They steadfastly adhere to bullshit stories while the opposition builds up a big head of steam, and they only budge from their bullshit stories for as long as it takes for the danger to avert, then they close the source/kick out the inspectors again. Playing fair with organizations that don't sucks.
Posting ciphertext and plaintext and inviting people to attack it should keep the encryption method safe if it's as secure as he thinks it is. If some reverse engineers the algorithm (or an equivalent) it will show it wasn't worth patenting in the first place (or that it's already been patented).
This is bullshit. No serious cryptographer is going to try to attack an arbitrary sample of encryption, even with plaintext, without a description of the algorithm. The algorithm should never be considered part of the secret, it should be as public as possible. Why would anyone waste their time on trying to figure out what kind of bit-twiddling is being done when that's not actually the core of the security. Read Applied Cryptography and get over it.
If you've gotten the bounces but not angry replies, then you're not in the from address of the message. Bounces go to whoever is specified as sending the message in the SMTP protocol, which doesn't examine the header, but uses the MAIL FROM and RCPT TO commands to determine source and destination.
I know this because I wrote a 'mass-emailing' engine for Disney that allowed them to improve the scale, frequency and level of customization of their 'subscription' mailing lists.
That's the perihelion distance, which is the closest it gets to the SUN, not to the earth. Closest approach to earth will probably be quite a lot less than 6 light minutes if anyone has cause to be concerned.
What's a better scale is the Torino scale, which is basically an impact threat scale, from 0 to 10, with 10 meaning a very destructive impact will happen very soon. This rock as a Torino rating of 1, so I daresay there's nothing to worry about
I daresay a Torino rating of 0 is 'nothing to worry about' and 1 is 'lets keep a really close eye on this one'.
Specifically I'm talking about the Australian govt who a while back cut all funds to asteroid search programs, virtually leaving the entire southern hemisphere unchecked for such potential threats.
Actually, I believe that most asteroid threats lie in the plane of the eccliptic, which means you see them coming from pretty much anywhere on the planet.
Anything NOT coming from the plane of the eccliptic is probably interstellar and thus likely moving WAY too fast to get to and divert without some major advances in technology.
>Second, there should be no surprise... COFFEE IS FUCKING HOT. Suprise, you're an idiot.
To each and every one of you morons who claim 'Coffee is hot, get over it', I award one styrofoam container of coffe plasma, server at 2000 degrees c. Hot coffee does not have to be dangerous coffee.
If its really holographic storage, depending on how its implemented, it will be much more resitant to scratches than typical CD's or DVD's. Every part of a hologram contains a bit of the whole. If you shatter a hologram of a rose, you don't get lots of little parts of the rose. You get lots of little holograms of the whole original picture, each less distinct and clear than the original.
Combined with digital error recovery this could make the media very resiliant.
He believes that the falling of a raindrop is of equal complexity as the behavior of gases in a nebula - a single equation can predict both.
And currently to the best of our knowledge, its only 4 forces and their interactions that govern both, and everything else in the universe. And much work goes into showing that these are merely different aspects of the same force.
Maybe it can't be proven, per se, but nothing scientific can be. All scientific theories are that - just theories. None of it should be dogma, for that would violate the principles of science.
But by the same token, dismissing the value of well established theories leads you down a pointless road. Why believe anything, if you can't really trust in its validity.
The STL makes no guarantees that it checks for errors (bounds checking,
Vectors are the only place you have bounds checking issues. vector::operator[] does not provide bounds checking. vector::at() does. That's the only difference. So you're dead wrong here. Its also very sad that no one else defending the STL has managed to point this out, demonstrating that even among its proponents, few really delve deep into the functionality to find what they want.
using a pointer into the wrong collection
I'm not sure what you mean here. First off, you should use iterators, not pointers, when dealing with the STL.
It's hard to predict whether any particular data structure or algorithm is going to be fast. Sure, it makes asymptotic guarantees, but everybody does that; it's the constants that matter.
And this is specific to STL as opposed to other libraries how? I mean except that the STL guarantees are WELL documented, and that anyone using the STL regularly should essentially know them well, and thus can be interchanged with anyone else who knows the STL well, leading to greater code maintainability.
I just inherited a Bluetooth financial transaction system project and was wondering what freely available STL I should use? Thanks
STLPort seems to be widely regarded as the best free implementation. My company uses dinkum STL, which is not free, but available for several platforms.
Since string has methods for several diffent uses, it is unlikely you actually need everything that it implements, and creating a new class with that broad set of functionality (via inheritence) is bad programming practice because you have given your class more functionality than it needs.
String in itself has more functionality than most people need. Most of the STL containers do for that matter. Part of the advantage to the STL is that as templates, only the parts you actually use are compiled into the program. If your derivation is in turn a template class as well, you retain this advantage. And even if your derived class is a specific type instance, the linker will remove uneeded code. If you argument applies not to code generation, but just the amount of functionality in the class, your complaint could just as easily be leveled against the whole of STL.
As a good example, suppose your are migrating away from a custom string class, or something like MFC's CString. You can derive from std::string, and then implement compatibility functions as needed, expressing them in terms of the native std::string. This is an excellent first step in migrating away from even the usage of the non-standard functions, since you can now do that incrementally.
Your example of list vs. vector is specious, because where functionality between the two overlaps, there are vastly different requirements in behaviour concerning speed of operations. If that is the case, then yes, you're better off implemnting a new class (or deriving from or containing an instance of the correct STL class).
I grant you that the need for derivation is rare, and most places where it would be used could be as easily accomplished with generic functions that operate on your data structure instead of being a member of your derived class, but there are times when it is more effective to derive.
Brad
Using STL may affect your portability, especially in the embedded systems arena.
That's the stupidest thing I've heard all day. You switched from std::string to the MFC CString and you say that STL isn't portable? You don't need MFC's handholding. You go out and find one of the many copies of the STL that's freely available out there and you compile it yourself. You don't switch to something thats even LESS portable.
Having additional classes only uses more memory at compile time. It makes absolutely no difference at runtime. The executable size increases only because of debug information. Stripping out the debug info will dramatically reduce executable size
Sorry, no. If you're working with multiple DLL's and you access a std::list declared in some header from both of them, functions that you call in both DLL's will be located in both DLL's Thus code bloat. For a monolithic application, you are correct.
YOU SHOULD NEVER INHERENT FROM AN STL CONTAINER. Period. There is no good reason to do this. If your design calls for it, then you have a bad design. Besides, STL containers do not have to have virtual destructors so you are introducing potential memory leaks if you inherent from them (this was made part of the standard on purpose).
That's a pretty broad statement, and again I disagree. Suposing you want to create a string class with a subset of the functionality in std::string? Do you re-implement it? Supposing you want to create a structure that is best expressed as a list, but has just a little more functionality? Granted, you have to keep a pointer to the derived class, because of the virtual dtor issue, but its not completely unheard of.
Read the Science Magazine paper. This isn't crackpot science. They may be wrong, but they're not falling victim to your list of red flags. As far as I can tell they get a score of -5, based on what was published by the original authors.
I'm concerned that it hasn't been duplicated yet, but hopeful.
We could always just make the string self buoyant (fill air sacks within it with helium or hydrogen).
That only works as far as the string is in atmosphere, a very small percentage of the total length. Buoyancy depends on heavier material surrounding the buoyant object. That's why ocean liners don't fall to the bottom of the ocean, but then again, neither do they hover in the air. Once you're in space, all you've got it gravity.
But why not have a rocket take off that drags a string behind it? And, say, take the string to the moon.
I'm not positive, but I'm pretty sure that no material has the tensile strength to hold its own weight all the way to the moon. If you held a 5 foot string, it weighs practically nothing. If you dug a 100 mile hold and held a 100 mile string that was dangling down it it would rip your arm off. If you suspended it from something stronger than you, the string would just break under its own weight.
Plus you can't anchor a string to the earth and the moon. The earth rotates much faster than the moon orbits. If you attached it to just the earth it would only line up with the moon once a day, and it would be going so fast as it passed it you would be smashed into the moon. By the same token if you attached it to the moon, it would fly around the earth every 24 hours, meaning it would be blazingly fast, about 350 mph. Bad rope burn if you try to grab it.
However, it might be possible to build a 'string' that is strong enough to simply lead into orbit. Anchor one end to the earth, and the other to a large mass slightly outside geosync orbit, which is still way way closer than the moon. Then you can climb the string all the way to the mass and be flung away from the earth. At any rate we still don't have strong enough string. Yet.
Lots of reasons. First problem is to keep the ISS from being flung in the opposite direction of the direction of the launch. You could possibly solve that one by making each launch fire the actual launch vehicle and a waste mass in the opposite direction to conserve momentum, but then you double the power requirements and the mass you have to get into orbit.
The next problem is that because of tidal forces any long linear object in orbit will be pulled into an orientation where the long axis of the station is pointed directly at the earth. The center of mass of any object in orbit at orbital speed, but anything closer to the earth is moving slower than orbital speed (because speed to maintain orbit gets faster the closer you get to the center of the earth, but the whole object can only go at a fixed speed) and anything further away from the center of mass of the station is moving faster than orbital velocity.
At any rate, if you've got a long structure in orbit, one end will point at the earth, the other directly away. The amount of energy required to point the launcher anywhere remotely useful would probably be better spent attached to the object you want to launch in the first place.
Believe me, contextual menus and keyboard shortcuts are almost totally irrelevant.
I knew someone was going to say this.
They're NOT irrelevant if I want to use them. I don't care if you don't like using keyboard shortcuts. You don't have to. But If I want to use them and they're not there, if there's not way for me to navigate and perform actions without touching the mouse on the Mac and I can on Windows, then that is a deficiency.
I don't know what your line of work is, but I'm a software developer and keyboard shortcuts are my bread and butter for a smooth working environment. I spend most of my time editing text and not even touching the mouse. Keyboard shortcuts make my life easier and improve my efficiency, as they would for many users who spend most of their time on the keyboard and not the mouse.
Slashdot Mirror
Settle down there. Its a matter of personal preference. I'll grant that Quarantine is probably one of Egan's easiest reads, since its essentially formatted as a noir dectective novel, but I don't think its neccessarily his best work. I'd personally say that I think Diaspora or Teranesia are better novels for interesting new ideas.
Bzzt, sorry, thank you for playing, but that's not what I meant at all. By turn off all the crap I mean the flashy chrome attached to the UI in XP. Yes I know that you can switch to the command line or X11 in OS X, but I still want GUI navigation through files. I want the finder, I just don't want it to be slow.
I'm a professional software developer that had to port a large body of code from Windows to Mac. I've also done a signifigant amount of work on *nixes. The Finder interface in 10.0 and 10.1 is unbearably slow. I haven't had enough experience with 10.2 yet to make a call. The problem seems to be twofold, poor UI, and poor implementation.
You have to understand where I'm coming from. I'm no fan of Microsoft's practices or the stability or security of their code. And I am a big fan of OS X technology. A (mostly) user friendly operating system backended to a unix system, with all the unix tools and features I love. Plus I'm not railing on the hardware architecture or the OS core. Codewarrior on OS X beats the pants off Visual Studio on Windows in just about every category. But OS X's Finder, its front door as it were to someone like me, has some serious lacks.
I'm pretty fast in Windows explorer, I have to be navigating between hundreds of source files. I've learned just about all the shortcut keys and my hands move to wherever is fastest to accomplish a given task, mouse or keyboard. When I started working on the mac I was frustrated by the amount of mouse effort I had to expend. If my hands are on the keyboard and I need to do some UI navigation I don't want to have to use the mouse. I call that poor UI. I know there are probably keys there I don't know about, but they certainly aren't readily apparent in the help files. The tab between controls functionality windows has seems to be largely missing. I'm not incapable of learning new shortcut commands, I just need to be able to find out what they are without installing 4 third party applications that add them.
The seoncd part is that the finder is just damn slow. I don't care that its shiny and round and scales perfectly. I have a ~500Mhz G4 and thats more than enough power to make sure that simple tasks like moving files around and editing source code should never EVER have a perceptible delay. Sure, maybe Windows XP might be slow on an equivalently powered PC, but you know what? I can turn off all the UI crap that comes with XP. Not so with OS X. Its about as customizable as your grandmothers sofa, the one with the plastic covering you're not allowed to sit on.
At the risk of going (further) off-topic, I was not attempting to evaluate the moral stance of my own government. I personally do not support war war in Iraq and am not a fan of my president. I was merely trying to draw a parallel between what I perceieve as two evils.
It makes me wonder exactly what kind of mindset it take to stand there and lie like that. Is it self-delusion, or are they standing there with the proverbial smoking gun in their hand and a stupid smirk on their face saying 'What violations?' because they know the opposition is too much of a pussy to punch them in the face when they deny it.
Microsoft and Iraq remind me of each other in this respect. They steadfastly adhere to bullshit stories while the opposition builds up a big head of steam, and they only budge from their bullshit stories for as long as it takes for the danger to avert, then they close the source/kick out the inspectors again. Playing fair with organizations that don't sucks.
This is bullshit. No serious cryptographer is going to try to attack an arbitrary sample of encryption, even with plaintext, without a description of the algorithm. The algorithm should never be considered part of the secret, it should be as public as possible. Why would anyone waste their time on trying to figure out what kind of bit-twiddling is being done when that's not actually the core of the security. Read Applied Cryptography and get over it.
You do if you don't want to wonder if they're only interested in you for the money.
I know this because I wrote a 'mass-emailing' engine for Disney that allowed them to improve the scale, frequency and level of customization of their 'subscription' mailing lists.
Yes, I built a bomb once.
That's the perihelion distance, which is the closest it gets to the SUN, not to the earth. Closest approach to earth will probably be quite a lot less than 6 light minutes if anyone has cause to be concerned.
I daresay a Torino rating of 0 is 'nothing to worry about' and 1 is 'lets keep a really close eye on this one'.
Actually, I believe that most asteroid threats lie in the plane of the eccliptic, which means you see them coming from pretty much anywhere on the planet.
Anything NOT coming from the plane of the eccliptic is probably interstellar and thus likely moving WAY too fast to get to and divert without some major advances in technology.
>Second, there should be no surprise... COFFEE IS FUCKING HOT. Suprise, you're an idiot.
To each and every one of you morons who claim 'Coffee is hot, get over it', I award one styrofoam container of coffe plasma, server at 2000 degrees c. Hot coffee does not have to be dangerous coffee.
Brad
If its really holographic storage, depending on how its implemented, it will be much more resitant to scratches than typical CD's or DVD's. Every part of a hologram contains a bit of the whole. If you shatter a hologram of a rose, you don't get lots of little parts of the rose. You get lots of little holograms of the whole original picture, each less distinct and clear than the original. Combined with digital error recovery this could make the media very resiliant.
And currently to the best of our knowledge, its only 4 forces and their interactions that govern both, and everything else in the universe. And much work goes into showing that these are merely different aspects of the same force.
Maybe it can't be proven, per se, but nothing scientific can be. All scientific theories are that - just theories. None of it should be dogma, for that would violate the principles of science.
But by the same token, dismissing the value of well established theories leads you down a pointless road. Why believe anything, if you can't really trust in its validity.
Jesus tapdancing christ! vector HAS optional bounds checking. Use the at() function instead of the [] operator.
Vectors are the only place you have bounds checking issues. vector::operator[] does not provide bounds checking. vector::at() does. That's the only difference. So you're dead wrong here. Its also very sad that no one else defending the STL has managed to point this out, demonstrating that even among its proponents, few really delve deep into the functionality to find what they want.
using a pointer into the wrong collection
I'm not sure what you mean here. First off, you should use iterators, not pointers, when dealing with the STL.
It's hard to predict whether any particular data structure or algorithm is going to be fast. Sure, it makes asymptotic guarantees, but everybody does that; it's the constants that matter.
And this is specific to STL as opposed to other libraries how? I mean except that the STL guarantees are WELL documented, and that anyone using the STL regularly should essentially know them well, and thus can be interchanged with anyone else who knows the STL well, leading to greater code maintainability.
STLPort seems to be widely regarded as the best free implementation. My company uses dinkum STL, which is not free, but available for several platforms.
String in itself has more functionality than most people need. Most of the STL containers do for that matter. Part of the advantage to the STL is that as templates, only the parts you actually use are compiled into the program. If your derivation is in turn a template class as well, you retain this advantage. And even if your derived class is a specific type instance, the linker will remove uneeded code. If you argument applies not to code generation, but just the amount of functionality in the class, your complaint could just as easily be leveled against the whole of STL.
As a good example, suppose your are migrating away from a custom string class, or something like MFC's CString. You can derive from std::string, and then implement compatibility functions as needed, expressing them in terms of the native std::string. This is an excellent first step in migrating away from even the usage of the non-standard functions, since you can now do that incrementally.
Your example of list vs. vector is specious, because where functionality between the two overlaps, there are vastly different requirements in behaviour concerning speed of operations. If that is the case, then yes, you're better off implemnting a new class (or deriving from or containing an instance of the correct STL class).
I grant you that the need for derivation is rare, and most places where it would be used could be as easily accomplished with generic functions that operate on your data structure instead of being a member of your derived class, but there are times when it is more effective to derive. Brad
That's the stupidest thing I've heard all day. You switched from std::string to the MFC CString and you say that STL isn't portable? You don't need MFC's handholding. You go out and find one of the many copies of the STL that's freely available out there and you compile it yourself. You don't switch to something thats even LESS portable.
Sorry, no. If you're working with multiple DLL's and you access a std::list declared in some header from both of them, functions that you call in both DLL's will be located in both DLL's Thus code bloat. For a monolithic application, you are correct.
YOU SHOULD NEVER INHERENT FROM AN STL CONTAINER. Period. There is no good reason to do this. If your design calls for it, then you have a bad design. Besides, STL containers do not have to have virtual destructors so you are introducing potential memory leaks if you inherent from them (this was made part of the standard on purpose).
That's a pretty broad statement, and again I disagree. Suposing you want to create a string class with a subset of the functionality in std::string? Do you re-implement it? Supposing you want to create a structure that is best expressed as a list, but has just a little more functionality? Granted, you have to keep a pointer to the derived class, because of the virtual dtor issue, but its not completely unheard of.
I'm concerned that it hasn't been duplicated yet, but hopeful.
That only works as far as the string is in atmosphere, a very small percentage of the total length. Buoyancy depends on heavier material surrounding the buoyant object. That's why ocean liners don't fall to the bottom of the ocean, but then again, neither do they hover in the air. Once you're in space, all you've got it gravity.
I'm not positive, but I'm pretty sure that no material has the tensile strength to hold its own weight all the way to the moon. If you held a 5 foot string, it weighs practically nothing. If you dug a 100 mile hold and held a 100 mile string that was dangling down it it would rip your arm off. If you suspended it from something stronger than you, the string would just break under its own weight.
Plus you can't anchor a string to the earth and the moon. The earth rotates much faster than the moon orbits. If you attached it to just the earth it would only line up with the moon once a day, and it would be going so fast as it passed it you would be smashed into the moon. By the same token if you attached it to the moon, it would fly around the earth every 24 hours, meaning it would be blazingly fast, about 350 mph. Bad rope burn if you try to grab it.
However, it might be possible to build a 'string' that is strong enough to simply lead into orbit. Anchor one end to the earth, and the other to a large mass slightly outside geosync orbit, which is still way way closer than the moon. Then you can climb the string all the way to the mass and be flung away from the earth. At any rate we still don't have strong enough string. Yet.
Lots of reasons. First problem is to keep the ISS from being flung in the opposite direction of the direction of the launch. You could possibly solve that one by making each launch fire the actual launch vehicle and a waste mass in the opposite direction to conserve momentum, but then you double the power requirements and the mass you have to get into orbit.
The next problem is that because of tidal forces any long linear object in orbit will be pulled into an orientation where the long axis of the station is pointed directly at the earth. The center of mass of any object in orbit at orbital speed, but anything closer to the earth is moving slower than orbital speed (because speed to maintain orbit gets faster the closer you get to the center of the earth, but the whole object can only go at a fixed speed) and anything further away from the center of mass of the station is moving faster than orbital velocity.
At any rate, if you've got a long structure in orbit, one end will point at the earth, the other directly away. The amount of energy required to point the launcher anywhere remotely useful would probably be better spent attached to the object you want to launch in the first place.
I knew someone was going to say this.
They're NOT irrelevant if I want to use them. I don't care if you don't like using keyboard shortcuts. You don't have to. But If I want to use them and they're not there, if there's not way for me to navigate and perform actions without touching the mouse on the Mac and I can on Windows, then that is a deficiency.
I don't know what your line of work is, but I'm a software developer and keyboard shortcuts are my bread and butter for a smooth working environment. I spend most of my time editing text and not even touching the mouse. Keyboard shortcuts make my life easier and improve my efficiency, as they would for many users who spend most of their time on the keyboard and not the mouse.
Brad