In C++, there are better ways to prevent memory leaks than carefully freeing everything in your destructors (which doesn't work anyhow if your constructor throws an an awkward moment).
You accidentally a few words. You might say you accidentally a grammar exception at an awkward moment.
So would the unfortunate people around you who are exposed to your choice in "favorite movies" as they're projected not-so-discreetly onto some convenient surface.
Now, you smile, but he's done a calculation, and if you take all the buildings and make their roofs white and if you make the pavement more of a concrete type of colour rather than a black type of colour, and you do this uniformly . . . it's the equivalent of reducing the carbon emissions due to all the cars on the road for 11 years.
Being mostly a Perl hacker now, I'm as guilty as most in trying to find the perfect regex solution to a blindingly simple problem. It's seductive, it's cool, it's mystical, it's insider cant and sacred dweomer and secret handshake all rolled together.
I have, posted on my cube wall, a particularly good quote from Jamie Zawinski:
Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems.
Well, here's the real problem. You don't know what point anything has in the real world. Never. Particularly, not at the age of 17. But even at the age of 47, or 77. Because the real world changes, and the most interesting changes take directions you can't even fantasize about, let alone accurately predict.
So, to write off any knowledge as irrelevant is short-sighted and foolish. When you ultimately need to know it, you may not have time to learn it.
Exactly! The U.S. economy long ago evolved beyond primitive barter-based economic activity. Now we use an ultra-modern system of representative currency to convey the value of any trading event, such as the purchase of pre-paid judicial support.
Those backwards nations in benighted continents like Europe or Asia have much to learn about high-tech economic optimization, particularly in the realm of influence-peddling.
Brings a tear of pride to this ol' American's eye.
However, we do commend you on your attempts to fight global warming with chilled urine. I bet the brave and thirsty crew of the ISS would appreciate a tall cool glass of recycled whiz. In fact, that'd be #1 on their hit parade!
Personally, I believe the bought Sun just to get control of MySQL so they could kill it, since it was taking sales away from them.
A cogent and insightful theory, except that it's precisely like Mack buying out Segway because it was taking truck sales away from them.* Oracle doesn't have a credible product (or even a foot in the door) in any market where MySQL is already effective.
But this won't be totally effective
For the basic reason I stated above
we need to get all the MySQL users to rally behind one of the forks not controlled by Oracle.
Fair enough; I dislike Oracle's business dealings and basic arrogance enough to get me behind a genuine grassroots fork. But don't succumb to Amiga Persecution Complex. If it happens, the non-Oracle fork's ultimate poor uptake and small community won't be because of some sinister Oracle Trilateral Commission keeping the little guy down; it'll be the little guy just being little.
*I'd like to point out the nifty Slashdot-compliant car analogy. OK, technically, truck analogy.
*Yes, that includes "lose", as in "If you lose your gas cap, that stupid check engine light will come on!"
And every problem is serious... as in, "serious source of revenue at dealership service departments".
Remember, it's not a convenience to you, it's primarily (per the language of the law) to protect the environment from your poorly-tuned smog-spitter, and only slightly less importantly to generate unavoidable trips to the mechanic.
Actually, I was gonna make a joke involving crowbars, but I don't think it would work.
And yeah, I do run CentOS on the household server. I like the RedHat heritage without the RedHat pricetag or the Fedora churn. YMMV. At least I'm qualified to fanboi about CentOS, even if I have enough clue not to.
Scare quotes? Like "he's not really my friend, I'm humoring him until he coverts to Linux."?
"so-called" quotes? Like "He's more than a friend, but I won't come out of the closet for him."?
I don't get it. It's distracting. It reduces whatever value this tutorial may have had. It certainly seems to reinforce the arrogant attitude "You're smart, I don't understand why you aren't doing exactly what I do."
Could I interest you in some 100% oxygen-free virgin-silicon fiber HDMI cables with gold-plated connectors? A bargain at $750 per meter! It'll improve the sound of your iPod to no end! Warmer, richer, more spacial sound from your genuine Apple-brand earbuds!
is engineering a read/write head which is bent at 90 degrees to reality in two distinct and orthogonal directions.
The downside is that a head crash would threaten the integrity of the space-time continuum worse than a Large Hadron Collider mishap and two Star Trek: Voyager episodes all occurring at the same time.
Maybe I'm naive. (OK, not "maybe".) And maybe I'm forgetful. (Well, again, that's more a certainty than a likelihood.)
But this is the first media review I've read here that wasn't poorly-disguised marketing. Unless it's some kind of bizarre, reverse-psychology viral marketing.
In which case it fails, because it doesn't generate enough "rubberneckers-gawking-at-the-freeway-crash" curiosity to make me want to buy the book.
So. A negative book review. What's next, a moratorium on dupes?
Speed can be a contributing cause to a crash. Higher speed reduces effective response time (or, if you wish, increases response distance), meaning a situation which could have been avoided (braking, evasive maneuvers) at a lower speed becomes unavoidable at a higher one. (Of course, arguing about causation can be pointless--after all, there could have been no crash at all if the drivers had chosen not to drive in the first place.)
But true, speed's affect on a crash is to increase the total kinetic energy budget of all impacts involved.
Have you read "Rainbows End," by Vernor Vinge?
I know it's not what you want (reality), it's fiction, but it's got some interesting concepts.
For example, that computer display might as well just be on a contact lens instead on some bulky headset.
Screw contact lenses. If you want an awesome Vernor Vinge innovation in user interfaces, consider the A Deepness in the Sky and its version of localizers: smart dust which can "learn" to directly stimulate a user's optic nerve to create computer graphics within the visual system itself.
Not to nit-pick, but AUTODIN was message-switched. (I worked AUTODIN software in the early '80s.)
The distinction between message-switching and packet-switching is small but crucial. The quantum of messaging in a message-switched network is an entire message. That's why AUTODIN implemented overrides and interrupts, permitting a high-precedence message to override a long lower-precedence message. When that happened, the receiving switch discarded the partly-received lower-precedence message, received and processed the higher-precedence message in its entirety, and then began from octet 0 with the next message on the circuit addressed to it (which may be the message it partially received earlier--but with no persistence, it started from the beginning.)
A packet-switched equivalent would hold the incomplete partial message in core (or disk, I suppose) and receive the packets of the higher-precedence message, assemble that message and process that message, and then continue processing the delayed (not interrupted) remainder of the lower-precedence message.
Packet switching was, in its time, radical. It allowed organic solutions to problems like precedence-based circuit management in less wasteful ways than message switching. It was also sufficiently different from message-switching in behavior that the software for packet-switching had to be written pretty much from scratch, or bought from a vendor if you were lucky.
That's the voice of experience speaking: our team wrote a very primitive TCP/IP stack for our Unisys 1100 mainframe, and never shook all the bugs out of it (mostly timing bugs, since realtime interrupt handling on the comm circuits were always a nightmare of race conditions.) We were never so glad when Unisys started offering off-the-shelf LAN hardware and TCP/IP software for those machines, and we could stop wrestling with our own ugly Frankenstein monster.
Slashdot Mirror
In C++, there are better ways to prevent memory leaks than carefully freeing everything in your destructors (which doesn't work anyhow if your constructor throws an an awkward moment).
You accidentally a few words. You might say you accidentally a grammar exception at an awkward moment.
In fact, the modem in the video predates the AT command set by 14 years.
"The Unexpected Pants of Steve Jobs"
Like he inadvertently wore Hawaiian-print Bermuda shorts with his mock turtleneck.
The weird thing is that we'd probably never notice, with the RDF making us see what we expect.
So would the unfortunate people around you who are exposed to your choice in "favorite movies" as they're projected not-so-discreetly onto some convenient surface.
You sick, sick person.
Now all we need is white tar...
Exactly.
Being mostly a Perl hacker now, I'm as guilty as most in trying to find the perfect regex solution to a blindingly simple problem. It's seductive, it's cool, it's mystical, it's insider cant and sacred dweomer and secret handshake all rolled together.
I have, posted on my cube wall, a particularly good quote from Jamie Zawinski:
Well, here's the real problem. You don't know what point anything has in the real world. Never. Particularly, not at the age of 17. But even at the age of 47, or 77. Because the real world changes, and the most interesting changes take directions you can't even fantasize about, let alone accurately predict.
So, to write off any knowledge as irrelevant is short-sighted and foolish. When you ultimately need to know it, you may not have time to learn it.
Learn everything. There's no good excuse not to.
+1 Voice of Bitter Experience
Exactly! The U.S. economy long ago evolved beyond primitive barter-based economic activity. Now we use an ultra-modern system of representative currency to convey the value of any trading event, such as the purchase of pre-paid judicial support.
Those backwards nations in benighted continents like Europe or Asia have much to learn about high-tech economic optimization, particularly in the realm of influence-peddling.
Brings a tear of pride to this ol' American's eye.
FIRST POST! Frosty piss too.
Fail post!
However, we do commend you on your attempts to fight global warming with chilled urine. I bet the brave and thirsty crew of the ISS would appreciate a tall cool glass of recycled whiz. In fact, that'd be #1 on their hit parade!
Well, I did say "credible". If MySQL is a Segway, Oracle Express is a tricycle. (Not the cool kind, or even the useful kind. The pre-school kind.)
Justferinstance, if you need over 4Gb of tablespace in MySQL, it's just a couple of
statements away. If you need over 4Gb of tablespace in OE... your Oracle account exec will be happy to help you. Bring your wallet.
Personally, I believe the bought Sun just to get control of MySQL so they could kill it, since it was taking sales away from them.
A cogent and insightful theory, except that it's precisely like Mack buying out Segway because it was taking truck sales away from them.* Oracle doesn't have a credible product (or even a foot in the door) in any market where MySQL is already effective.
But this won't be totally effective
For the basic reason I stated above
we need to get all the MySQL users to rally behind one of the forks not controlled by Oracle.
Fair enough; I dislike Oracle's business dealings and basic arrogance enough to get me behind a genuine grassroots fork. But don't succumb to Amiga Persecution Complex. If it happens, the non-Oracle fork's ultimate poor uptake and small community won't be because of some sinister Oracle Trilateral Commission keeping the little guy down; it'll be the little guy just being little.
*I'd like to point out the nifty Slashdot-compliant car analogy. OK, technically, truck analogy.
Hey, a loose* gas cap is srs bzns!
*Yes, that includes "lose", as in "If you lose your gas cap, that stupid check engine light will come on!"
And every problem is serious... as in, "serious source of revenue at dealership service departments".
Remember, it's not a convenience to you, it's primarily (per the language of the law) to protect the environment from your poorly-tuned smog-spitter, and only slightly less importantly to generate unavoidable trips to the mechanic.
trying to separate CentOS from RedHat.
OMG how dare you! They are completely different.
Actually, I was gonna make a joke involving crowbars, but I don't think it would work.
And yeah, I do run CentOS on the household server. I like the RedHat heritage without the RedHat pricetag or the Fedora churn. YMMV. At least I'm qualified to fanboi about CentOS, even if I have enough clue not to.
In the fine summary, I mean.
Scare quotes? Like "he's not really my friend, I'm humoring him until he coverts to Linux."?
"so-called" quotes? Like "He's more than a friend, but I won't come out of the closet for him."?
I don't get it. It's distracting. It reduces whatever value this tutorial may have had. It certainly seems to reinforce the arrogant attitude "You're smart, I don't understand why you aren't doing exactly what I do."
Obvious crap is obviously highly moderated. Welcome to /.
Could I interest you in some 100% oxygen-free virgin-silicon fiber HDMI cables with gold-plated connectors? A bargain at $750 per meter! It'll improve the sound of your iPod to no end! Warmer, richer, more spacial sound from your genuine Apple-brand earbuds!
is engineering a read/write head which is bent at 90 degrees to reality in two distinct and orthogonal directions.
The downside is that a head crash would threaten the integrity of the space-time continuum worse than a Large Hadron Collider mishap and two Star Trek: Voyager episodes all occurring at the same time.
Maybe I'm naive. (OK, not "maybe".) And maybe I'm forgetful. (Well, again, that's more a certainty than a likelihood.)
But this is the first media review I've read here that wasn't poorly-disguised marketing. Unless it's some kind of bizarre, reverse-psychology viral marketing.
In which case it fails, because it doesn't generate enough "rubberneckers-gawking-at-the-freeway-crash" curiosity to make me want to buy the book.
So. A negative book review. What's next, a moratorium on dupes?
They've invented the governor. Except it's a less reliable, more expensive bolt-on which misapplies GPS technology instead of using existing, trusted, and well-understood speed measurement instrumentation already installed in the vehicle.
Bravo.
Speed can be a contributing cause to a crash. Higher speed reduces effective response time (or, if you wish, increases response distance), meaning a situation which could have been avoided (braking, evasive maneuvers) at a lower speed becomes unavoidable at a higher one. (Of course, arguing about causation can be pointless--after all, there could have been no crash at all if the drivers had chosen not to drive in the first place.)
But true, speed's affect on a crash is to increase the total kinetic energy budget of all impacts involved.
Irony: Wikipedia calling your information service non-authoritative.
Have you read "Rainbows End," by Vernor Vinge?
I know it's not what you want (reality), it's fiction, but it's got some interesting concepts.
For example, that computer display might as well just be on a contact lens instead on some bulky headset.
Screw contact lenses. If you want an awesome Vernor Vinge innovation in user interfaces, consider the A Deepness in the Sky and its version of localizers: smart dust which can "learn" to directly stimulate a user's optic nerve to create computer graphics within the visual system itself.
Not to nit-pick, but AUTODIN was message-switched. (I worked AUTODIN software in the early '80s.)
The distinction between message-switching and packet-switching is small but crucial. The quantum of messaging in a message-switched network is an entire message. That's why AUTODIN implemented overrides and interrupts, permitting a high-precedence message to override a long lower-precedence message. When that happened, the receiving switch discarded the partly-received lower-precedence message, received and processed the higher-precedence message in its entirety, and then began from octet 0 with the next message on the circuit addressed to it (which may be the message it partially received earlier--but with no persistence, it started from the beginning.)
A packet-switched equivalent would hold the incomplete partial message in core (or disk, I suppose) and receive the packets of the higher-precedence message, assemble that message and process that message, and then continue processing the delayed (not interrupted) remainder of the lower-precedence message.
Packet switching was, in its time, radical. It allowed organic solutions to problems like precedence-based circuit management in less wasteful ways than message switching. It was also sufficiently different from message-switching in behavior that the software for packet-switching had to be written pretty much from scratch, or bought from a vendor if you were lucky.
That's the voice of experience speaking: our team wrote a very primitive TCP/IP stack for our Unisys 1100 mainframe, and never shook all the bugs out of it (mostly timing bugs, since realtime interrupt handling on the comm circuits were always a nightmare of race conditions.) We were never so glad when Unisys started offering off-the-shelf LAN hardware and TCP/IP software for those machines, and we could stop wrestling with our own ugly Frankenstein monster.
xkcd agrees. At least, in its more lucid moments.