The hard drives are usually IDE, although some high end models may still be using SCSI. Video output is SVGA. Slots are PCI and AGP. I don't recall what type of memory it uses, but third party memory modules are a LOT cheaper than getting it through Apple.
IIRC, there are drivers for the Voodoo 3 for Mac... NVidia is supposed to be releasing Mac drivers soon too I think...
< /lib is bogus. libc is bogus./etc is bogus. password files are bogus./dev is bogus. There are huge assumptions built into the codebase about a number of fundamentally bogus things, from the bogus filesystem hierarchy to the bogus libraries to... you guessed it... the necessity of a command line and a terminal. And curses, no less! >>
First off, the directory heirarchy has been rearanged into something that makes much more sense. Second off, you never need to access a commandline in the upcoming MacOS X. Period. End of discussion.
The commandline is there only for those who want it. ALL administrative tasks can be handled (and indeed, are BEST handled) from the GUI.
<<Not that I don't love Unix anyway. Not that I don't use it every day. But if you think millions of Mac users are going to start loving it because Steve Jobs tells them to... you are going to have to give me your dealer's phone number. >>
From the perspective of a Mac user, not that much has changed. You have Aqua, and you must log in, and there's more stuff that you can configure but that's about it.
<<Or is some of it still going to leave people having fits? >>
Apple has done a remarkable job of hiding what little is left of "Unix" under the GUI.
<<These "little details" matter. It needs to be disabled by default, in acknowledgement of the fact that an overwhelming majority of users won't use it, and could in fact get bitten by it. A million little details occur to me. Multi-user computers are fundamentally more complicated than single-user computers. That's complexity no one should have to put up with unless they ask for it. And even if they demand it, woe to the person who should offer them the unix security model in return. >>
First off, the added complexity of having to log into a Mac is trivial. You double-click your name, and type or speak your password. Anyone who has ever used an e-commerce site is familiar with the concept.
Second off, while under the hood a multi-user system is fundamentally different, the end user experience need not be very different.
My parents are using an iMac with MacOS 9, set up for multi-user login. They have no problems with it. They log in, and then from then on it is just a Mac.
The best way to keep them interested is to give them what they need to get results quickly.
Start them in a language that has little infrastructure overhead, such as Visual BASIC, or Perl... Nothing with #includes and everything wrapped in a function and all that... Save that stuff for later.
Whet their appetite by accomplishing little things first. Start with teaching them to write a "guess the number" type game perhaps.
As they absord that -- and they will absorb it quickly -- move on to new stuff.
Once they have a sufficiently broad set of "tools" at their command -- basic flow-control (loops, conditionals...), I/O (producing output to the screen, reading user input), variable manipulation -- you can introduce more complex concepts.
It'll be a while before they understand *why* "goto" is generally bad, functions are good, and encapsulation is neccesary to ensure one's sanity but they will gradually get there.
The really tricky part is presenting this with correct timing. Don't go too fast -- they'll get confused -- but don't go too slow -- they'll get bored. And as above, any kid is going to get bored if they can't recognize progress and accomplishment in their efforts.
Actually, XFree86 4.0, and the numerous extensions to X are gradually transforming it into something pretty reasonable. However, dumping it entirely isn't an option, unless everyone starts using Qt or GTK -- since those can be ported to other GUI systems.
>
Windows 2000 already enjoys that title.
>
Yes. You didn't read the Ars Technica article, did you?:)
>
You assume that backwards compatibility and the elimination of the "ugliness" of a commandline-first system are mutually exclusive. They are not.
MacOS X has a shell, and has all sorts of commandline tools available for it. DP4 includes a GUI-based development environment which seamlessly relies on gcc and gdb. The developer need never touch a command line. The user need never touch a command line.
You can however download all your favorite commandline programs, compile them, and run them to your heart's content.
>
Read the Ars Technica article. Library handling is RADICALLY different, and eliminate most of the problems commonly associated with shared libraries. Configuration files are in XML. The filesystem has been restructured.
>
Agreed. But in this case, Apple is producing a better Unix, and a better MacOS all at once. All the cruft from Unix/BSD is being eliminated, the interface is modern, administration can be done ENTIRELY from the GUI.
>
MacOS 9 already supports multi-user desktops. I set up my mom's iMac so that she and my dad have seperate logins and can't screw things up. They double-click their names, speak their password and go ff to do whatever they want. I have an account with admin priviledges...:)
I have heard many things that encourage me that Apple understands this, and may therefore be the first to create a Unix-stable, xerox-style operating system. I have also seen many things that discourage me, because they indicate Apple is buying the benighted notion that BSD-compatibility is worth a damn to their business. It is not. Let me repeat: it is not. And furthermore, it will eviscerate the utility of the MacOS. Do you hear me, Tevanian? Hide that damn shell. Hide it somewhere where we will never find it.
Unix users are smart, self-reliant people. We can find plenty of ways to get our jollies without mastering our problems onto millions of MacOS CD's.
Consider your motivations and look for the path that will make you happiest.
If curiosity is your motivation, then the best path to take is that which affords you the most opportunities to learn. If money is your motivation, find the fad-of-the-week and latch onto it with a deathgrip. Wash, rinse, repeat next week.:)
Always reevaluate where you are and try to determine if you are happy, and whether your current path will lead to more, or less happiness.
<<It's easy to argue that this isn't Microsofts fault, until you compare it to GM shipping products that failed so badly in crash tests.>>
In the case of things like the Melissa virus, this makes sense. But this is not such a case.
This has nothing to do with Outlook, or how it was designed.
The way ILUVYOU works is to send an e-mail with an attachment: A standalone script written in VBScript.
<<Windows can't be locked down enough to stop this stuff, ergo, it's intrinsically faulty.>>
What can you do on Linux, or Solaris to stop a malicious shell script, or Perl script attached to an e-mail?
If the recipient chooses to execute the script, then he or she will be subjected to whatever any other program can do.
The ILUVYOU script is smart enough to read Outlook's address book, but it could as easily read any other e-mail program's address book. ILUVYOU also interacts with mIRC to spread itself that way. Is mIRC at fault? Of course not.
The only "solution" would be to run every single program in the OS under a sandbox. That's not a realistic option, even if you could write a provably secure sandbox.
This worm could as easily have been a Windows EXE file. There is no functional difference here.
NT, like *nix has file ownership constraints that limit the extent of the damage that can be done. That's all that can realistically be done.
I'm not exactly a fan of Microsoft, but given that *nix is susceptible to the exact same sort of attack, I can't blame them here.
First off, leadership does not neccesarily mean establishing new proprietary ways of communicating with clients. Linux could become a leader in clustering and high-availability solutions. It could become a leader in web application development/deployment platforms/tools.
There are many ways Linux could innovate and jump ahead of the pack. But that's not neccesarily a good thing.
Right now, Open Source has to play catch up because there are serious areas which it is deficient in. It is tempting to postpone development in those areas, or to begin cool new development in other areas but that isn't what we need.
Let other companies take the risks and fight the big battles. I'm more than content to have Linux take the winning protocol/standard/whatever and implement it better than the commercial OS that championed it.
But I don't object to anyone doing what Open Source is about: Scratching an itch. If someone needs a revolutionary new way of sharing data between clients, or a revolutionary new web application platform, be my guest! Innovate to your heart's content. Do it because you need it, but don't do it just because you want to be ahead of Microsoft.
Melissa and other such virii work by infecting Office documents with malicious code. You can attribute this then to Microsoft for at minimum, not taking proper precautions with what an Office document can do.
ILUVYOU on the other hand, is a standalone VBS script. It is not part of an Office document. Being such, it really is no different than any other executable.
The ILUVYOU worm would work on any Windows based e-mail program that followed the association of.VBS files to Windows Scripting Host -- not just Outlook. The worm's author simply chose to read your Outlook address book however. It could have as easily been your Eudora address book, but realistically, more people use Outlook, making it a better choice of attack.
yeah, but how much does mySQL slow down if you want to avoid table corruption? oh wait, unlike DB2, you can't avoid it.
I've NEVER seen unrecoverable table corruption in MySQL. In the DB2 instance, a table would be completely obliterated if the script accessing the table crashed before it disconnected the database handle. Oops. No ability to recover AT ALL, thanks to the fact that turning the journal off is what caused the instability.
Fast and decently reliable is good enough for some tasks, but for almost all non-web, and a good bit of web applications, MySQL is a square peg in a round hole.
I agree that for many non-web tasks MySQL is not well suited. At least for so-called "enterprise level" stuff. MySQL can be used to fill smaller niches even in that arena though.
I've only ever been involved in one web application where MySQL was not well suited, and that application classified as a traditional "data mining" type application.
This sounds like an application that could be better handled by LDAP instead of an SQL database. Hogwash.
I have a suspicion that the people who safely use MySQL would be better off using LDAP, because their applications are heavily oriented towards reads Actually, our application is heavily oriented towards *writes* which is why we use MySQL. 30x faster for our situation than the best alternative. (DB2)
We did use LDAP at one point, but performance and scalability were non-existent. We had to scramble to move to MySQL when we started getting around 50,000 page views/day -- the LDAP system couldn't handle it. Now, with MySQL we handle 2,000,000 page views a day, with several products instead of the one product we had at the time. (web based e-mail client)
If we were to implement something that required more than a few updates per minute, we would look into PostgresSQL or Sybase but as it stands now MySQL is the hands down winner.
My company's benchmarks indicate that MySQL is faster for inserts than DB2 (widely regarded as being a bloody fast database) by a factor of 30x. Higher if you want to avoid table corruption in DB2. (we had to turn journaling off to get the best performance)
-JF
Re:Spot on... OpenSource is the issue
on
Why Not MySQL?
·
· Score: 2
MySql is _not_ OpenSource
I guess if you don't consider the GPL to be an open source license, then your statement makes sense. While TcX doesn't release the current-stable series under the GPL, they release older generations under the GPL. You can get MySQL 3.20.32a under the GPL right now. When 3.23.x becomes the official stable series, I'll bet you'll see 3.21.33 be GPLed.
TcX has been developing MySQL for years without "raising the price." Even if they did, so what? You still get the source, and they still publish older stable versions under the GPL.
As for PostgreSQL... Until it becomes *stable*, *fast*, and supports *outer joins* I find it an unworkable solution.
FFT calculation, and graphic generation, for example are not going to go fast no matter what.
In web applications, such complex calculations tend to be the abnormal case.
All Apache-mod_perl does is remove the over-head. Well, there is very little overhead to perl to begin with.
Absolutely false. There is a great deal of overhead to forking and execing Perl. And mod_perl does MUCH more than merely eliminate that overhead. mod_perl gives you the ability to do things like database connection caching and provides access to Apache internals giving your script more information and more control.
I've run all sorts of comparisons between java and perl, and for small - medium sized scripts, compilation is barely noticable.
My company has 70,000 lines of Perl code. Compilation time is significant.
The slowest parts tend to be in database reconnections, forking off seperate processes to do simple operations like file grepping, finding, etc.
First off, nothing will compensate for poor code. If you are using mod_perl, you can cache database connections. Forking a process to grep a file, or find a file -- that's ludicrous! It can be done trivially in Perl.
but I found that the same algorithm would run incredibly slowly in a java-servlet world because of the un-optimized string parsing in Java.
There are regex engines for Java that provide much of the performance and flexibility of Perl.
But if I redesign the java-system so that it uses a truely optimized 'parser' then I can get better performance than even in perl.
Of course. And there's probably a better way to do the Perl version too. There's *always* a more efficient way of doing something. And there's always a less efficient way.
The only problem is that you have heavy context switching, as opposed to the light-weight context switching of a threaded model ( such as java-servlets).
Apache 2.0 addresses this issue allowing a hybrid solution. (Multiple processes with multiple threads)
Another issue with process segmented workers is the redundant usage of memory and thus the propensity to Virtual memory thrashing. You, of course, always want to put more than enough memory in a server, but you also would like to cache as much of the web site as possible. If you were to scale to 50 workers, your memory contension would be well beyond that of a CPU-cachable range. Much Perl code can be pre-loaded into the parent Apache process allowing it to be shared among processes. Thanks to the joys (grr) of copy-on-write, it gradually gets unshared -- a fault of Perl intermingling code and data -- but tuning process lifetime can alleviate this.
For small-scale operations ( Apache-Front-end, HTML-rendering, Business-logic, database-back-end ), where the business-logic is minimal, you can use mod_perl with apache and have the DB on another computer and you have plenty of scalability. To my understanding this is exactly slashdot. It is when business-logic becomes comparible in resource requirements to the other elements that perl really falls short.
My company handles 2,000,000 page views per day. Most of that is our web-based e-mail client. (heavily customizable/cobrandable!) We're growing at as much as 40% per month. We handle 1,500,000 mailboxes. We use Apache, mod_perl, and MySQL. With careful design our system ust keeps getting faster and faster.
It's hard to farm out CPU cycles to other machines or CPU's. That depends on how well you designed your code. We have no such difficulties. I believe we have 11 web servers handling our e-mail client, 6 or so handling our message boards product, and a handful serving our search and chat products. (Both of those are in Java -- but receive trivial usage thus far...)
And if your logic serializes access to data ( via DB row/table locks ) then the ability to finish business logic computation really starts to stand out like a soar thumb.
That problem really depends on your RDBMS. MySQL is not well suited to such situations, but Oracle and DB2 handle them fairly gracefully.
Perl just doesnt show up in the enterprise model, or even the real service model beyond the simple form entry services like slashdot.
I must take exception to that statement. My personal site, my previous employer (BrainPower -- now out of business unfortunately), my present employer (Everyone.net) all use(d) complex business logic rules and all have found Perl to perform quite well when properly managed.
A web based e-mail client does not classify as a "form entry service." Our inter-company communication/integration protocols are also Perl based with great success.
Java was designed with all of this in mind, they just don't always achieve their goals completely. If you can get over Java's screwy I/O model. No asynchronous I/O? Come on! One should not be forced to take on the overhead of threads for synchronous or multiplexed I/O. It's become a pain in the neck for our search product. We have to spawn 20 or more threads to do a meta-search. That's all well and good until you have a thousand people doing it at the same time!
I'm really tired of hearing the "Well [x] is a great toy for small companies/sites/whatever but when you want real power and performance use [y]." That argument has been used by Sun and Sco to describe Linux, by Python, Java, and other language advocates to describe Perl, and in many many more cases...
I stand by my experiences. BrainPower: data mining application. MrJoy.com: Customizable news and community site. Everyone.net: Cobranded, web based e-mail, community (message boards), search, and chat. With much more on the way.
This is false. Apache with mod_perl runs at the same speed as Apache -- the combined speed of your computer, network connection, disk, etc. Yes, you can write slow mod_perl stuff (if you use it as glorified CGI), but mod_perl itself has no such limitations.
The real problem is memory overhead. Our mod_perl processes can reach 20-30MB each. But then again we have 70,000 lines of Perl code...
Normally I agree with most of what Jon Katz says. Such is not the case with this article.
Jon Katz whines about 330,000 users having their "privacy violated." And some of them are kids. My god! Think of the CHILDREN! That should be your first clue that he's full of hot air.
The firm Metallica used to find these "kids" didn't do anything the kids themselvesdidn't do in the process of findind the music they stole. They did searches -- but the firm wrote down the usernames of people they found rather than actually downloading stuff.
Metallica would be *entirely* justified in adding these 330,000 law breakers (and make no mistake, that is *exactly* what they are!) to their lawsuit, but they have not. They have strated that they will not. Instead, they simply ask that Napster obey their own publicly stated policy of blocking known pirates.
You can argue until you are blue in the face that record companies are greedy, glutonous pigs, but the fact is that the law gives them certain rights over the material they produce.
Metallica's actions have proven to be incredibly mild compared to what they *could* be doing. They are taking measures to stop hundreds of thousands of pirates right now (without hauling them off to JAIL, where they legally belong!) and trying to stem one of the big causes of the problem in stopping Napster.
Napster is not a good thing. It is JUST a tool for piracy. It does not legitimize online music, it legitimizes piracy -- the THEFT of other people's work. And why does this tool exist? Why does it prosper? Because we all have this entitlement mentality. We are *entitled* to music. Why should we have to pay for something which musicians work hard to make, which record companies spend lots of money to promote and distribute...
Katz: Stop whining. Nobody's privacy got violated. If you are standing in a crowd you cannot reasonably expect privacy. Likewise, if you are letting people download files from your computer, you cannot reasonably expect privacy. Metallica's actions are NOT heavy handed. The RIAA's actions against My.MP3.com are heavy-handed: They are using the letter of the law to crush competition despite the fact that no actual piracy has been committed. Metallica on the other hand is witnessing more piracy occur in *one day* than has likely happened in the past *10 years*. (before Napster)
-JF
Freedom vs. Reality (or: Scorched earth approach)
on
Thus Spake Stallman
·
· Score: 1
Freedom freedom freedom. Give me my freedom. Damn the cost!
I'm a very big fan of Open Source, and the benefits to me as a consumer it generates. I am not such a big fan of Stallman's zealotry.
Stallman and the Free Software model fail to recognize that people, and companies put a great deal of effort, energy, and time into their works. His goal of making all software be Free Software (by annihilating non-Free Software) is absurd.
His goal would kill the commercial software industry. Every piece of software we use would be made by volunteers who worked on it when they felt like it. Which may be less often than people realize -- if the intellectual property industries are annihilated, we'll all be working blue-collar jobs.
Yes, many Free Software projects are very very good. Better even than their commercial counterparts. But the Free Software movement has shown itself to be nowhere near as good at certain things as the commercial software industry.
Example:
The Open Source/Free Software/Linux/BSD communities have shown themselves to be incredibly arrogant when it comes to end users' ("my mom") needs. It's only in the past couple years that a serious effort has been made to produce an operating system that can be used by end users. Previously the prevalent attitude was "well, if they wont take the time to read my 30MB of man-pages, they can go to hell." But now, we have collectively set our sights on toppling Microsoft and so we have to fight them on their own ground: Ease of use.
How "free" can one be, if one cannot even access the tools that you have so kindly "liberated" for them?
For all the bad they've done, Microsoft and Apple have done a great deal of good: They've made PCs accessible to the "average" person.
The reality is that we need companies to produce the things which we as a community do not *want* to produce, or *cannot* produce. Unfortunately, Stallman's unwillingness to compromise, or to work with the "other side" is a scorched earth policy. Most software companies would go down the drain, the few that remained would be dependent upon venture capital, and community-written software.
Redhat is great and all, but Gnome isn't exactle knocking Windows off the desktops en masse.
Stallman will be viewed as a zealot and a nutcase until he recognizes that software doesn't appear out of the ether. It *costs* people to develop software. Whether that cost is in time/energy/effort, or good old fashioned money, people deserve to be compensated for their expenditure.
People may even deserve the freedom to earn a little profit. But that freedom of course conflicts with the Free Software movement's goals.
You have to consider what they *want* the information for. *WHY* do companies want demographic information about you? Once you understand this, it doesn't look nearly as scary.
My company for example, asks for all of the above plus (optionally) information about how much you make, your occupation, what industry you are in, and your precise address. Why?
It isn't as useful as one would think for "tracking" you. Even if you *don't* provide a site with that information, they can analyze their log files to see what people are doing (most log analyzers even list the "top paths through site") and of course, cookies can make even more precise tracking possible.
Companies don't care about *YOU* personally. There is nobody sitting at some desk somewhere saying "Aha! John Smith likes McDonalds!" Most uses of demographic information are *more effective* if you as an individual are ignored.
All demographic information is useful for is/targetting/ things to you. I looked at a bunch of Transformers auctions on Amazon.com, and all of a sudden when I go to Amazon.com I'm greeted with a list of Transformers auctions, books, movies, and such. Cool! Saves me some effort. I haven't paid much attention, but I'll bet the banner ads they show me are targeted at kids and toy-afficianados.:)
There's really not as much to this as you think. It's simply an extension of customization. How many of you customize your Slashdot page to show the SlashBoxes you like? Well, that's the same thing: You're giving Slashdot demographic information about you. The fact that you're logging in lets them uniquely identify you.
Ok, so they can't identify you in meatspace, but so what if they could? Are the black helicopters going to land in your front yard? No. At *worst*, you might get a little more junk mail -- targetted to stuff you've shown you're interested in.
BFD.
There are abuses of privacy, and privacy does need to be protected, but many of you are too over-sensitive about this issue. You don't make a distinction between *good* and *bad* uses of personal information and you overlook the fact that most of you just throw such information at web companies without thinking twice about it.
It basically explains how at the time Netscape was in big big trouble and covers the open-sourcing of Mozilla... It culminates with the AOL-Time Warner deal...
It has interviews with numerous Netscape employees -- including then-employee Jamie Zawinsky (blue hair/nails and all...) -- and tells which ones quit and roughly why...
I enjoyed it quite a bit... Made my parents sit through it -- especially the interview with Pavlov's parents...:)
Actually, the specified option does precisely that. The "originating server" is considered as the server that the page came from, not the server that the image came from.
Netscape 4.x has an option which will let you allow cookies only from the domain which they originated from. Images, while they may be grabbed from another domain are considered to be within the "domain" of the whole page.
So if I'm at foo.com, and foo.com/index.html has an IMG tag linking to doubleclick.net, doubleclick.net's cookie will not be sent back to doubleclick.net.
I don't recall if it will just be sent back to foo.com, or if it goes into the bit bucket...
Not all information needs to be archived. Most of the e-mail I receive can go in the bit bucket for all I care. The rest, I archive. As for the information that can/should be archive, the author's statements to the contrary, industry standards can be used to archive what should be archived.
Given a format that is a) adequately documented, b) accurately represents the data it encompasses, and c) has sufficient widespread adoption, we can simply archive to that format as we need to.
Let's consider various and sundry data types, the prominent format for handling them, and the potential longevity of those formats.
Text: For raw text of course you have ASCII. While not a permanent fixture, nobody can argue it's longevity. We'll call this the baseline. Moving up from ASCII you need some way of defining formatting and such. There are really only a couple realistic solutions. Either some SGML based system, HTML, or PDF. I'll get into the latter two cases a little further down. Let's say that for plain text, SGML has the best longevity because of widespread adoption, and simplicity.
Rich Text (beyond simple formatting): As above, we need something better than ASCII. I'll vote for PDF here. It's a proprietary format, but it seems to be pretty well understood, and it does an accurate job of representing the original document. Mac OS X groks it very well, and Adobe has ensured that there's a viewer for every platform. If conversion tools can be made, then this is a good format.
Images (bitmap): PNG, JPG, GIF, and TIFF. TIFF seems to be less relevent these days although most scanner software still produces it. JPG/GIF are where the majority of data presently exists, and PNG is where everything should be archive, IMHO... PNG being lossless, and supporting about every feature known to man, this seems to be the best solution. One could crawl the web, grabbing every single GIF or JPG, archive it to PNG format with no loss of data and quickly build a significant archive.
Image (vector): Sorry, don't know much about the formats used here...
Audio: The obvious solution for archival is uncompressed, raw audio in a well understood format like WAV. This is an area that doesn't seem to be changing much...
Video: Again, I can't really comment on the formats here...
Things become more complicated when you have interactive media, or other very specialized forms of data... But I'd rather save that for the experts...
The author brings up the "loss of fidelity" issue when updating documents to a new format. I think this really only is an issue when making a lateral move. Converting from JPG to PNG wouldn't be a problem, nor GIF to PNG. Converting from WordPerfect to Word on the other hand, is problematic at best...
Thus the need for archival formats with some longevity. Perhaps a commission should be formed on data archival formats? A group of OSS developers who do nothing but strictly define what format(s) are to be used for "data archival" purposes, and ensure that tools to read/write these formats are readily available on every platform -- including new ones as they come out.
The trick is to avoid lateral conversions at all costs.
I wish they would use Oracle, and then maybe they wouldn't have to flush all the past stories and comments (i.e., the whole database would be searchable). I would imagine the reason they do that is that MySQL is not known for scaling up to large databases.
This is something of a myth... MySQL can actually handle very large tables quite well. It's problems are with lock contention... Instead of page or row level locking, it uses full-table locking which creates a bottleneck. This however has more to do with volume of users than volume of data.
Now, I'm not sure why Rob purges the old data, except perhaps as a matter of "hygiene" because properly designed MySQL databases would have no problems handling it. At least, if one is using the latest versions of MySQL which support >2GB tables on Linux...
Oracle on the other hand is as much as 14x slower than MySQL, and has serious performance issues with things like connecting to the database. You absolutely must use database connection caching to get acceptable performance. Not to mention the obscene pricing...
Even DB2 which is orders of magnitude faster than Oracle, and orders of magnitude cheaper than Oracle is not neccesarily well suited to a Slashdot style system...
MySQL is actually really good for many web applications... And it's few problems can be overcome (like splitting your tables up -- x becomes x1, x2, x3, etc...) in most cases...
Corel announced their involvement with the WINE project a very long time ago... Nothing appeared to come of it however. WINE made steady, incremental improvements but no major progress...
With any luck, this version will have some noticable improvements... Bearing in mind of course that this version was undoubtedly used to help port Corel Office 2000 to Linux...
In Silicon valley, many of the best software engineers don't have formal education. And many of the worst have degrees from prestigious universities.
I believe most places that have restrictions on the use of the word "engineer" are in the context of civil engineering. I am not a civil engineer.
But whatever you want to call me -- programmer, software engineer, or walking-talking-orange -- I work for Everyone.net. I spend my days writing code for them, and I spend my nights writing code for myself. I know the person running the giveaway: his motivations, and his intentions.
Therefore -- arguments about semantics aside -- I feel confidant in saying that it wont be used for spam.
Re:Collecting E-mail adresses? For spam?
on
Win an AIBO
·
· Score: 1
Selling or renting the list would be using it for spam. The list will not be sold, rented, or in any way used for spam. The rules specify exactly how the list will be used: Your friends' addresses will be sent one e-mail (which you can compose, or you can leave it to us) to tell them about the giveaway. You will receive one e-mail with the giveaway outcome.
Slashdot Mirror
The hard drives are usually IDE, although some high end models may still be using SCSI. Video output is SVGA. Slots are PCI and AGP. I don't recall what type of memory it uses, but third party memory modules are a LOT cheaper than getting it through Apple.
IIRC, there are drivers for the Voodoo 3 for Mac... NVidia is supposed to be releasing Mac drivers soon too I think...
-JF
</lib is bogus. libc is bogus. /etc is bogus. password files are bogus. /dev is bogus. There are huge assumptions built into the codebase about a number of fundamentally bogus things, from the bogus filesystem hierarchy to the bogus libraries to... you guessed it... the necessity of a command line and a terminal. And curses, no less! >>
First off, the directory heirarchy has been rearanged into something that makes much more sense. Second off, you never need to access a commandline in the upcoming MacOS X. Period. End of discussion.
The commandline is there only for those who want it. ALL administrative tasks can be handled (and indeed, are BEST handled) from the GUI.
<<Not that I don't love Unix anyway. Not that I don't use it every day. But if you think millions of Mac users are going to start loving it because Steve Jobs tells them to... you are going to have to give me your dealer's phone number. >>
From the perspective of a Mac user, not that much has changed. You have Aqua, and you must log in, and there's more stuff that you can configure but that's about it.
<<Or is some of it still going to leave people having fits? >>
Apple has done a remarkable job of hiding what little is left of "Unix" under the GUI.
<<These "little details" matter. It needs to be disabled by default, in acknowledgement of the fact that an overwhelming majority of users won't use it, and could in fact get bitten by it. A million little details occur to me. Multi-user computers are fundamentally more complicated than single-user computers. That's complexity no one should have to put up with unless they ask for it. And even if they demand it, woe to the person who should offer them the unix security model in return. >>
First off, the added complexity of having to log into a Mac is trivial. You double-click your name, and type or speak your password. Anyone who has ever used an e-commerce site is familiar with the concept.
Second off, while under the hood a multi-user system is fundamentally different, the end user experience need not be very different.
My parents are using an iMac with MacOS 9, set up for multi-user login. They have no problems with it. They log in, and then from then on it is just a Mac.
-JF
The best way to keep them interested is to give them what they need to get results quickly.
Start them in a language that has little infrastructure overhead, such as Visual BASIC, or Perl... Nothing with #includes and everything wrapped in a function and all that... Save that stuff for later.
Whet their appetite by accomplishing little things first. Start with teaching them to write a "guess the number" type game perhaps.
As they absord that -- and they will absorb it quickly -- move on to new stuff.
Once they have a sufficiently broad set of "tools" at their command -- basic flow-control (loops, conditionals...), I/O (producing output to the screen, reading user input), variable manipulation -- you can introduce more complex concepts.
It'll be a while before they understand *why* "goto" is generally bad, functions are good, and encapsulation is neccesary to ensure one's sanity but they will gradually get there.
The really tricky part is presenting this with correct timing. Don't go too fast -- they'll get confused -- but don't go too slow -- they'll get bored. And as above, any kid is going to get bored if they can't recognize progress and accomplishment in their efforts.
-JF
>
:)
:)
Actually, XFree86 4.0, and the numerous extensions to X are gradually transforming it into something pretty reasonable. However, dumping it entirely isn't an option, unless everyone starts using Qt or GTK -- since those can be ported to other GUI systems.
>
Windows 2000 already enjoys that title.
>
Yes. You didn't read the Ars Technica article, did you?
>
You assume that backwards compatibility and the elimination of the "ugliness" of a commandline-first system are mutually exclusive. They are not.
MacOS X has a shell, and has all sorts of commandline tools available for it. DP4 includes a GUI-based development environment which seamlessly relies on gcc and gdb. The developer need never touch a command line. The user need never touch a command line.
You can however download all your favorite commandline programs, compile them, and run them to your heart's content.
>
Read the Ars Technica article. Library handling is RADICALLY different, and eliminate most of the problems commonly associated with shared libraries. Configuration files are in XML. The filesystem has been restructured.
>
Agreed. But in this case, Apple is producing a better Unix, and a better MacOS all at once. All the cruft from Unix/BSD is being eliminated, the interface is modern, administration can be done ENTIRELY from the GUI.
>
MacOS 9 already supports multi-user desktops. I set up my mom's iMac so that she and my dad have seperate logins and can't screw things up. They double-click their names, speak their password and go ff to do whatever they want. I have an account with admin priviledges...
I have heard many things that encourage me that Apple understands this, and may therefore be the first to create a Unix-stable, xerox-style operating system. I have also seen many things that discourage me, because they indicate Apple is buying the benighted notion that BSD-compatibility is worth a damn to their business. It is not. Let me repeat: it is not. And furthermore, it will eviscerate the utility of the MacOS. Do you hear me, Tevanian? Hide that damn shell. Hide it somewhere where we will never find it.
Unix users are smart, self-reliant people. We can find plenty of ways to get our jollies without mastering our problems onto millions of MacOS CD's.
Consider your motivations and look for the path that will make you happiest.
:)
If curiosity is your motivation, then the best path to take is that which affords you the most opportunities to learn. If money is your motivation, find the fad-of-the-week and latch onto it with a deathgrip. Wash, rinse, repeat next week.
Always reevaluate where you are and try to determine if you are happy, and whether your current path will lead to more, or less happiness.
-JF
Bad analogy.
<<It's easy to argue that this isn't Microsofts fault, until you compare it to GM shipping products that failed so badly in crash tests.>>
In the case of things like the Melissa virus, this makes sense. But this is not such a case.
This has nothing to do with Outlook, or how it was designed.
The way ILUVYOU works is to send an e-mail with an attachment: A standalone script written in VBScript.
<<Windows can't be locked down enough to stop this stuff, ergo, it's intrinsically faulty.>>
What can you do on Linux, or Solaris to stop a malicious shell script, or Perl script attached to an e-mail?
If the recipient chooses to execute the script, then he or she will be subjected to whatever any other program can do.
The ILUVYOU script is smart enough to read Outlook's address book, but it could as easily read any other e-mail program's address book. ILUVYOU also interacts with mIRC to spread itself that way. Is mIRC at fault? Of course not.
The only "solution" would be to run every single program in the OS under a sandbox. That's not a realistic option, even if you could write a provably secure sandbox.
This worm could as easily have been a Windows EXE file. There is no functional difference here.
NT, like *nix has file ownership constraints that limit the extent of the damage that can be done. That's all that can realistically be done.
I'm not exactly a fan of Microsoft, but given that *nix is susceptible to the exact same sort of attack, I can't blame them here.
-JF
First off, leadership does not neccesarily mean establishing new proprietary ways of communicating with clients. Linux could become a leader in clustering and high-availability solutions. It could become a leader in web application development/deployment platforms/tools.
There are many ways Linux could innovate and jump ahead of the pack. But that's not neccesarily a good thing.
Right now, Open Source has to play catch up because there are serious areas which it is deficient in. It is tempting to postpone development in those areas, or to begin cool new development in other areas but that isn't what we need.
Let other companies take the risks and fight the big battles. I'm more than content to have Linux take the winning protocol/standard/whatever and implement it better than the commercial OS that championed it.
But I don't object to anyone doing what Open Source is about: Scratching an itch. If someone needs a revolutionary new way of sharing data between clients, or a revolutionary new web application platform, be my guest! Innovate to your heart's content. Do it because you need it, but don't do it just because you want to be ahead of Microsoft.
-JF
Melissa and other such virii work by infecting Office documents with malicious code. You can attribute this then to Microsoft for at minimum, not taking proper precautions with what an Office document can do.
.VBS files to Windows Scripting Host -- not just Outlook. The worm's author simply chose to read your Outlook address book however. It could have as easily been your Eudora address book, but realistically, more people use Outlook, making it a better choice of attack.
ILUVYOU on the other hand, is a standalone VBS script. It is not part of an Office document. Being such, it really is no different than any other executable.
The ILUVYOU worm would work on any Windows based e-mail program that followed the association of
Sorry, but this one aint Microsoft's fault...
-JF
yeah, but how much does mySQL slow down if you want to avoid table corruption? oh wait, unlike DB2, you can't avoid it.
I've NEVER seen unrecoverable table corruption in MySQL. In the DB2 instance, a table would be completely obliterated if the script accessing the table crashed before it disconnected the database handle. Oops. No ability to recover AT ALL, thanks to the fact that turning the journal off is what caused the instability.
Fast and decently reliable is good enough for some tasks, but for almost all non-web, and a good bit of web applications, MySQL is a square peg in a round hole.
I agree that for many non-web tasks MySQL is not well suited. At least for so-called "enterprise level" stuff. MySQL can be used to fill smaller niches even in that arena though.
I've only ever been involved in one web application where MySQL was not well suited, and that application classified as a traditional "data mining" type application.
-JF
This sounds like an application that could be better handled by LDAP instead of an SQL database.
Hogwash.
I have a suspicion that the people who safely use MySQL would be better off using LDAP, because their applications are heavily oriented towards reads
Actually, our application is heavily oriented towards *writes* which is why we use MySQL. 30x faster for our situation than the best alternative. (DB2)
We did use LDAP at one point, but performance and scalability were non-existent. We had to scramble to move to MySQL when we started getting around 50,000 page views/day -- the LDAP system couldn't handle it. Now, with MySQL we handle 2,000,000 page views a day, with several products instead of the one product we had at the time. (web based e-mail client)
-JF
If we were to implement something that required more than a few updates per minute, we would look into PostgresSQL or Sybase but as it stands now MySQL is the hands down winner.
My company's benchmarks indicate that MySQL is faster for inserts than DB2 (widely regarded as being a bloody fast database) by a factor of 30x. Higher if you want to avoid table corruption in DB2. (we had to turn journaling off to get the best performance)
-JF
MySql is _not_ OpenSource
I guess if you don't consider the GPL to be an open source license, then your statement makes sense. While TcX doesn't release the current-stable series under the GPL, they release older generations under the GPL. You can get MySQL 3.20.32a under the GPL right now. When 3.23.x becomes the official stable series, I'll bet you'll see 3.21.33 be GPLed.
TcX has been developing MySQL for years without "raising the price." Even if they did, so what? You still get the source, and they still publish older stable versions under the GPL.
As for PostgreSQL... Until it becomes *stable*, *fast*, and supports *outer joins* I find it an unworkable solution.
-JF
FFT calculation, and graphic generation, for example are not going to go fast no matter what.
In web applications, such complex calculations tend to be the abnormal case.
All Apache-mod_perl does is remove the over-head. Well, there is very little overhead to perl to begin with.
Absolutely false. There is a great deal of overhead to forking and execing Perl. And mod_perl does MUCH more than merely eliminate that overhead. mod_perl gives you the ability to do things like database connection caching and provides access to Apache internals giving your script more information and more control.
I've run all sorts of comparisons between java and perl, and for small - medium sized scripts, compilation is barely noticable.
My company has 70,000 lines of Perl code. Compilation time is significant.
The slowest parts tend to be in database reconnections, forking off seperate processes to do simple operations like file grepping, finding, etc.
First off, nothing will compensate for poor code. If you are using mod_perl, you can cache database connections. Forking a process to grep a file, or find a file -- that's ludicrous! It can be done trivially in Perl.
but I found that the same algorithm would run incredibly slowly in a java-servlet world because of the un-optimized string parsing in Java.
There are regex engines for Java that provide much of the performance and flexibility of Perl.
But if I redesign the java-system so that it uses a truely optimized 'parser' then I can get better performance than even in perl.
Of course. And there's probably a better way to do the Perl version too. There's *always* a more efficient way of doing something. And there's always a less efficient way.
The only problem is that you have heavy context switching, as opposed to the light-weight context switching of a threaded model ( such as java-servlets).
Apache 2.0 addresses this issue allowing a hybrid solution. (Multiple processes with multiple threads)
Another issue with process segmented workers is the redundant usage of memory and thus the propensity to Virtual memory thrashing. You, of course, always want to put more than enough memory in a server, but you also would like to cache as much of the web site as possible. If you were to scale to 50 workers, your memory contension would be well beyond that of a CPU-cachable range.
Much Perl code can be pre-loaded into the parent Apache process allowing it to be shared among processes. Thanks to the joys (grr) of copy-on-write, it gradually gets unshared -- a fault of Perl intermingling code and data -- but tuning process lifetime can alleviate this.
For small-scale operations ( Apache-Front-end, HTML-rendering, Business-logic, database-back-end ), where the business-logic is minimal, you can use mod_perl with apache and have the DB on another computer and you have plenty of scalability. To my understanding this is exactly slashdot. It is when business-logic becomes comparible in resource requirements to the other elements that perl really falls short.
My company handles 2,000,000 page views per day. Most of that is our web-based e-mail client. (heavily customizable/cobrandable!) We're growing at as much as 40% per month. We handle 1,500,000 mailboxes. We use Apache, mod_perl, and MySQL. With careful design our system ust keeps getting faster and faster.
It's hard to farm out CPU cycles to other machines or CPU's.
That depends on how well you designed your code. We have no such difficulties. I believe we have 11 web servers handling our e-mail client, 6 or so handling our message boards product, and a handful serving our search and chat products. (Both of those are in Java -- but receive trivial usage thus far...)
And if your logic serializes access to data ( via DB row/table locks ) then the ability to finish business logic computation really starts to stand out like a soar thumb.
That problem really depends on your RDBMS. MySQL is not well suited to such situations, but Oracle and DB2 handle them fairly gracefully.
Perl just doesnt show up in the enterprise model, or even the real service model beyond the simple form entry services like slashdot.
I must take exception to that statement. My personal site, my previous employer (BrainPower -- now out of business unfortunately), my present employer (Everyone.net) all use(d) complex business logic rules and all have found Perl to perform quite well when properly managed.
A web based e-mail client does not classify as a "form entry service." Our inter-company communication/integration protocols are also Perl based with great success.
Java was designed with all of this in mind, they just don't always achieve their goals completely.
If you can get over Java's screwy I/O model. No asynchronous I/O? Come on! One should not be forced to take on the overhead of threads for synchronous or multiplexed I/O. It's become a pain in the neck for our search product. We have to spawn 20 or more threads to do a meta-search. That's all well and good until you have a thousand people doing it at the same time!
I'm really tired of hearing the "Well [x] is a great toy for small companies/sites/whatever but when you want real power and performance use [y]." That argument has been used by Sun and Sco to describe Linux, by Python, Java, and other language advocates to describe Perl, and in many many more cases...
I stand by my experiences. BrainPower: data mining application. MrJoy.com: Customizable news and community site. Everyone.net: Cobranded, web based e-mail, community (message boards), search, and chat. With much more on the way.
2,000,000 page views per day and growing rapidly.
-JF
This is false. Apache with mod_perl runs at the same speed as Apache -- the combined speed of your computer, network connection, disk, etc. Yes, you can write slow mod_perl stuff (if you use it as glorified CGI), but mod_perl itself has no such limitations.
The real problem is memory overhead. Our mod_perl processes can reach 20-30MB each. But then again we have 70,000 lines of Perl code...
-JF
Normally I agree with most of what Jon Katz says. Such is not the case with this article.
Jon Katz whines about 330,000 users having their "privacy violated." And some of them are kids. My god! Think of the CHILDREN! That should be your first clue that he's full of hot air.
The firm Metallica used to find these "kids" didn't do anything the kids themselvesdidn't do in the process of findind the music they stole. They did searches -- but the firm wrote down the usernames of people they found rather than actually downloading stuff.
Metallica would be *entirely* justified in adding these 330,000 law breakers (and make no mistake, that is *exactly* what they are!) to their lawsuit, but they have not. They have strated that they will not. Instead, they simply ask that Napster obey their own publicly stated policy of blocking known pirates.
You can argue until you are blue in the face that record companies are greedy, glutonous pigs, but the fact is that the law gives them certain rights over the material they produce.
Metallica's actions have proven to be incredibly mild compared to what they *could* be doing. They are taking measures to stop hundreds of thousands of pirates right now (without hauling them off to JAIL, where they legally belong!) and trying to stem one of the big causes of the problem in stopping Napster.
Napster is not a good thing. It is JUST a tool for piracy. It does not legitimize online music, it legitimizes piracy -- the THEFT of other people's work. And why does this tool exist? Why does it prosper? Because we all have this entitlement mentality. We are *entitled* to music. Why should we have to pay for something which musicians work hard to make, which record companies spend lots of money to promote and distribute...
Katz: Stop whining. Nobody's privacy got violated. If you are standing in a crowd you cannot reasonably expect privacy. Likewise, if you are letting people download files from your computer, you cannot reasonably expect privacy. Metallica's actions are NOT heavy handed. The RIAA's actions against My.MP3.com are heavy-handed: They are using the letter of the law to crush competition despite the fact that no actual piracy has been committed. Metallica on the other hand is witnessing more piracy occur in *one day* than has likely happened in the past *10 years*. (before Napster)
-JF
Freedom freedom freedom. Give me my freedom. Damn the cost!
I'm a very big fan of Open Source, and the benefits to me as a consumer it generates. I am not such a big fan of Stallman's zealotry.
Stallman and the Free Software model fail to recognize that people, and companies put a great deal of effort, energy, and time into their works. His goal of making all software be Free Software (by annihilating non-Free Software) is absurd.
His goal would kill the commercial software industry. Every piece of software we use would be made by volunteers who worked on it when they felt like it. Which may be less often than people realize -- if the intellectual property industries are annihilated, we'll all be working blue-collar jobs.
Yes, many Free Software projects are very very good. Better even than their commercial counterparts. But the Free Software movement has shown itself to be nowhere near as good at certain things as the commercial software industry.
Example:
The Open Source/Free Software/Linux/BSD communities have shown themselves to be incredibly arrogant when it comes to end users' ("my mom") needs. It's only in the past couple years that a serious effort has been made to produce an operating system that can be used by end users. Previously the prevalent attitude was "well, if they wont take the time to read my 30MB of man-pages, they can go to hell." But now, we have collectively set our sights on toppling Microsoft and so we have to fight them on their own ground: Ease of use.
How "free" can one be, if one cannot even access the tools that you have so kindly "liberated" for them?
For all the bad they've done, Microsoft and Apple have done a great deal of good: They've made PCs accessible to the "average" person.
The reality is that we need companies to produce the things which we as a community do not *want* to produce, or *cannot* produce. Unfortunately, Stallman's unwillingness to compromise, or to work with the "other side" is a scorched earth policy. Most software companies would go down the drain, the few that remained would be dependent upon venture capital, and community-written software.
Redhat is great and all, but Gnome isn't exactle knocking Windows off the desktops en masse.
Stallman will be viewed as a zealot and a nutcase until he recognizes that software doesn't appear out of the ether. It *costs* people to develop software. Whether that cost is in time/energy/effort, or good old fashioned money, people deserve to be compensated for their expenditure.
People may even deserve the freedom to earn a little profit. But that freedom of course conflicts with the Free Software movement's goals.
The Nut is dead. Long live the Nut!
-JF
>
/targetting/ things to you. I looked at a bunch of Transformers auctions on Amazon.com, and all of a sudden when I go to Amazon.com I'm greeted with a list of Transformers auctions, books, movies, and such. Cool! Saves me some effort. I haven't paid much attention, but I'll bet the banner ads they show me are targeted at kids and toy-afficianados. :)
You have to consider what they *want* the information for. *WHY* do companies want demographic information about you? Once you understand this, it doesn't look nearly as scary.
My company for example, asks for all of the above plus (optionally) information about how much you make, your occupation, what industry you are in, and your precise address. Why?
It isn't as useful as one would think for "tracking" you. Even if you *don't* provide a site with that information, they can analyze their log files to see what people are doing (most log analyzers even list the "top paths through site") and of course, cookies can make even more precise tracking possible.
Companies don't care about *YOU* personally. There is nobody sitting at some desk somewhere saying "Aha! John Smith likes McDonalds!" Most uses of demographic information are *more effective* if you as an individual are ignored.
All demographic information is useful for is
There's really not as much to this as you think. It's simply an extension of customization. How many of you customize your Slashdot page to show the SlashBoxes you like? Well, that's the same thing: You're giving Slashdot demographic information about you. The fact that you're logging in lets them uniquely identify you.
Ok, so they can't identify you in meatspace, but so what if they could? Are the black helicopters going to land in your front yard? No. At *worst*, you might get a little more junk mail -- targetted to stuff you've shown you're interested in.
BFD.
There are abuses of privacy, and privacy does need to be protected, but many of you are too over-sensitive about this issue. You don't make a distinction between *good* and *bad* uses of personal information and you overlook the fact that most of you just throw such information at web companies without thinking twice about it.
Actually, it's already BEEN aired...
:)
It basically explains how at the time Netscape was in big big trouble and covers the open-sourcing of Mozilla... It culminates with the AOL-Time Warner deal...
It has interviews with numerous Netscape employees -- including then-employee Jamie Zawinsky (blue hair/nails and all...) -- and tells which ones quit and roughly why...
I enjoyed it quite a bit... Made my parents sit through it -- especially the interview with Pavlov's parents...
Actually, the specified option does precisely that. The "originating server" is considered as the server that the page came from, not the server that the image came from.
Netscape 4.x has an option which will let you allow cookies only from the domain which they originated from. Images, while they may be grabbed from another domain are considered to be within the "domain" of the whole page.
So if I'm at foo.com, and foo.com/index.html has an IMG tag linking to doubleclick.net, doubleclick.net's cookie will not be sent back to doubleclick.net.
I don't recall if it will just be sent back to foo.com, or if it goes into the bit bucket...
Not all information needs to be archived. Most of the e-mail I receive can go in the bit bucket for all I care. The rest, I archive. As for the information that can/should be archive, the author's statements to the contrary, industry standards can be used to archive what should be archived.
Given a format that is a) adequately documented, b) accurately represents the data it encompasses, and c) has sufficient widespread adoption, we can simply archive to that format as we need to.
Let's consider various and sundry data types, the prominent format for handling them, and the potential longevity of those formats.
Text: For raw text of course you have ASCII. While not a permanent fixture, nobody can argue it's longevity. We'll call this the baseline. Moving up from ASCII you need some way of defining formatting and such. There are really only a couple realistic solutions. Either some SGML based system, HTML, or PDF. I'll get into the latter two cases a little further down. Let's say that for plain text, SGML has the best longevity because of widespread adoption, and simplicity.
Rich Text (beyond simple formatting): As above, we need something better than ASCII. I'll vote for PDF here. It's a proprietary format, but it seems to be pretty well understood, and it does an accurate job of representing the original document. Mac OS X groks it very well, and Adobe has ensured that there's a viewer for every platform. If conversion tools can be made, then this is a good format.
Images (bitmap): PNG, JPG, GIF, and TIFF. TIFF seems to be less relevent these days although most scanner software still produces it. JPG/GIF are where the majority of data presently exists, and PNG is where everything should be archive, IMHO... PNG being lossless, and supporting about every feature known to man, this seems to be the best solution. One could crawl the web, grabbing every single GIF or JPG, archive it to PNG format with no loss of data and quickly build a significant archive.
Image (vector): Sorry, don't know much about the formats used here...
Audio: The obvious solution for archival is uncompressed, raw audio in a well understood format like WAV. This is an area that doesn't seem to be changing much...
Video: Again, I can't really comment on the formats here...
Things become more complicated when you have interactive media, or other very specialized forms of data... But I'd rather save that for the experts...
The author brings up the "loss of fidelity" issue when updating documents to a new format. I think this really only is an issue when making a lateral move. Converting from JPG to PNG wouldn't be a problem, nor GIF to PNG. Converting from WordPerfect to Word on the other hand, is problematic at best...
Thus the need for archival formats with some longevity. Perhaps a commission should be formed on data archival formats? A group of OSS developers who do nothing but strictly define what format(s) are to be used for "data archival" purposes, and ensure that tools to read/write these formats are readily available on every platform -- including new ones as they come out.
The trick is to avoid lateral conversions at all costs.
I wish they would use Oracle, and then maybe they wouldn't have to flush all the past stories and comments (i.e., the whole database would be searchable). I would imagine the reason they do that is that MySQL is not known for scaling up to large databases.
This is something of a myth... MySQL can actually handle very large tables quite well. It's problems are with lock contention... Instead of page or row level locking, it uses full-table locking which creates a bottleneck. This however has more to do with volume of users than volume of data.
Now, I'm not sure why Rob purges the old data, except perhaps as a matter of "hygiene" because properly designed MySQL databases would have no problems handling it. At least, if one is using the latest versions of MySQL which support >2GB tables on Linux...
Oracle on the other hand is as much as 14x slower than MySQL, and has serious performance issues with things like connecting to the database. You absolutely must use database connection caching to get acceptable performance. Not to mention the obscene pricing...
Even DB2 which is orders of magnitude faster than Oracle, and orders of magnitude cheaper than Oracle is not neccesarily well suited to a Slashdot style system...
MySQL is actually really good for many web applications... And it's few problems can be overcome (like splitting your tables up -- x becomes x1, x2, x3, etc...) in most cases...
Corel announced their involvement with the WINE project a very long time ago... Nothing appeared to come of it however. WINE made steady, incremental improvements but no major progress...
With any luck, this version will have some noticable improvements... Bearing in mind of course that this version was undoubtedly used to help port Corel Office 2000 to Linux...
In Silicon valley, many of the best software engineers don't have formal education. And many of the worst have degrees from prestigious universities.
I believe most places that have restrictions on the use of the word "engineer" are in the context of civil engineering. I am not a civil engineer.
But whatever you want to call me -- programmer, software engineer, or walking-talking-orange -- I work for Everyone.net. I spend my days writing code for them, and I spend my nights writing code for myself. I know the person running the giveaway: his motivations, and his intentions.
Therefore -- arguments about semantics aside -- I feel confidant in saying that it wont be used for spam.
Selling or renting the list would be using it for spam. The list will not be sold, rented, or in any way used for spam. The rules specify exactly how the list will be used: Your friends' addresses will be sent one e-mail (which you can compose, or you can leave it to us) to tell them about the giveaway. You will receive one e-mail with the giveaway outcome.