Slashdot Mirror

AirDrop and Android -- this makes no sense. You were talking about transferring data from an iOS phone to a laptop.
AirDrop and Linux -- no, you use a method like this: http://www.libimobiledevice.or...
AirDrop and Windows -- no, you use one of the methods here https://it.toolbox.com/blogs/a...
AirDrop is designed for secure and private transfer of data between Apple devices. The whole point of the Apple proposition is to be able to offer solutions that take advantage of the tight integration of software and hardware. So they are inherently non-cross-platform. Affecting shock or dismay at this situation is just stupid.

And why you are fussed about transferring data securely and privately if you're just going to move it to an insecure platform that doesn't protect privacy is beyond me.

As a tech person, was it really so difficult for you to search for this stuff?

I remember back in 2002 reading about a 2PB DB2 at some research university. My google-fu isn't good enough to hunt it down.

But I hope the below provides some insight to where DB2 is at today. 500,000PB. I need to do more research because I am finding it hard to believe.

http://it.toolbox.com/blogs/db...

Anyway DB2 has always been more hardware limited than software. Every atom in DB2 can be plumped up in bits till it hits the hardware limits; multiplying its overall capacity. But too many bits and you are just wasting space.

NASA has never built rockets, it's bought them from Boeing and a whole host of other US companies over the years. The new "private" launch startup companies are Seven Dwarfs who will rely to a large part on US government money via NASA and other organisations like US DoD to offset their costs and pad the bottom line.

Here's a similar issue cited : Vista refuses to work with some DHCP servers - the presence of a registry setting to turn this behaviour off (the default value is "1" for on) reveals that rather than just stick to a DHCP client that works as standard, MS deliberately broke it so it would be harder to work with any DHCP server that wasn't Windows.

There are permutations of the concepts in database theory that have not been tried, at least not that I know of, but NoSQL and this NoSQL 2.0 idea are not amongst them.

A short, and not comprehensive, list of underlying database structures
Another short list, describing a few others
A short list of some file organization methods (ie: access methods)

A truly novel combination of existing structures and access methods would be worthy of a new name. A truly novel form of structure or file organization - assuming it is actually useful - is worthy of not just a new name but a new name writ large on the front page. A repackaged version of an existing combination might want a new marketing name, but it should be recognized that that is all it is - a name to sell by.

Yeah, my current employer "bought" me from a call center, over eleven years ago, for $36k. Now, I'm making nearly 3x that salary. I come and go when I please, essentially work on what I feel like working on, and I get to be an asshole and a curmudgeon, and noone can call me on it. There are benefits other than salary.

They enticed you away with a raise, and you stayed because you kept getting fair market value for your service. That was kinda my whole point.

What he ought to do is decide whether working for the new company benefits him more than working for the old company. Whether it's worth giving up the friendships, relationships, intangible benefits, and other goodies he's built up in exchange for the larger salary and the possibility of new intangible benefits down the road. Early this year, I took a new job with a giant financial firm, and while the pay was indeed nice, the working environment was NOT what it was cracked up to be. It was a nightmare, and so I returned here about about 10 weeks. Not everyone would have this opportunity, but in my case, I'm sure glad I did.

So, let me get this straight. Talking with your boss about another opportunity could be considered disloyal, but you actually left your current job for a better offer and then came back and you're advising others on what you consider to be company loyalty?

This is not just my advice, this is the generally accepted wisdom:

http://www.forbes.com/2008/06/28/counter-offer-employer-lead-careers-cx_hr_0630counteroffer.html

http://frugaldad.com/2008/02/05/accepting-company-counter-offer-can-be-risky-move/

http://www.businessweek.com/careers/content/nov2004/ca2004114_2710_ca009.htm

http://it.toolbox.com/blogs/it-recruiter/why-you-should-not-accept-a-counter-offer-2359

I would hardly consider these 4 links "accepted wisdom". The first link (Forbes) talks about some guy whose counteroffer was to be the CEO of a major multinational retailer. So what if he only had the job for 3 years? When your salary is $1m per year and you have a golden parachute bailout, 3 years as CEO is plenty of time to rack up some serious cash. It even mentioned that he took an early retirement. Oh, the horror. That sounds like just about the best possible outcome. CEO anecdotes are not really applicable for people working at the "peon" level.

Second link (frugaldad) is written by Jason (Frugal Dad) on his blog. His anecdote is that he was ready to receive a counteroffer, but he got laid off instead. He then goes on to contradict the belief that counteroffers are indicators of disloyalty in his second paragraph.

Third link (businessweek) is behind a paywall, or broken.

Fourth article (it.toolbox) was written by a recruiter who is obviously irritated by people who run through the whole recruitment process (thus wasting his time) and then stay with their current company due to a counter-offer. He ends the article with this:

"I hope that some of this dialoge hits home because these are some of the most frustrating issues to handle as a recruiter. I think they are all avoidable and can positively impact your career when handled in the right manner. These are principles to live by, like being honest and sticking to your word, and knowing thy self!"

And I think that speaks volumes. It's not accepted wisdom, it's one recruiter guy giving his opinion.

Whatever though. Of course, there are intangibles like the people you work with, that atmosphere, perks, and your gene

Seriously? Is anyone at your current company under the illusion that you would not leave for a high enough offer? People can pretend all they want, but the reality is that your current employer bought you from your previous employer. Every new person they hire, they are hiring away from another company, likely at a higher rate. What's the big surprise here? Of course your skills are for sale - that's why you're working. If they are not willing to pay market value for your skills then move on.

Yeah, my current employer "bought" me from a call center, over eleven years ago, for $36k. Now, I'm making nearly 3x that salary. I come and go when I please, essentially work on what I feel like working on, and I get to be an asshole and a curmudgeon, and noone can call me on it. There are benefits other than salary.

I suppose I'm rather baffled by the whole logic here; what, then, should he do? Refuse the current job offer and stay where he's at, but keep it a secret? How does that prove loyalty at all? Nobody knows about it. Or he could refuse the current job offer and then tell his current employer he was offered a job somewhere else but refused. That just sounds needy and pathetic - does that prove loyalty? Or does that prove you're too chickenshit to stand up and ask for a reasonable raise?

What he ought to do is decide whether working for the new company benefits him more than working for the old company. Whether it's worth giving up the friendships, relationships, intangible benefits, and other goodies he's built up in exchange for the larger salary and the possibility of new intangible benefits down the road. Early this year, I took a new job with a giant financial firm, and while the pay was indeed nice, the working environment was NOT what it was cracked up to be. It was a nightmare, and so I returned here about about 10 weeks. Not everyone would have this opportunity, but in my case, I'm sure glad I did.

    Or he could man up and explain the situation to his boss. If his boss has a clue and his workplace isn't a hellhole, they might offer him a small raise. If they are hostile to the whole idea, then he's better off quitting and moving on anyway. I've never had a problem discussing stuff like this with my boss, she is intelligent and reasonable and understands that I have bills to pay and a family to feed. I don't work for the love of working, I work because I need a paycheck. If I can get a bigger paycheck by negotiating a little bit, what's the harm in that? If you work at a company that considers something like this untrustworthy, then maybe you should reevaluate the situation.

The problem is that it marks you as someone who's looking for a new job. Even if you get your counter-offer, your employer knows it's merely a matter of time. Those "intangibles" tend to disappear rather quickly at that point. If you're working strictly for a salary, then by all means, go for the counteroffer, but for the rest of us, it's not worth turning our workplace hostile for a little more money.

This is not just my advice, this is the generally accepted wisdom:

http://www.forbes.com/2008/06/28/counter-offer-employer-lead-careers-cx_hr_0630counteroffer.html
http://frugaldad.com/2008/02/05/accepting-company-counter-offer-can-be-risky-move/
http://www.businessweek.com/careers/content/nov2004/ca2004114_2710_ca009.htm
http://it.toolbox.com/blogs/it-recruiter/why-you-should-not-accept-a-counter-offer-2359

Sigh, you've missed the entire point of the "Primary Keyvil" articles (Part 1, Part 2, Part 3), and many similar ones. Let's go through your drivel point by point.

"Student ID" is an acceptable primary key - you will be able to tell if two rows are duplicates based on this alone.

Wrong, wrong, wrong. A surrogate key, like "student ID", actually is an acceptable "primary key" for a table, but only if you have a real way to tell apart your users, something based on an understanding of an answer to the question "what defines a unique student, and how am I going to verify that?".

It's not automatically generated by the database, which is the primary keyvil syndrome.

VERY WRONG! From the database's point of view, and the "primary keyvil" syndrome, it doesn't matter if you fill in the "student ID" using, say, a database function called SYS_GUID(), or whether you generate this GUID on the client side. Read Part 1 of the Primary Keyvil syndrome articles for another example. But let's take our example of a table of students and run with it. You, the database application developer and schema designer, have created a table of students where the only unique key is a "student ID". Let's pretend you're smart, and you only assign new student IDs to new students coming through the gate on admission day. So far, so good, right?

Well, you're sitting in your office when a freshman comes in and says "Hey, I lost my ID. How do I get a new one". Now you're in a tough spot. You could say "what's your student ID number?", and if the student knows it, then you print off a new student ID for him, since you know who he is based on his ID number, right? Uh oh, you've just opened a door to students impersonating other students. But let's ignore that problem for now... what do you do if the poor kid doesn't know his ID number? Well, you ask him..... his name? Right? What if it's "Joe Smith", and you have fifty of those in your giant state school? Uh, I guess you ask him his name, and his street address, right? That's got to be unique, right? Or maybe his current SSN, those can never change, right? And how do you prove that the student in front of you is really who he says he is?

The frantic grasping around in the above paragraph is why you need to have a good answer to the question "what distinguishes a unique student?" before you go designing a table like this. There are several ways to answer this question: in practice, you might enforce unique constraints on (full name + home phone number), or maybe just a unique key on SSN if you're daring. But either way, relying solely on some arbitrary identifier like "Student ID" with no actual anchor in reality opens all sorts of paths to trouble. (Incidentally, the social security administration has the same problem, they've just thought through and been through the consequences. They have elaborate, formal answers to the question "how do we distinguish unique people, regardless of SSN", for scenarios like assigning new SSNs, changing SSNs, replacing lost social security cards to people who don't remember their SSN, etc etc.)

Another major problem I didn't even touch on, is how your model would prevent a user from getting two student IDs, either intentionally or accidentally. If you haven't answered these fundamental questions, you will have a database full of garbage. Kind of like the No Fly List.

It's as unique as it would be to include the students DNA in number form as the primary key.

Privacy concerns aside, DNA would actually be a totally reasonable way to distinguish unique students -- student comes in to your office, you take a cheek swab, and issue him his replacement ID card. (Hrm,

Sigh, you've missed the entire point of the "Primary Keyvil" articles (Part 1, Part 2, Part 3), and many similar ones. Let's go through your drivel point by point.

"Student ID" is an acceptable primary key - you will be able to tell if two rows are duplicates based on this alone.

Wrong, wrong, wrong. A surrogate key, like "student ID", actually is an acceptable "primary key" for a table, but only if you have a real way to tell apart your users, something based on an understanding of an answer to the question "what defines a unique student, and how am I going to verify that?".

It's not automatically generated by the database, which is the primary keyvil syndrome.

VERY WRONG! From the database's point of view, and the "primary keyvil" syndrome, it doesn't matter if you fill in the "student ID" using, say, a database function called SYS_GUID(), or whether you generate this GUID on the client side. Read Part 1 of the Primary Keyvil syndrome articles for another example. But let's take our example of a table of students and run with it. You, the database application developer and schema designer, have created a table of students where the only unique key is a "student ID". Let's pretend you're smart, and you only assign new student IDs to new students coming through the gate on admission day. So far, so good, right?

Well, you're sitting in your office when a freshman comes in and says "Hey, I lost my ID. How do I get a new one". Now you're in a tough spot. You could say "what's your student ID number?", and if the student knows it, then you print off a new student ID for him, since you know who he is based on his ID number, right? Uh oh, you've just opened a door to students impersonating other students. But let's ignore that problem for now... what do you do if the poor kid doesn't know his ID number? Well, you ask him..... his name? Right? What if it's "Joe Smith", and you have fifty of those in your giant state school? Uh, I guess you ask him his name, and his street address, right? That's got to be unique, right? Or maybe his current SSN, those can never change, right? And how do you prove that the student in front of you is really who he says he is?

The frantic grasping around in the above paragraph is why you need to have a good answer to the question "what distinguishes a unique student?" before you go designing a table like this. There are several ways to answer this question: in practice, you might enforce unique constraints on (full name + home phone number), or maybe just a unique key on SSN if you're daring. But either way, relying solely on some arbitrary identifier like "Student ID" with no actual anchor in reality opens all sorts of paths to trouble. (Incidentally, the social security administration has the same problem, they've just thought through and been through the consequences. They have elaborate, formal answers to the question "how do we distinguish unique people, regardless of SSN", for scenarios like assigning new SSNs, changing SSNs, replacing lost social security cards to people who don't remember their SSN, etc etc.)

Another major problem I didn't even touch on, is how your model would prevent a user from getting two student IDs, either intentionally or accidentally. If you haven't answered these fundamental questions, you will have a database full of garbage. Kind of like the No Fly List.

It's as unique as it would be to include the students DNA in number form as the primary key.

Privacy concerns aside, DNA would actually be a totally reasonable way to distinguish unique students -- student comes in to your office, you take a cheek swab, and issue him his replacement ID card. (Hrm,

Sigh, you've missed the entire point of the "Primary Keyvil" articles (Part 1, Part 2, Part 3), and many similar ones. Let's go through your drivel point by point.

"Student ID" is an acceptable primary key - you will be able to tell if two rows are duplicates based on this alone.

Wrong, wrong, wrong. A surrogate key, like "student ID", actually is an acceptable "primary key" for a table, but only if you have a real way to tell apart your users, something based on an understanding of an answer to the question "what defines a unique student, and how am I going to verify that?".

It's not automatically generated by the database, which is the primary keyvil syndrome.

VERY WRONG! From the database's point of view, and the "primary keyvil" syndrome, it doesn't matter if you fill in the "student ID" using, say, a database function called SYS_GUID(), or whether you generate this GUID on the client side. Read Part 1 of the Primary Keyvil syndrome articles for another example. But let's take our example of a table of students and run with it. You, the database application developer and schema designer, have created a table of students where the only unique key is a "student ID". Let's pretend you're smart, and you only assign new student IDs to new students coming through the gate on admission day. So far, so good, right?

Well, you're sitting in your office when a freshman comes in and says "Hey, I lost my ID. How do I get a new one". Now you're in a tough spot. You could say "what's your student ID number?", and if the student knows it, then you print off a new student ID for him, since you know who he is based on his ID number, right? Uh oh, you've just opened a door to students impersonating other students. But let's ignore that problem for now... what do you do if the poor kid doesn't know his ID number? Well, you ask him..... his name? Right? What if it's "Joe Smith", and you have fifty of those in your giant state school? Uh, I guess you ask him his name, and his street address, right? That's got to be unique, right? Or maybe his current SSN, those can never change, right? And how do you prove that the student in front of you is really who he says he is?

The frantic grasping around in the above paragraph is why you need to have a good answer to the question "what distinguishes a unique student?" before you go designing a table like this. There are several ways to answer this question: in practice, you might enforce unique constraints on (full name + home phone number), or maybe just a unique key on SSN if you're daring. But either way, relying solely on some arbitrary identifier like "Student ID" with no actual anchor in reality opens all sorts of paths to trouble. (Incidentally, the social security administration has the same problem, they've just thought through and been through the consequences. They have elaborate, formal answers to the question "how do we distinguish unique people, regardless of SSN", for scenarios like assigning new SSNs, changing SSNs, replacing lost social security cards to people who don't remember their SSN, etc etc.)

Another major problem I didn't even touch on, is how your model would prevent a user from getting two student IDs, either intentionally or accidentally. If you haven't answered these fundamental questions, you will have a database full of garbage. Kind of like the No Fly List.

It's as unique as it would be to include the students DNA in number form as the primary key.

Privacy concerns aside, DNA would actually be a totally reasonable way to distinguish unique students -- student comes in to your office, you take a cheek swab, and issue him his replacement ID card. (Hrm,

Time and time again, the question of Oracle-like hints for PostgreSQL pops up on the PostgreSQL mailing lists. I thought I share some links as I find the topic fairly interesting. Hopefully the DBAs out there will too.

Why PostgreSQL Doesn't Have Query Hints
Why PostgreSQL Already Has Query Hints
Plan Tuner - Ripped from the above link

And in case you don't know, this is a great place to stay current with PostgreSQL development and technology.

From the second paragraph of that article:

This deeply saddens n3td3v because
we believe that MPAA and RIAA are forces of good. They saved millions of lives.
(n3td3v has lobbied for corporal punishment for trolls and torrent downloaders)

http://it.toolbox.com/blogs/managing-infosec/security-trolls-n3td3v-12460 states:

N3td3v is/was a security troll that plagued the full disclosure list for quite a while, claiming to be a yahoo security engineer

(from the start of an extensive article)

The most complete copy I've found of Faulkner's lengthy initial posting on the matter is at:
http://webcache.googleusercontent.com/search?q=cache:WnAbrdQbA30J:www.scribd.com/doc/13974347/mirror-of-wwwuwwwbcom-FBI-indiscriminate-actions-in-fascist-america+&cd=1&hl=en&ct=clnk

Yep, the google cache of a page printed to PDF and uploaded to Scribd. Some formatting is lost; try the text-only version from the google cache toolbar and copying into an editor (or otherwise removing the bright-green-ness of the text).

This is probably the most complete account of events, tied together with at least one side of the full story.

The debt in the millions was the operating costs of a failed business he was part owner of (not in itself illegal, unless you incur the debt deliberately); and he was not the cause of the business failing (in his own words). I didn't find any evidence of him being charged with wrongdoing over the operation of that business (brief google search)

He wasn't hiding overseas - he was never told to stay in the country, and informed the head of the FBIs investigation where he would be living, and who he would be working for. He never tried to change his identity.

Faulkner, who was a part owner of Premier Voice before selling it about a year ago, acknowledges that Premier owed money to AT&T at one time — though he says he’s not certain it was for interconnection. He says that debt was assumed by the new owner when he sold the company. Either way, he says, this would be categorized as corporate debt, not fraud.

"There’s a big difference between stealing money and owing money," he says.

- http://www.wired.com/threatlevel/2009/04/data-centers-ra/

Egh, that's it from me for now - some terrible bug in Chrome and/or Slashcode is making it a significant hassle to copy/paste stuff. Anyone else have similar issues? (I'm running current Chrome on OS X 10.6)

You've got the performance part backwards for PostgreSQL; it goes up with every release, sometimes a little, sometimes in a big way. See PostgreSQL history for a comparison covering versions 8.0 to 8.4. The mild regression in 8.4 shown there is actually reversible; it's mainly because a query related parameter for how many statistics to collect and use for query planning was increased by default. That results in better plans for most real-world queries, but it detuned this trivial benchmark a little bit. You can get performance back to 8.3 levels just by turning the parameter back to the "optimized for trivial queries" default of the older versions if you care about that. Most people prefer the new default. In the real world, 8.4 is actually faster due to improved handling of background VACUUM tasks too, which don't show up in simple benchmarks either.

I'm the current lead architect on building a PostgreSQL Performance Farm to prevent regressions from popping into future versions of the code too. There is a recently completed beta client for that purpose. We're in the process of working out how to integrate into future development, starting with 9.1, so that potential regressions are spotted on a commit by commit basis. I haven't seen any performance regressions between 8.4 and 9.0, only moderate improvements overall and large ones in specific areas that were accelerated.

Now, if you use some of the new replication features aggressively, that can add some overhead to slow down the master. But that's true of most solution; the data coming off the master has to take up some time to generate. The way PostgreSQL 9.0 does it is is pretty low overhead, it just ships the changed blocks around. Theoretically some statement based solutions might have lower overhead, but they usually come with concerns about non-determinism on the slaves when replayed (random numbers, timestamps, and sequence numbers are common examples).

Given the non-disclosure terms of most of the closed source databases, nobody can publish benchmarks that include them without going through something like the TPC or SPEC process. The last time that was done in 2007, PostgreSQL 8.2 was about 15% slower than Oracle running the same database-heavy workload. And note that it was PostgreSQL 8.3 that had one of the larger performance increases, so that was from just before a large leap forward in PostgreSQL performance.

At this point, Oracle and most other commercial databases still have a large lead on some of the queries run in the heavier TPC-H benchmarks. Links to more details as to why are on the PostgreSQL wiki. It just hasn't been a priority for development to accelerate all of the types of queries required to do well in that benchmark, and nobody so far has been willing to fund that or the subsequent certification via the TPC yet. Sun was the only one throwing money in that direction, and obviously the parts of that left within Oracle will no longer do so.

It was wrong.

Watermelon has more iron in it than spinach, and I personally find it far more tasty.

I'm in the anti-M$ camp, but it really sickens me to see a bunch of zealots that can't even be honest or fair; it makes our side seem whiny. It would be like a Microsoftie uttering some hyperbole like "no successful company is running Linux." See how stupid and detached from reality that sounds?

Hey, look! I put the words "Linux innovations" into some search engines...
http://www.theinquirer.net/inquirer/news/1017183/linux-innovation-missing
http://it.toolbox.com/blogs/paytonbyrd/linux-lacks-innovation-13721
http://www.zdnet.com/blog/murphy/is-linux-innovative/972

See, no innovation --these results prove it! Wow, it sure is easy to have a ridiculous opinion. Maybe we could try to appear just a little fair-minded and actually put 10 seconds of real effort into our assertion the M$ has never innovated?

Infinite scalability isn't the only snake oil in the cloud. Other cloud computing myths include "all you need is a credit card" and "cloud is cheaper."

She meant spinach, and I refused to eat it. And it turns out I was right - spinach is very LOW in iron. It turns out that a decimal point error was propagated for decades, and that the "spinach is high in iron and good for you" speeches were wrong.

Why should corporations care? Two words "litigation exposure." A bot-net living in your network takes down an e-commerce site for day. They will see you in court. Good luck with that "don't blame me, blame my ISP" defense.

I think that kind of "not my problem" thinking is what is driving the current cloud computing craze. Corporations seem to think that they can side step the accountability hassle if they outsource IT to the cloud. Good luck with that too.

I'm going to have to call "NPOV violation" on that one... it's a list of their losses, while their wins have gone unmentioned.

As an IT professional with 15 years of IT experience I say that you do not need any Math beyond most rudimentary arithmetic and some statistics used in spreadsheets and reports. If you need to calculate something and to figure out formulas you will likely use Google or a mailing list. Even logic as programming logic is pretty basic and far away from predicate calculus that one studies in school. One may say that this may change but for millions of COBOL, VB and Java programmers nothing has changed about this in the past thirty years, except that you may only need less math now.

As a PhD student in CS who *has* to be good at Math both for theoretical work and for the craft, so I have few advices to offer gathered from personal experience, learning and exploration:

Most math ever required to be decent at Computer Science is concentrated in the (hybrid) field of mathematics called Discrete Mathematics. If your skills are strong enough to know this field well then you are set. In addition, you should probably be good at series and limits as they are fundamental to asymptotic analysis and at linear algebra.

As an admirer of Math I can tell you that the most fundamental skill for Computer Science is Mathematics. True, fundamental Computer and Computational Science is Mathematics. To be really good at CS you need to be strong at Set and Number Theory, Probability and Statistics, Calculus through Differential Equations, Graph Theory and Linear Algebra.

Regards,
Edmon
My blog entries on math and science are here.

That is possible if I read this right. http://it.toolbox.com/blogs/php-bsd-me/the-mysql-license-8922
It would leave any closed source licensed versions dependent on Oracle or force them to carefully separate out their code from mysql so they can use the forked version.

I would use Postgresql http://www.wikivs.com/wiki/MySQL_vs_PostgreSQL since it's standards compliant, feature full and is fast if properly configured.

From a technology perspective, you are correct. The only justification for cloud computing is economic and that makes sense only if your web and db resource usage fluctuates wildly and unpredictably.

This story is less concerning when you read this two week old story from the NY Times (which I blogged about here) that talks about this trend where the R&D centers for major companies federate their pure research efforts amongst each other in order to increase efficiency and save money. Even though they are spending less, it doesn't mean that they are doing less.

Don't forget Stac Electronics, Microsoft fucked them over real good too on their way to the top. Then there is their history of subtlety (or overtly) fucking around with specifications specifically to cause pain to their own customers who dare to choose to use non-Microsoft products. For example the DHCP "bug" in Vista, the 500mb memory check in Windows 3.1 (which broke IBM's then-fairly-successful OS/2 for Windows product), their incompatible kerberos strategy, their undermining of Java, their web page editors that made pages look fucked up in non-IE browsers.

Microsoft has justifiably earned the hatred they receive, it's not like this aggravation with them happened for no reason.

I'm sure there are others that I'm missing but the very idea that mac laptops aren't "premium" is ridiculous. You can argue that the set of features that you get are not worth the price, but one can make the same argument about "premium" cars as well and has nothing to do with if the object itself has a feature set above and beyond the average.

Probably the most cogent analogy I can think of is cars. For the most part, an Acura is a Honda. Indeed a good majority of Acura parts are actually Honda parts. But an Acura costs more and people are willing to pay for them than a Honda. To some people who only fixate on pricing that seems ridiculous as they equate the two as the same therein lies the problem. An Acura is similar but not identical to a Honda. If you ignore the details, an Acura TL is the same as a Honda Accord but that's using a flawed comparison.

That's the same difference between an Apple laptop and any other laptop. No two laptops models are ever really the same even by the same manufacturer. Apple has put more into the fit and polish than other manufacturers. Apple has targeted the middle of the market to the high-end premium. They do not want a part of the low-end market as they know they cannot compete with the Dell, HP, etc.

For some people, Apples are simply "prettier" and they are willing to pay for that. For some people, Apples are less hassle and they are willing to pay for that. For others, Apples don't have the processing power, HD, whatever, that they want and they are not willing to pay for that. The real point is it is really up to the needs and wants of the customer. Discounting Macs are more expensive for no reason is another way of saying that value only means money and you can't understand that value might mean other things for other people. For other people value can mean time, ease of use, aesthetics, etc.

Take for example why do some computer security professionals use Macs? It's not because they think Macs are cute. With a Mac they can run Windows, Unix, BSD, Linux, etc which is very beneficial to their job. On the other end, why do professional photographers use Macs? It's because they don't care to get involved with the intricate details of maintaining a computer. Most of them are not technical. They want to worry more about the color saturation of a photo rather than drivers for their camera.

And Aster nCluster is PostgreSQL based. Yahoo's "homegrown system" also started with PostgreSQL.

Yep, there was definitely a jump in postgresql around that time too, but the slope for MySQL appears to have gone up. There wasn't any sort of mass exodus from MySQL to PostgreSQL.

Maybe some of that was people afraid of what would happen to MySQL as a result of Sun's acquisition but it could also be a result of Sun providing support for PostgreSQL and including it in Solaris 10. Around June 2007 there was a big spike and that was when Sun came out with the first industry standard benchmark Sun put out with PostgreSQL, Sun Java App Server on a T2000 UltraSPARC T1 server.

I could really care less what happens to MySQL, I'm more concerned what happens with Sun's future contributions to PostgreSQL.

Shouldn't they just get some comedians to point out how Apple is full of chic jerks and PC's are where real computing is done?"

Depends on how you define "real computing". It is becoming more apparent that more security professionals are using Macs. As someone who has used and managed Linux, I bought a Mac because it does the job I need it to do without the maintenance my PC needs or the tweaking that my Linux boxes needed.

It's difficult to remember something that isn't true.

http://it.toolbox.com/blogs/managing-infosec/linux-hacked-more-often-than-windows-2003-23371

It takes more than excited zeal to keep a system secure.

...he does raise the point that Microsoft will only issue fixes for certain customers.

Anyone can request a hotfix. Every copy of Windows purchased within the last decade is supported.

At least with open source you can patch problems on your own, even if the owner does not wish to or even goes out of business.

Did you know that that violates your support contract? If you should choose to do that, you've forfeited your rights to hold RedHat or Novell or whomever your vendor is liable in case of a major support issue-- they no longer have to hold your support contract valid. I don't think some amateur hacked solution is worth the loss of your vendor's liability.

It's client-server all over again? Umm. Yeah? So?

So, what happens when you can't get to the server because there has been a fire in your data center? Or, a crucial fiber optic center? Or, a meteor could be involved.
What do you do when your server, or your customer's service, is unavailable for a week or three?

The hack seems already quite old now, I found this 3-years old post : http://it.toolbox.com/blogs/puramu/javascript-hack-to-display-your-browsing-history-12694 Proof of concept : http://ha.ckers.org/weird/CSS-history.cgi

Note that 5 and 6 are only less of a threat if compiled with a compiler for which you have the source code. But hold on, how do you compile your compiler? You better do it by hand:

http://it.toolbox.com/blogs/puramu/ken-thompson-and-the-selfreferencing-c-compiler-16142

Not meaning to be 'dork' about this, per my subject line, but... pointing out some facts:

New MacOS and Linux virus found in the wild:

Per my subject-line? Linux does INDEED, have viruses (no immunity, sorry to blow your 'illusion'):

http://it.toolbox.com/blogs/locutus/new-macos-and-linux-virus-found-in-the-wild-15440

From 2007... but, point IS there (for both Linux AND the MacOS X too)

APK

P.S. => Also, from the "POV" of say, a botmaster or otherwise misguided person - THINK about this, for a second:

Say, YOU were out to 'make monies' suckering others via botnets etc. OR, just out to "blow their machines" & do other mischief... wouldn't YOU attack the largest block of users out there, & those possibly/potentially less "technical" than a std. *NIX head might be??

(After all, isn't *NIX & its variants GENERALLY the province of more "geeky types" (excepting MacOS X that is, it's built to be "useable by gramma" etc. et al), that most likely could not ONLY shut the damn thing down & spread it to others quickly in the *NIX community how to do so, but also, attack back...? You'd most likely avoid them...

Thus, Windows IS going to have more of this happening, because it's more used. Plus, javascript + iframes (biggest attack vectors there is via webbrowsers &/or email programs no less the past 3-5 yrs. now)... do they run on LINUX &/or *NIX in general? Yes, they do. You're, in theory, JUST as vulnerable... just not as oft targetted... apk

Well maybe someone should port COBOL onto a JVM, and also the rest of the mainframe style environment it needs.

You mean like this?

Monty's been working on the interesting "Maria" transactional engine (evolved from, and compatible with MyISAM), which is slated to become MySQL's future default engine.

Since they recently made a feature-complete ("no known bugs"!) release of Maria, I'm tempted to think that was his personal deadline to quit.

Josh Berkus (core PostgreSQL developer) also recently quit Sun.

I like Sun. I'm sad that they have lost these two brilliant database engineers, and I hope they go on and kick Oracle's (and that other company's) butt anyway.

Monty's been working on the interesting "Maria" transactional engine (evolved from, and compatible with MyISAM), which is slated to become MySQL's future default engine.

Since they recently made a feature-complete ("no known bugs"!) release of Maria, I'm tempted to think that was his personal deadline to quit.

Josh Berkus (core PostgreSQL developer) also recently quit Sun.

I like Sun. I'm sad that they have lost these two brilliant database engineers, and I hope they go on and kick Oracle's (and that other company's) butt anyway.

You may have said that as a joke, but Comcast is one step ahead of you. http://it.toolbox.com/blogs/managing-infosec/comcast-wants-to-put-a-video-camera-in-your-television-set-top-box-23242

I would think for most consumers, they don't care about the OS and couldn't tell you the difference between X11 and xfs. Can I surf the web? Write documents? Play music and video? Consumers care about function and form. Having some aesthetic appeal helps.

If you look at college campuses, you're starting to see that Macs are becoming more prevalent than PCs now. As generalizations go, many Windows users buy Microsoft because they don't know there exist alternatives. This is starting to change with Linux and OS X. There are indications that more computer security professionals are using Macs due to the their ability to run Windows XP, OS X, Linux, and BSD. These professionals could easily run whatever they wanted but have chosen OS X.