There's no need for any of this monkey business. Just drink
good espresso.
Let me be blunt: If you aren't drinking espresso -- good
espresso -- you haven't tasted coffee. And I mean
espresso, not cappuccino, not latte, not
frapparichinomochalaloopy. That's the kind of stuff you make when you
want to cover up the taste of bad espresso.
Good espresso is nothing
like the over-roasted, over-extracted, bitter and charred-tasting stuff
you've had when you finally worked up the courage to try an
``espresso'' at *$s or some other gourmet coffee chain. If you're lucky,
they gave you 3 or 4 ounces of unspeakably bitter drek. If you
weren't lucky,... Well, I'm just thankful that
you're still with us.
Good espresso is like heaven in a cup. Deep, rich, dark, and luxurious,
good espresso has no bitterness. Its potent perfume only hints at the
depth of complexity that awaits you upon the first sip. Creamy, caramelly,
exploding with flavor, with a touch of sweetness on the tongue: This
is what good espresso tastes like. No need to add sugar, the real
stuff is quaffed straight.
Oh, and does espresso help your coding? You betcha! Nothing
cuts through code fog like a double ristretto. Fires up
the brain into smooth working condition. Clarity? You own
clarity. With espresso cup in hand, ease in to the Captain's Chair: You are in command.
Face it, you need the real stuff. Here's how to get it:
Stop buying stale coffee at stores and ``gourmet'' shops.
Get an old hot-air popcorn popper and start homeroasting.
It's cheap, it's easy, and it's so worth it. You won't
believe how much better truly fresh coffee tastes. If you go no
farther than this and get a french press and a cheap grinder, you'll
have better coffee at home than you'll be able to find anywhere else.
Get a decent espresso machine. No steam toys. Read the
user-contributed reviews on www.coffeekid.com. Plan on
spending at least 250 USD for a decent machine. Spend the money:
you'll pay for it in under a year from your coffee-chain savings.
Get a good grinder. You can't make real espresso without
one. This is the one that people skimp on and later wonder why their
fancy 1000-USD espresso machine can't make good espresso. Plan on
another 200 USD, minimum. Again, it pays for itself.
Lurk in alt.coffee
and drink in the wisdom. Learn how to pull a ristretto that extracts the deep, beautiful essence of
15g of freshly ground, freshly roasted coffee into 1.75ounces
of pure bliss. Once you've had a "god shot", you'll never be able to go back to bad coffee again.
Do it. It will change your life.
P.S. Here's a good starting roast/blend for espresso: 2 parts
brazillian cerrado, 1 part sumatra mandheling, 1/2 part monsooned
malabar, 1/2 part monsooned cherry aa robusta. Roast each part
individually, just a bit into the second crack. Blend and store in an
airtight glass container. The next morning, open the container
and try to contain your amazement at how great the stuff is.
In any case, your whole argument goes out the window if they state in the terms that come inside the Tivo packaging that they reserve the right to change the software on the box.
Companies can print whatever they want inside the packaging, but if it ain't legal, it ain't legal. If the packaging claimed that the manufacturer "reserved the right" to take stuff from my house, would that legitimize stealing?
Compainies do this kind of thing because many people are sheep and will actually fall for bogus claims of "reserved rights" and disclaimers for things that can't legally be disclaimed. The people who belive this garbage are throwing away their rights by being dumb enough to believe that those rights don't exist, simply because A Big Corporation told them so.
personally python annoys me but that's just cuz' the whitespace-as-block-delimiter thing rubs me the wrong way, code just don't look right unless it's got curly braces (this is the same reason haskell and lisp and scheme annoy me...
Now, hold on there a second, pally. With Haskell, you can have it either way -- braces or whitespace -- or both. If you don't like the whitespace blocks, don't use 'em.
... oh wait, they also annoy me becuase they're functional languages, but that's another 20KB rant in of it's own right).
Well, Haskell is pure functional. Got me there. [With hand-waving motion.] Did I mention that you can use whitespace or braces to delimit blocks?;-)
Since qmail has already had one exploit in its history...
What exploit are you referring to? To my knowledge there has never been a remote-root exploit for qmail (and securityfocus doesn't show anything like it, either). The closest "exploit" has been a denial-of-service attack that was based on overly-long RCPTs in SMTP handshakes. This never compromised the security of the host but only caused qmail to stop responding to SMTP requests.
Contrast qmail's security history -- with only one, non-compromising DoS vulnerablity -- to sendmail's -- chock full o' root holes -- and you'll see that there is no comparison between the two.
... why should we believe that the rest of DJB's software is any more secure?
Don't trust anybody's reputation. Read the code. Compare qmail's code to sendmail's. Compare djbdns's code to BIND's. No comparision. Say what you will about the man, but djb codes with a paranoia that few can match.
Not to be a lexicographic nitpicker, but perhaps you should look up the definition of "guarantee" in the dictionary. A guarantee is not proof that a condition is true; rather it is an assurance (usually backed by money or a buy-back provision) that the condition is true.
This is exactly what the "djbdns security guarantee" is.
The usage by djb (and myself in my earlier post) is correct and entirely appropriate.
You claim that $500 is insignificant, but it proves that the author is willing to put his money where is mouth is. The ISC isn't doing this with BIND.
In any case, my best assurance about djbdns is the code itself. Take a look. It's absolutely paranoid about security-related issues. The same as qmail. Now take a look at BIND. Which do you feel is more secure?
Djbdns is to BIND what qmail is to sendmail.
Not only is it written with security in mind, it even has a security guarantee. A refreshing change of pace.
Obviously, computer games don't save lives (if anyone cares to disagree with me on that one, I'd love to hear your argument)...
Actually, computer games do save lives in that they provide income and health benefits to a large populace in the electronic entertainment industry. That same multi-billion dollar industry also saves lives in the general populace by contributing to the economy at large. (Recall that there is a strong association between a nation's economic strength and its citizens' life expectancy.)
So, games do save lives, but in order to see the fact one must be willing to examine indirect economic effects.
Look, folks, object orientation is just one tool of many in the big box of software tools. Use it when appropriate, use something else when it isn't. This guy rants rants about OOP basically on three grounds, all of which are straw-man agruments:
OOP doesn't live up to the hype of its most zealous proponents (What does?)
When you do stupid things with OOP, you get stupid results. (What did you expect?)
Contrived, obviously-false statements about OOP are not true. Examples taken from the document: "Myth: Only OOP has automatic garbage collection", "Myth: Only OO databases can store large, multimedia data", "Myth: Components can only be built with OOP", and so on. These aren't legitimate myths widely believed by folks who use OOP; these are straw men propped up so that he could knock them down.
The reality is that OOP is a good tool for solving a lot of common problems. It's also a lousy tool for solving a lot of other common problems. When OOP isn't the right tool, don't use it.
Just use the right tool to begin with. When it comes to programming paradigms, there are lots of tools in box:
declarative (often in terms of w/ functional and logic based)
Use the right tool for the job. You'll be glad you did. (And you won't have to put up a web site just to rant about your bad experiences with using a hammer to place dry-wall screws.)
If you go to Google and search on phrases from the ReviewBoard article that are likely to be unique to the article, e.g. "E10k frame is capable of holding", how many hits do you get? Zero. This suggests that the article is too new to have been indexed by Google.
However, redir asserts that he has reliable information
that the ReviewBoard article was written in way back in March and therefore couldn't have been copied from AD's epinions piece from a few days ago, as AD claims.
If the RB article is actually nine months old, why hasn't Google indexed it yet? Certainly, Google combs RB more frequently than once every nine months. For example, here is a RB article posted in March, and it's in Google: Search on
"sprint pcs makes me think", taken from the article's opening line. Google returns the article as the first hit. (Following hits come from rb.chabotc.com.)
In summary:
Redir claims that the article is nine months old.
Google indexes RB more frequently than once every nine months.
The article hasn't been indexed by Google.
This evidence is highly suggestive that AD is correct and redir is not.
Please stop disseminating sensitive military information...
Yes, let's hope that Google doesn't fall into the wrong hands! Why, then anybody could search on empradiation and find all sorts of public information, including the documents I found! Oh, I shudder at the horror!
Most fighter aircraft designed to withstand EMP
on
EMP Artillery Shells
·
· Score: 3
If you do a little searching with Google and friends, you'll see that US fighter aircraft (and their components) are designed -- and tested -- to withstand significant amounts of EMP radiation. EMP is a well-known problem, and the engineers have been designing-in solutions for it for decades. Over a decade ago, in fact, I worked for a defense contractor on fighter aircraft, and EMP was one of the standard things upon which the aircraft were tested.
Basically, an aircraft near an EMP acts like an antenna, building up a voltage of about 8V/ft of aircraft size. There are fairly standard ways to design around this kind of build up. It might seem like a nasty problem after the fact, but if you know about it when engineering aircraft (and other military hardware), it's not the uncrackable nut it's made out to be.
See, for example,
this
reference that Google turned up. This is textbook stuff now.
At the companies I've worked or consulted for, certification is something the companies will consider if you don't have a well-established track record. The applicability of certs is generally limited to entry- and mid-level positions. You will almost never get a senior position on the strength of a few certs.
If you don't have the experience, and a good work history to prove it, a certfication may get you in the door. But, for higher-level positions, like the senior designer for a large system's middleware or the engineer in charge of scalability/performance tuning on a large-scale distributed sytem (which a lot of e-commerce back ends are), certifications aren't given much credibility.
In general, a known track record (good or bad) trumps certifications: If you're a known lamer, a cert won't save you. And if you're a known project-saver, nobody is even going to ask for your certs (or a resume in many cases) -- they want you on the team.
So, if you have a good track record, make sure that you can demonstrate it to potential employers. Otherwise, a certification may be your best bet.
You say in your first point that flash is not "native, open, [or] standardized"
No, that's not what I said. Please go back and read what I wrote.
First, what do you mean "native"? Native to what? The web browser? Your operating system?
Again, please read what I wrote. I wrote that content ought to be expressed in the Web's native, open, standardized formats. You know, the Web -- that crazy combination of a particular transport (HTTP) and a collection of standardized, well-defined content types (HTML/XHTML/CSS/...), all lovingling guided in public view by the friendly folks at the World Wide Web Consortium.
See, the point here is that Flash isn't like HTTP or HTML or CSS. It's one company's way of trying to pull an end-run on the standards process and sneak itself into a de-facto standard position by coaxing the ever-presuadable design community into using its products: Oh, you'll be cool! Your site will be the hippest! Just Generate your site using Flash! And don't worry about that tricky HTML and CSS stuff, just let us do the heavy lifting for you. That will leave you free to express your wonderful visions to the fullest!
Run, boy! It's the Sirens calling you to the rocks. Turn away while you still can!
Which brings us to the "open" part. Since Macromedia released the Flash specification as an open format...
Yeah, riiiiiiight. Have you actually read the licensing terms for that "open" code for which you provided a link? How about this spiffy licensing term: "You agree that your Product must output SWF files that can be opened without Errors in the latest version of the Macromedia Flash authoring software..." Gee, my Product has ensure that Macromedia's software sits in the cat-bird's seat? Now that's open!
Now for me, someone who wanted to provide a nice, well-designed visual and aural site for the common user...
Now, here's where most designers drive the buggy into the ditch. They leap to the conclusion that their users want a "nice, well-designed visual and aural site" without ever considering if that's really what their users want. When I hit E*Trade, I'm not wondering what visual and aural treats the boys at E*Trade Central have in store for me today. I'm wondering what's happening to my portfolio. I'm not sure why this point eludes so many design folk.
I'll let you in on what's apparently a big secret around here: Most users don't care Jack Squat about the visual and (gasp!) aural qualities of a site. All they care about is that the site solves their problems or satisfies their needs and wants as quickly and as transparently as possible. (Note that this does not mean that hideous, ugly sites are okay. Hideousness and ugliness get in the way of solving problems and satisfying needs and wants, and that violates the Prime Directive.)
So, if the best way to give your users what they want is with spiffy visual and aural stuff, then by all means have at it. On the other hand, if your site is like most web sites, where the primary objective is to deliver information or sell a good or product, please stay at least seven meters away from Flash! It's not what your users want; it just gets in the way.
It sounds like you want to say to hell with the new web multimedia formats and for everyone to be surfing in Lynx.
Not at all. I think that new web multimedia formats are great, just as long as they are reserved for content that is inherently multimedia in essence. The reason I'm urging people to avoid Flash is because most designers seem to think that non-multimedia content somehow becomes "better" when forced into a multimedia format like Flash. It ain't so. Content is best expressed in terms of the minimum presentation sufficient to capture the nature of the content. Anything else just gets in the way.
So, Flash is fine for animated cartoons. But it makes a lousy tool for general web site construction.
And your average.jpg is indexable? Well you can index the alt tag...so then a web designer would make sure the text from his/her flash movie would be included in a html tag in the page that brings it up.
You're right, JPEG images are not indexable. And that's why I wouldn't take a block of text (or other useful content), render it into a JPEG image, post it on a site instead of the text itself, and try to cover up my stupidity by stuffing the text in the image's ALT attribute. Yet that's exactly what a bunch of folks who use Flash do. They convert useful information, sometimes entire site hierarchies, into a less accessible, less useful form (Flash), and substitute that weakened content for the real thing.
When designing a site you have to assume that the average hit is gonna come from a newer, faster machine.
No you don't.The fact is, most people don't have the latest-and-greatest hardware and software. Making this assumption is not only contrary to fact, it's cheating yourself, your customers, and your clients. Rather than figuring out how to solve problems in terms of standard, web-native technologies that almost everybody on the Internet can use, you've chosen to make an assumption that makes your life easier at great cost to everybody else.
You can't expect the site designer to continue and continue to make site backwards compatible. [...] It is not designers problem if a user can't keep up with technology, he has to go with the majority. As long as the technology is excepted as the norm (which flash seems to be) go ahead and use it.
You're right about one thing. If a designer designs sites under the assumption that users will "keep up with technology," it's not his problem -- it's his users' problem and his client's problem. They're the ones that will suffer for his laziness.
And good designers do ensure that their sites are backwards compatible. For example, Amazon's designers made sure that you can buy books via Lynx if you want. They get it: Their content matters, and their designers make sure that the content rules, not the presentation (or their own egos).
Image is everything. It's not how great your product is it's how well you can market, display, and how cute it is.
Image is not everything. If you look at the companies that live or die based on their web presence, the ones that must truly "get" the web in order to survive, you'll see that they almost universally avoid Flash. Do you need Flash to buy a book from Amazon? Or post to Slashdot? Or participate in projects on Sourceforge? Or trade stocks on E*Trade? Nope. Are you seeing the big picture yet?
Remember: It's the content that counts! Everything that gets in the way, including Flash, is damaging to your users and your clients.
CSS and dhtml were developed to provide just that "Rich Immersive Experience" you deride, without the plugin download. Fact is, if people didn't want a pretty or graphical site, then the tag would never have been invented, and everyone would still be using lynx.
Baloney.
CSS and more-recent flavors of HTML, especially XHTML Basic, were designed to provide greater degrees of separation between content and presentation -- not to further mix the two, as your response suggests! This intertwining of content and presentation is the primary reason that Flash is so destructive when used to express content that could have been expressed in "native" web formats.
Flash prevents the content from being used in its own right. It prevents the use of text-to-speech technologies for sight-impared users, prevents the use of intelligent indexing systems, makes automated classification and compilation next to impossible, and generally flies in the face just about everything sensible that has happened in the last decade to make information more accessible and usable.
For example, the W3C's recently recommended XHTML Basic "allows content to be be shared across desktop computers, TVs, PDAs, pagers, and mobile phones." It makes content more accessible, more usable.
Flash does exactly the opposite. It obfuscates content by hiding it inside of a particular form of presentation.
First, I want to make it clear that I have nothing against the fine hackerly work that is Perl::Flash.
But Flash, itself, is just plain evil. Don't use Flash. Ever.
Why?
Well, for starters, using Flash announces to the world that you don't have a clue about how the Web works. Rather than express your content in the Web's native, open, standardized formats, you've hidden you content inside of a non-native, non-indexable, non-searchable format that a good many surfers can't view.
Using Flash announces to your web-surfing customers that you don't care about them. Forcing them to download the most-recent Flash plugin just for the privelige of viewing your site is presumptious and unrealistic -- many people will just surf to another site, perhaps one of your competitors'.
Using Flash cheats your clients. Most companies would kill for a few percentage points of market share. But, by using Flash for a client's web site, you'll exclude people with older browsers and unsupported platforms from using your site. These people represent a sizable market share. Do you think your clients don't want these people as customers? Content hidden inside of Flash can't be indexed by search engines. Do you think that you clients don't want people to find their products and services easily?
Finally, using Flash cheats yourself. You're kidding yourself if you think that you need to use Flash. I can't think of one instance of where Flash has made a site better. Just about every use I've seen has been gratuitous. People don't surf the web because they want a Rich Immersive Experience. They surf because they want to find solutions to their problems or find products and services that meet their needs and wants. Flash just gets in the way. So, do yourself a favor and learn what makes the Web work well -- HTML, XHTML, CSS, and their W3C-recommended friends. Then you can toss Flash in the trash. Do it. You'll be a better human for it.
So, just in case you didn't get the point: Don't use Flash!
A conforming Virtual Machine implementation shall support automatic garbage collection. The garbage-collection method is unspecified and left as a design decision for the implementor to consider based on the desired runtime characteristics of the Virtual Machine. However, it is required that any conforming implementation's garbage collection satisfy the required characteristics defined in Section 6.5.2, namely that it be godawful.
Yes, MI is lame for modeling. There just aren't that many "car-planes" in the real world, nor does the human brain resolve such unions easily. Since modeling is all about making the complex simple and understandable, MI is a poor tool for that purpose.
Nevertheless, when it comes to implmentation, MI is quite useful, and it's too bad that Java doesn't allow it. For example, see the cool stuff that the folks at Code Farms are doing:
I would like to know, however, what the problem might be with doing a re-vote...?
The problem is that, barring sustaining evidence for the "confusing ballots" having caused the wrong person to win the election, there is no provision for such a "re-vote" under Florida law. In order to contest the election, it would be the burden of the contestor to demonstrate (i.e., sustain) that "a person other than the successful candidate was the person duly nominated or elected to the office in question". In other words, make a darn good case for the causality I mentioned in earlier.
See 2000 Florida State Code, Title IX, 102.168(3)(e):
http://www.leg.state.fl.us/statutes/index.cfm?App_ mode=Display_Statute&Search_String=& amp; amp; amp;URL= Ch0102/SEC168.HTM&Title=-%3E2000-%3ECh0102-%3ESect ion%20168
If it's clear that they were confused, though, it seems that the only fair thing to do is have a re-vote in Palm Beach....
That the ratio of Buchanan votes to Bush votes in Palm Beach is significantly different from the similarly computed ratio for other counties and that this difference is extremely unlikely to be expained by random chance alone is not sufficient evidence to support the claim that the seemingly unexplained results are caused by confusing ballots or by voter error. In other words, you haven't demonstrated causality, and therefore there is no reason to suggest that the Palm Beach votes aren't legitimate.
The seeming anomaly could be explained by a number of other factors. For example:
Bush made statements that angered voters in Palm Beach. Many of these voters are conservative and would have voted for Bush, but instead they voted for their next-best conservative choice, Buchanan.
Buchanan has an unusually strong support base in Palm Beach.
Buchanan's relatives and family friends live in Palm Beach.
I just made these up, but I hope that you can see that a number of reasonable circumstances could explain the anomalous results beside the much-touted "confusing ballot" explanation.
Demonstrating a causal relationship is difficult and requires much stronger evidence than has been presented so far.
Contrary to some of the postings here that would have you believe that requirements specifications are nothing more than glorified feature lists and necessary only when dealing with a client, requirements specifications do several things, all extremely valuable:
They represent the best-available information about the system to be built and represent it in a readily-accessible form (natural language, e.g., English). Not everybody involved on a project speaks code, and even those that do don't always speak it in the same way or to the same degree. A requirements specification allows everybody -- business folks, senior analysts, junior coders, and other project participants -- to understand the requirements for the system and participate in their definition.
The requirements specification serves as a very-high-level representation of the system to be built which is easier and quicker to change than other representations. Like it or not, English and other natural languages are more expressive than most programming languages. You could write the code first and then change it until it's right, or you could write the requirements first and change them until they're right and then write the code -- once. The latter course is usually faster (for non-trivial systems) and yields software of higher quality.
When software is being developed by or for multiple parties, the requirements specification holds the best present agreement among those parties and helps drive the parties to consensus. Trying to get large, disparate groups of people to agree on something as complicated as a large software system is a daunting task. It's a process that usually takes months, but you can reduce that time (to fewer months) if you capture requirements as they're agreed to and put them in a specification so that they aren't forgotten and rehashed over and over again.
The requirements specification serves as an agreement among parties. In other words, "If it's not in the requirements, it won't be in the system."
So, let's give requirements specifications a break. They are useful tools.
I agreed to the license of my own free will, knowing the terms of it (I read EULAs), so I am ethically bound to abide by the terms.
So, if you could get the "Critial Update" for a massive security vulnerability in your OS only by agreeing to the terms of a bundled EULA, would your decision to accept the terms of the Update be of your own free will?
It's not like the vendor is holding a gun to your head, but they are saying, in effect, "Somebody else could very well be pointing a gun at you, and you are vulnerable (owing to a hole in the armor we sold you earlier), but we have a repair kit for the armor, so everything is okay. Oh, but in order to get the repair kit, you will need to agree to these additional terms..."
Ever use Windows Update to retrieve a "Critical Update" for a security vulnerability in Windows? Guess what? If you want to apply the update, you must agree to its bundled EULA. Seems to me that there's a bit of implicit coercion in that "choice" to accept or reject the bundled EULA.
I guess you could choose not to accept the EULA, but that would mean running an OS with well-publicized and wide-open security holes. Again, that doesn't seem like much of a choice.
Slashdot Mirror
Let me be blunt: If you aren't drinking espresso -- good espresso -- you haven't tasted coffee. And I mean espresso, not cappuccino, not latte, not frapparichinomochalaloopy. That's the kind of stuff you make when you want to cover up the taste of bad espresso.
Good espresso is nothing like the over-roasted, over-extracted, bitter and charred-tasting stuff you've had when you finally worked up the courage to try an ``espresso'' at *$s or some other gourmet coffee chain. If you're lucky, they gave you 3 or 4 ounces of unspeakably bitter drek. If you weren't lucky,... Well, I'm just thankful that you're still with us.
Good espresso is like heaven in a cup. Deep, rich, dark, and luxurious, good espresso has no bitterness. Its potent perfume only hints at the depth of complexity that awaits you upon the first sip. Creamy, caramelly, exploding with flavor, with a touch of sweetness on the tongue: This is what good espresso tastes like. No need to add sugar, the real stuff is quaffed straight.
Oh, and does espresso help your coding? You betcha! Nothing cuts through code fog like a double ristretto. Fires up the brain into smooth working condition. Clarity? You own clarity. With espresso cup in hand, ease in to the Captain's Chair: You are in command.
Face it, you need the real stuff. Here's how to get it:
- Stop buying stale coffee at stores and ``gourmet'' shops.
- Get an old hot-air popcorn popper and start homeroasting.
It's cheap, it's easy, and it's so worth it. You won't
believe how much better truly fresh coffee tastes. If you go no
farther than this and get a french press and a cheap grinder, you'll
have better coffee at home than you'll be able to find anywhere else.
- Get a decent espresso machine. No steam toys. Read the
user-contributed reviews on www.coffeekid.com. Plan on
spending at least 250 USD for a decent machine. Spend the money:
you'll pay for it in under a year from your coffee-chain savings.
- Get a good grinder. You can't make real espresso without
one. This is the one that people skimp on and later wonder why their
fancy 1000-USD espresso machine can't make good espresso. Plan on
another 200 USD, minimum. Again, it pays for itself.
- Lurk in alt.coffee
and drink in the wisdom. Learn how to pull a ristretto that extracts the deep, beautiful essence of
15g of freshly ground, freshly roasted coffee into 1.75ounces
of pure bliss. Once you've had a "god shot", you'll never be able to go back to bad coffee again.
Do it. It will change your life.P.S. Here's a good starting roast/blend for espresso: 2 parts brazillian cerrado, 1 part sumatra mandheling, 1/2 part monsooned malabar, 1/2 part monsooned cherry aa robusta. Roast each part individually, just a bit into the second crack. Blend and store in an airtight glass container. The next morning, open the container and try to contain your amazement at how great the stuff is.
Compainies do this kind of thing because many people are sheep and will actually fall for bogus claims of "reserved rights" and disclaimers for things that can't legally be disclaimed. The people who belive this garbage are throwing away their rights by being dumb enough to believe that those rights don't exist, simply because A Big Corporation told them so.
My advice: Don't be one of the sheep.
Contrast qmail's security history -- with only one, non-compromising DoS vulnerablity -- to sendmail's -- chock full o' root holes -- and you'll see that there is no comparison between the two.
Don't trust anybody's reputation. Read the code. Compare qmail's code to sendmail's. Compare djbdns's code to BIND's. No comparision. Say what you will about the man, but djb codes with a paranoia that few can match.If security matters to you, read the code.
You claim that $500 is insignificant, but it proves that the author is willing to put his money where is mouth is. The ISC isn't doing this with BIND.
In any case, my best assurance about djbdns is the code itself. Take a look. It's absolutely paranoid about security-related issues. The same as qmail. Now take a look at BIND. Which do you feel is more secure?
Djbdns is to BIND what qmail is to sendmail. Not only is it written with security in mind, it even has a security guarantee. A refreshing change of pace.
Actually, computer games do save lives in that they provide income and health benefits to a large populace in the electronic entertainment industry. That same multi-billion dollar industry also saves lives in the general populace by contributing to the economy at large. (Recall that there is a strong association between a nation's economic strength and its citizens' life expectancy.)
So, games do save lives, but in order to see the fact one must be willing to examine indirect economic effects.
Look, folks, object orientation is just one tool of many in the big box of software tools. Use it when appropriate, use something else when it isn't. This guy rants rants about OOP basically on three grounds, all of which are straw-man agruments:
The reality is that OOP is a good tool for solving a lot of common problems. It's also a lousy tool for solving a lot of other common problems. When OOP isn't the right tool, don't use it.
Just use the right tool to begin with. When it comes to programming paradigms, there are lots of tools in box:
Use the right tool for the job. You'll be glad you did. (And you won't have to put up a web site just to rant about your bad experiences with using a hammer to place dry-wall screws.)
If you go to Google and search on phrases from the ReviewBoard article that are likely to be unique to the article, e.g. "E10k frame is capable of holding", how many hits do you get? Zero. This suggests that the article is too new to have been indexed by Google.
However, redir asserts that he has reliable information that the ReviewBoard article was written in way back in March and therefore couldn't have been copied from AD's epinions piece from a few days ago, as AD claims.
If the RB article is actually nine months old, why hasn't Google indexed it yet? Certainly, Google combs RB more frequently than once every nine months. For example, here is a RB article posted in March, and it's in Google: Search on "sprint pcs makes me think", taken from the article's opening line. Google returns the article as the first hit. (Following hits come from rb.chabotc.com.)
In summary:
This evidence is highly suggestive that AD is correct and redir is not.
Yes, let's hope that Google doesn't fall into the wrong hands! Why, then anybody could search on empradiation and find all sorts of public information, including the documents I found! Oh, I shudder at the horror!
http://www.google.com/search?q=%22emp+radiation%22 +&hl=en&lr=&safe=off
If you do a little searching with Google and friends, you'll see that US fighter aircraft (and their components) are designed -- and tested -- to withstand significant amounts of EMP radiation. EMP is a well-known problem, and the engineers have been designing-in solutions for it for decades. Over a decade ago, in fact, I worked for a defense contractor on fighter aircraft, and EMP was one of the standard things upon which the aircraft were tested.
Basically, an aircraft near an EMP acts like an antenna, building up a voltage of about 8V/ft of aircraft size. There are fairly standard ways to design around this kind of build up. It might seem like a nasty problem after the fact, but if you know about it when engineering aircraft (and other military hardware), it's not the uncrackable nut it's made out to be.
See, for example, this reference that Google turned up. This is textbook stuff now.
At the companies I've worked or consulted for, certification is something the companies will consider if you don't have a well-established track record. The applicability of certs is generally limited to entry- and mid-level positions. You will almost never get a senior position on the strength of a few certs.
If you don't have the experience, and a good work history to prove it, a certfication may get you in the door. But, for higher-level positions, like the senior designer for a large system's middleware or the engineer in charge of scalability/performance tuning on a large-scale distributed sytem (which a lot of e-commerce back ends are), certifications aren't given much credibility.
In general, a known track record (good or bad) trumps certifications: If you're a known lamer, a cert won't save you. And if you're a known project-saver, nobody is even going to ask for your certs (or a resume in many cases) -- they want you on the team.
So, if you have a good track record, make sure that you can demonstrate it to potential employers. Otherwise, a certification may be your best bet.
No, that's not what I said. Please go back and read what I wrote.
Again, please read what I wrote. I wrote that content ought to be expressed in the Web's native, open, standardized formats. You know, the Web -- that crazy combination of a particular transport (HTTP) and a collection of standardized, well-defined content types (HTML/XHTML/CSS/...), all lovingling guided in public view by the friendly folks at the World Wide Web Consortium.
See, the point here is that Flash isn't like HTTP or HTML or CSS. It's one company's way of trying to pull an end-run on the standards process and sneak itself into a de-facto standard position by coaxing the ever-presuadable design community into using its products: Oh, you'll be cool! Your site will be the hippest! Just Generate your site using Flash! And don't worry about that tricky HTML and CSS stuff, just let us do the heavy lifting for you. That will leave you free to express your wonderful visions to the fullest!
Run, boy! It's the Sirens calling you to the rocks. Turn away while you still can!
Yeah, riiiiiiight. Have you actually read the licensing terms for that "open" code for which you provided a link? How about this spiffy licensing term: "You agree that your Product must output SWF files that can be opened without Errors in the latest version of the Macromedia Flash authoring software..." Gee, my Product has ensure that Macromedia's software sits in the cat-bird's seat? Now that's open!
Now, here's where most designers drive the buggy into the ditch. They leap to the conclusion that their users want a "nice, well-designed visual and aural site" without ever considering if that's really what their users want. When I hit E*Trade, I'm not wondering what visual and aural treats the boys at E*Trade Central have in store for me today. I'm wondering what's happening to my portfolio. I'm not sure why this point eludes so many design folk.
I'll let you in on what's apparently a big secret around here: Most users don't care Jack Squat about the visual and (gasp!) aural qualities of a site. All they care about is that the site solves their problems or satisfies their needs and wants as quickly and as transparently as possible. (Note that this does not mean that hideous, ugly sites are okay. Hideousness and ugliness get in the way of solving problems and satisfying needs and wants, and that violates the Prime Directive.)
So, if the best way to give your users what they want is with spiffy visual and aural stuff, then by all means have at it. On the other hand, if your site is like most web sites, where the primary objective is to deliver information or sell a good or product, please stay at least seven meters away from Flash! It's not what your users want; it just gets in the way.
Not at all. I think that new web multimedia formats are great, just as long as they are reserved for content that is inherently multimedia in essence. The reason I'm urging people to avoid Flash is because most designers seem to think that non-multimedia content somehow becomes "better" when forced into a multimedia format like Flash. It ain't so. Content is best expressed in terms of the minimum presentation sufficient to capture the nature of the content. Anything else just gets in the way.
So, Flash is fine for animated cartoons. But it makes a lousy tool for general web site construction.
Sigh. Okay, let's take 'em one by one...
You're right, JPEG images are not indexable. And that's why I wouldn't take a block of text (or other useful content), render it into a JPEG image, post it on a site instead of the text itself, and try to cover up my stupidity by stuffing the text in the image's ALT attribute. Yet that's exactly what a bunch of folks who use Flash do. They convert useful information, sometimes entire site hierarchies, into a less accessible, less useful form (Flash), and substitute that weakened content for the real thing.
No you don't.The fact is, most people don't have the latest-and-greatest hardware and software. Making this assumption is not only contrary to fact, it's cheating yourself, your customers, and your clients. Rather than figuring out how to solve problems in terms of standard, web-native technologies that almost everybody on the Internet can use, you've chosen to make an assumption that makes your life easier at great cost to everybody else.You're right about one thing. If a designer designs sites under the assumption that users will "keep up with technology," it's not his problem -- it's his users' problem and his client's problem. They're the ones that will suffer for his laziness.
And good designers do ensure that their sites are backwards compatible. For example, Amazon's designers made sure that you can buy books via Lynx if you want. They get it: Their content matters, and their designers make sure that the content rules, not the presentation (or their own egos).
Image is not everything. If you look at the companies that live or die based on their web presence, the ones that must truly "get" the web in order to survive, you'll see that they almost universally avoid Flash. Do you need Flash to buy a book from Amazon? Or post to Slashdot? Or participate in projects on Sourceforge? Or trade stocks on E*Trade? Nope. Are you seeing the big picture yet?
Remember: It's the content that counts! Everything that gets in the way, including Flash, is damaging to your users and your clients.
Baloney.
CSS and more-recent flavors of HTML, especially XHTML Basic, were designed to provide greater degrees of separation between content and presentation -- not to further mix the two, as your response suggests! This intertwining of content and presentation is the primary reason that Flash is so destructive when used to express content that could have been expressed in "native" web formats.
Flash prevents the content from being used in its own right. It prevents the use of text-to-speech technologies for sight-impared users, prevents the use of intelligent indexing systems, makes automated classification and compilation next to impossible, and generally flies in the face just about everything sensible that has happened in the last decade to make information more accessible and usable.
For example, the W3C's recently recommended XHTML Basic "allows content to be be shared across desktop computers, TVs, PDAs, pagers, and mobile phones." It makes content more accessible, more usable.
Flash does exactly the opposite. It obfuscates content by hiding it inside of a particular form of presentation.
Once again, Don't use Flash!
First, I want to make it clear that I have nothing against the fine hackerly work that is Perl::Flash.
But Flash, itself, is just plain evil. Don't use Flash. Ever.
Why?
So, just in case you didn't get the point: Don't use Flash!
The Java2 spec clearly states:
Wow. Go figure...;->
Care to explain how you're going to handle call-with-current-continuation?
;-)
Yes, MI is lame for modeling. There just aren't that many "car-planes" in the real world, nor does the human brain resolve such unions easily. Since modeling is all about making the complex simple and understandable, MI is a poor tool for that purpose.
Nevertheless, when it comes to implmentation, MI is quite useful, and it's too bad that Java doesn't allow it. For example, see the cool stuff that the folks at Code Farms are doing:
MI can be especially handy in conjunction with generic programming, another thing that Java doesn't do well.
The problem is that, barring sustaining evidence for the "confusing ballots" having caused the wrong person to win the election, there is no provision for such a "re-vote" under Florida law. In order to contest the election, it would be the burden of the contestor to demonstrate (i.e., sustain) that "a person other than the successful candidate was the person duly nominated or elected to the office in question". In other words, make a darn good case for the causality I mentioned in earlier.
See 2000 Florida State Code, Title IX, 102.168(3)(e):_ mode=Display_Statute&Search_String=& amp; amp; amp;URL= Ch0102/SEC168.HTM&Title=-%3E2000-%3ECh0102-%3ESect ion%20168
http://www.leg.state.fl.us/statutes/index.cfm?App
That the ratio of Buchanan votes to Bush votes in Palm Beach is significantly different from the similarly computed ratio for other counties and that this difference is extremely unlikely to be expained by random chance alone is not sufficient evidence to support the claim that the seemingly unexplained results are caused by confusing ballots or by voter error. In other words, you haven't demonstrated causality, and therefore there is no reason to suggest that the Palm Beach votes aren't legitimate.
The seeming anomaly could be explained by a number of other factors. For example:
I just made these up, but I hope that you can see that a number of reasonable circumstances could explain the anomalous results beside the much-touted "confusing ballot" explanation.
Demonstrating a causal relationship is difficult and requires much stronger evidence than has been presented so far.
Let's not be hasty.
So, let's give requirements specifications a break. They are useful tools.
It's not like the vendor is holding a gun to your head, but they are saying, in effect, "Somebody else could very well be pointing a gun at you, and you are vulnerable (owing to a hole in the armor we sold you earlier), but we have a repair kit for the armor, so everything is okay. Oh, but in order to get the repair kit, you will need to agree to these additional terms..."
Is this a free-will choice?
I guess you could choose not to accept the EULA, but that would mean running an OS with well-publicized and wide-open security holes. Again, that doesn't seem like much of a choice.