Don't let them off the hook. The god damn Microsoft rep keeps telling
me I have to use Windows X because it is better! He practically tells
me I'm being irresponsible running a business on Linux/Sun/DEC.
heh, I've never had the bad fortune of being pestered by a MS rep. I did once get a really funny piece of rep talk from an IBMer though: he was telling me that I should use java instead of perl for web development, and when I pushed with "why", his argument was "what if you need to port it to Linux?". the funny thing being that the perl in question has been running on Linux from the start.
you're wrong about (1) and (2); www.hotmail.com does indeed have these bugs. I've checked with socket(1) (an older netcat-equivalent program), and ran strace on it just to make sure. here's the relevant strace output:
notice how the server responds after the first \r\n from the client (when it's supposed to wait for \r\n\r\n, which signals the end of the HTTP headers), and how it only includes one \r\n at the end of its response, when it's supposed to include two (again, to signal the end of the http headers). www.hotmail.com right now (29Aug00, 1pm EST) is totally screwing up the http protocol.
Oh, and (3) is right too: if I send "HTTP/1.1" instead of "HTTP/1.0" it does exactly the same, pretends in its answer to be speaking HTTP/1.1, and still doesn't include the Connection: header.
Re:You seem to be a bit confused...
on
KDE Strikes Back
·
· Score: 2
I know that, but since most commercial apps are not open source, I said "commercial (not open source)" to clarify that i was talkign about those.
Re:License wars are a waste of energy
on
KDE Strikes Back
·
· Score: 2
of course they *can* pay them, but do you see Sun recommending to one of its clients that it should pay Troll Tech a large fee? they would if there was nothing else around, or if they had some kind of partnership with TT, but otherwise I can see how they'd rather tell them to code for GNOME.
Re:License wars are a waste of energy
on
KDE Strikes Back
·
· Score: 3
What people are bitching about is the fact that KDE is not legally
redistributable in binary form.
that is irrelevant. the KDE people are putting a GPL on a product that depends on Qt, and that's a perfectly clear indication that they intend to allow you to redistribute it. If they suddenly turned around and tried to sue you for redistributing KDE, no judge would listen to them for half a second.
the REAL licensing problem with KDE, is that you cna't write commercial (non open-source) apps for it, without paying Troll Tech. now, we free software hackers don't care much about this, but companies do. that's why you won't see Sun or IBM telling its ISVs that they should code for KDE, which is probably one of the big reasons why GNOME was picked over KDE for the onslaught of big-corp support. The only way Troll Tech could fix this would be LGPLing (not GPLing) Qt, but that would be quite squarely against their interests, so they won't do it.
other than that, this article didn't seem very convincing. Lots of babbling about politics and personal problems. I say, who cares. If you read the Linux Kernel mailing list, you'll see a lot of politics, conspiracy theories, and bitching and flaming even among the biggest developpers (including Linus himself). And you know what? It doesn't hamper kernel development -- it just moves it along. When there are disagreements, it's better to flame, say what you think, then look for common ground, than to pretend the disagreements aren't there. And no big project can exist without disagreements between people; not KDE, not GNOME, and not the linux kernel.
and then there's the technical arguments of KDE's superiority because of its greater consistency, which can be effectively countered by pointing out GNOME's greater openness (with multiple programming languages, its use of CORBA, and a non-toolkit-specific component model). I won't pass any hard judgements here: both consistency and openness are needed for a project to be good, and obivously KDE needs more of one and GNOME more of the other.
you forgot to add: multi-threaded apps are better for some things.
There are two ways of multi-threading an app: with threads that share everything (VM, open fds, cwd) but the stack, or with threads that share nothing but an area of shared memory. Under most OS's, the second is much slower than the first, which is why there's been this push towrdsa multi-threading in the first way. Both Solaris and NT have this problem, and when MS's interests coincide with Sun's, people just get the
impression that that is "the way to go".
OTOH, if you look at Linux (and FreeBSD, and even Plan 9), both kinds of threading work well, with very fast context switches. Under Linux, processes switch almost as fast as threads. So you can choose between the two ways of multi-threading, not by "which is faster", but by "which is more appropriate to the app".
Programming with several execution contexts sharing a single VM space is tricky. You need very careful locking, to prevent one thread's data updates from stomping on another's. On SMP machines, you get accesses to the same physical memory from all the CPUs, which means more bus traffic needed to maintain cache coherence. Multi-threaded, shared-memory programming is only worth it if your app calls for it, i.e if your app has a lot of shared state that all the threads will be working on.
Multi-threading with a separate VM space is considerably easier: each thread (or process -- processes are just one kind of thread) runs fully protected from interference, and you can always set up a shared memory zone for whatever shared data is needed. Each processor is mostly working on separate areas of memory, so bus contention is lower. The downside being that this kind of app tends to use more memory than the former.
Finally, single-threaded, event-driven programming should not be counted out. It turns out to be the most appropriate, for a surprisingly large number of problems. In some cases, you're better off running several copies of a single-threaded server (say, one per CPU), than a multi-threaded one.
IMNSHO, the worst thing that has come out of both Java and NT is the unthinking assumption that all programs should be multi-threaded, with a shared memory space, and that all servers should necessarily use one thread per connection. Yes, there are many cases where this is good, but there are also many cases where other solutions are just as good in performance, and much simpler and more maintainable in programming. Just say no to Sun's and MS's thread hype!
IMO, the licensing problem that made Sun and others prefer GNOME over KDE, is not so much compatibity between the QPL and the GPL (because, after all, the KDE authors
are the copyright holders to the KDE code, so they're the only ones who could sue you for not following the GPL to the letter, but they are clearly telling you that you can and should distribute their GPL stuff along with QPL'd Qt, so no court would seriously listen
if they somehow suddenly decided to change their tune). The real issue, is that these desktop environments also come with foundation libraries to build apps from,
that are *very* useful to make good apps that do common thigns (have a UI that fits, play sounds, print, etc), in a consistent way. Now, you don't want to restrict a desktop so that you can only write free (as in open source) apps on it. That would be like writing an OS that can only run open source apps: it just woulnd't fly. One fairly important point of the Free Software philosophy is that ideally all software should be free (as in speech), but that non free software should also be able to work with free software, when it's layered enough to be a separate entity.
in the case of KDE, you just can't build a commercial, non-free KDE application without paying Troll Tech. And *that* is what is makes KDE unacceptable as the ultimate free desktop for Linux and Unix. *Especially* for companies like Sun, who want to be able to make apps for whatever desktop they adopt, and these apps are not necessarily going to be all free. And they want to be able to tell ISVs that they should be coding for GNOME rather than Motif/CDE now, without having to tell them "code for KDE, and pay the Trolls everytime".
In the end, my opinion is that it's KDE's obstination to stick to Qt (and develop closely with it) that has ultimately doomed KDE as the mainstream Linux/Unix desktop. At the time KDE started, using Qt was the only expedient way to build a desktop, relatively quickly. But they chose to follow the Qt APIs very closely, without building layers of abstraction between the toolkit and their apps, and this has continued up to now, when KParts is intimately tied to Qt. Contrast this with GNOME, whose component model (Bonobo) is toolkit independent, and then the components that use it happen to also use GTK calls. Considering Troll Tech's decision (very justifiable for them as a business -- i'm not trying to criticize them) not to make Qt freely available for non-free development, the KDE team should have taken a step back after the 1.0 release, and either work on the failed Harmony project to re-create a LGPL Qt replacement, or switched their efforts to GTK, helped the C++ bindings mature, and ported their
stuff on it. If they'd done that, we'd probably only have one desktop environment now, and Miguel de Icaza might well be a KDE hacker. But that didn't happen, and GNOME is now reaping the benefits of its more far-reaching vision, in the form of significant commercial support.
beta products count if you want to count them, there's no universal answer as to whether it's "fair" or not. after all, beta products are already used by real people (random example: I use M17 for most of my browsing), and will become releases soon. but they're not yet mainstream.
I must admit that I find myself browsing with Galeon more than I do
with Mozilla these days. The simple and clean interface design
out-weigh the 'Heavy' and feature full interface of Moz.
my experience is that Galeon isn't quite ready for heavy use yet, but Mozilla pretty damn near is. I've been using M17 quite a bit for the last week, and I haven't had a single crash yet. The odd page that won't load, form entry field that grows and shrinks by a pixel randomly (pushing the rest of the page up and down.. real funny effect!), some UI oddities, sure, but it has basically rendered everything I've thrown at it, and done a good job of it. Once you get past the half-a-second redraw sluggishness, it's already much better than Netscape 4.7x.
Galeon, OTOH, still has some very basic functionality missing: you can't scroll up and down with the arrow keys, space and backspace; "see source" isn't there, forms have some problems, right-button menus aren't there yet, downloads don't work, much is missing from the preferences menu, etc etc.
it also has some very good points: the interface loads *fast* (faster than NS4.7, and much much faster than mozilla), what works, works pretty well. I
wouldn't be surprised at all if Galeon surpassed Mozilla in usability, and got all the features it needs, pretty soon. But for the moment I can't say it's usable for day-to-day browsing yet, and Mozilla is.
IE currently does the best job of standards compliance,
no, it's currently Mozilla that does the best job of standards compliance, on a count-the-points basis. IE is a relatively close second, but Mozilla does *that* better. now, of course, IE is a whole lot more stable than Mozilla. then again, Mozilla isn't even quite beta yet.
Instead of wasting time trying to turn into Linux into a desktop OS,
why isn't someone designing a new one from scratch? Sorry to burst
your bubble, folks, but Linux just isn't designed to be a desktop OS.
because OSs are layered things, and the lower levels (the kernel and drivers) are not anymore "designed to be a desktop OS" than designed to be anything else. The Linux kernel can be the foundation for a perfectly good destkop OS, it's just all the Unix command-line and/etc/configuration stuff that's historically tied to it. No-one's preventing YOU from making a desktop OS on top of the Linux kernel, that doesn't even use/bin/sh. For that matter, no one's preventing you from writing your own kernel either, but you'd better have some really good new ideas to put in it, to be worth the effort.
In the meantime, GNOME and KDE are moving forward, and doing the right thing: putting a pretty user interface on the whole system (which means that the average user ultimately doesn't have to touch the command line unless he actually wants to), while stayign reasonably close to the Unix way-of-doing-things, and keeping interoperability with more traditional Unix desktops (X11 + whichever wm).
It's fashionable to bash Intel on/., and claim that AMD will eat its lunch everywhere, but for the moment my impression is that X86-64 is at a much earlier stage of development than Merced (I can't bring myself to call it Itanium). Let's see, long before Merced's specs were public, Intel worked with MS to
ensure there'd be a 64-bit Windows port for it, and formed the Trillian project with Linux vendors to make sure there'd be a 64-bit GCC and Linux port. Now that the specs have been out for a while, GCC-ia64 exists (does anyone know how good it is at optimizing? my guess is "not great", but i really don't know), linux-ia64 is merged into the official kernel, several Linux distros have alphas or betas for ia64, MS has showed a prototype of win64, and things appear to be moving, slowly but surely. Now, AMD just unveiled the X86-64 specs, but where is the software support?
all we get is vague claims from Sun that they will port Solaris to the chip. Sure, AMD's processor will probably be compatible enough to run 32-bit Linux or Windows with no problem, but who wants a 64bit processor to run a 32-bit OS with 32-bit apps, when the 32-bit processor lines are cheaper and not anywhere near obsolescence? and where is the GCC port? it may be conceptually easy to move GCC over to this new beast, but it's still many hours of work; have they been done?
If AMD wants to be shipping X86-86 boxes soon (like early next year), they really need a solid, working, 64-bit OS for it. Linux being what it is, it will get ported over no matter what, but *very early* availability of Linux may well be what makes or breaks the X86-64. I sure hope that AMD, or some partner, will soon make public an internal port of GCC and Linux. If they haven't done it, they'd better start one, like now.
Any other VA customers out there like to comment??
My experience with VA has been good so far. we bought 2 systems from them a few months back (one large server, one small PC for use as a firewall). they worked well out of the box, and phone support was good. no idea about their "send back & fix" support.
Now I havn't done a lot of homework but don't VA boxes come Redhat
with VA Enhancements pre-installed on them.
yep, they do, and their enhancements are known for being very well tested and debugged, so I've always kept them. the annoying thing is that they're always a couple of revisions behind -- a few months back their system was shipping a modified RH6.0 when RH6.2 was just out. but they provide upgrades for their stuff, and RPMs for 6.2 will install on it, so it's not too much of a problem.
No, businesses make decisions with money. Assessing the financial
strength of different players also uses money. This is measuring
percentage of server license sales.
and basing a buying decision primarily on the financial strength of the different vendors doesn't seem like a good idea to me. sure, you want something that is supported, maintained, and will continue to be so in the future. but that is not the difficult part: Linux, Windows, Solaris and several others all fulfill these requirements. so it's more than worth considering other aspects too.
Who cares how many servers are deployed? It is irrelevant to EVERYONE.
Your decision to use an OS should be completely independent of what
other people are doing, right?
How many servers are deployed translates DIRECTLY into how easy it will be to find staff to run said servers, programmers who know the systems, and already-made (free or proprietary) commercial that runs on them. pretty important if you ask me.
Money, however, matters. It makes a lot of BIG differences. If I am a
interested in the revenue model of a OS, then the money does matter.
unless you are 1) planning to sell the OS, or 2) concerned that it will disappear or go unmaintained (and no, none of Linux, FreeBSD, Windows, Solaris, or AIX will), I don't see much of a reason to care about the revenue model of an OS.
They also can't seem to quite get rid of Sun or some of their software
competitors like Lotus, Borland/Inprise, and Oracle.
now that's an understatement if I ever saw one. can't "seem to quite get rid of" Sun, Lotus, Borland and Oracle? Sun's business is booming, Lotus is part of IBM, and Oracle is now *bigger* than Microsoft. I don't see MS getting anywhere near "getting rid" of these companies.
as of now, mozilla is my main browser. it finally got to the point where it works better than NS4.7x in day to day use. the latest NS 4.74 for linux was even more unstable than the previous ones: it crashes whenever you open a few windows (with lots of middle clicking) and then close a few with ^W. so that's it, exit netscape, enter mozilla. the UI feels slower, but the rendering is so much faster that it more than makes up for it. with the classic skin, bigger fonts and JS off, it's pretty damn usable.
That's not because I'm trying to impress anyone (I'm not), but because
I'm a mech hacker, too, and I appreciate the elegance of a really nice
mechanical hack like that required to do a nice watch.
contratulations, you're one of the very few people I know who actually appreciate watches for the mechanical works that they are. but please don't expect everyone else ot care about that aspect of them! anyway, I sure didn't imply to lump you together with the people who buy them "to convey status", like the other post said.
so watches
*should* have true sweep-second hands rather than the ridiculous
goose-stepping horrors the Japanese have foisted on us...)
now, who was talking about snobbishness?;-) to most of us a watch is just a way to know the current time, and from *that* perspective, digital works just fine, cheaper and less fragile.
Because maybe if you had the money you'd want to get a watch that'll
present yourself in a somewhat half-assed way.
I do have the money, and I don't want a watch to "present me". In fact, when I wear a watch (which is rare enough), I wear it in my pocket. Anyway, my point is that there's a large range of "personal presentation" options that involve neither dirty "C DOS RUN" t-shirts, nor PHB-style personal paraphernalia. One of the things that piss me off the most about these kinds of debates is that people tend to see these things in a linear scale, from "dorky" to "glamorous", and are all
excited either about defending either direction, or on finding the oh-so-difficult middle point. I say bullshit. There's many more options than that; there's not just an up and a down, but a front and back, left and right, and it's perfectly possible to have a personal style that looks like you give more than a crap about yourself, without buying into the name-brand clothes and goldwatch crap.
as for my work, I actually work for an internet company that has already realized that Linux and Free Software are good things, and where management actually cares more about what you have to say than about what your watch is made of. if yours doesn't, hey, we're hiring =)
Just don't be angry when I'm your boss in a week. =)
Or are you going to
sit and admire it, and then go out and get a real watch, a gold watch
that actually conveys status and meaning to the rest of society?
are you kidding? why would I want to spend my $$ on a GOLD WATCH of all things? of all the things I could do with my attention, time and money, choosing a watch that "conveys status and meaning to the rest of society" ranks pretty damn near the bottom.
$5 casio (or no brand) watches are the best. you can buy a whole box of them, and take the next one when yours goes in the washing machine or falls behind the bed or whatever.
seite 34 is one of the few where the Y unit is "time taken", not "amount processed per unit of time", which means that the *lower* line is the best one there. it's a bit surprising, but on seite 34, it's NetBSD that outperformed everyone. same thing on seite 32 (the SQL tests): Solaris was actually the slowest, and Linux the fastest.
in any case, we should take these tests with a large grain of salt. there are MANY factors unaccounted for: driver quality for the hardware used on each OS, IDE settings (hdparm on Linux), choice of filesystem, sync/async mounts, softupdates or not on BSD, journaling or not, and the large can of worms that is kernel tuning (did they do any?).
at least there are a few things we can tell kind of reliably from these tests: 1) the BSDs and Linux are all great; Solaris/x86 is generally slower (but may have better SMP, which wasn't tested here), 2) Linux 2.4 is a real improvement over 2.2, and 3) nfs and network stuff is faster when the client and the server use the same OS flavor.
it has been my impression that perl has been slipping.. losing its position as "the best for cgi
you could more accurately say that CGI has been losing its reputation as the best (or normal) way to do dynamic webpages, and *that* is a great thing in itself, since CGI (one fork/exec per page, yay!) sucks rocks. Perl has very good support for the CGI model, wiht the CGI.pm module, and mod_perl for Apache has two very good CGI emulations (Registry and PerlRun, with different tradeoffs in how much faster they are, and how much cleaner they require your code to be). However, emulating CGI is *NOT* the only, or the best way to use build dynamic pages with Perl.
The web-dev world has already pretty much come to the conclusion that URLs must be mapped to their content, not to a directory of scripts. As usual with Perl, There Is More Than Way To Do It; you have modules to embed stright Perl code into html pages (Embperl), modules that implement a higher-level componentized model (HTML::Mason, Apache::ASP, the Templating Toolkit, and others), and buzzword-compliant modules that go the XML/XSL way (AxKit).
As for perl6, I don't think it'll have a very direct impact in the way people do web development with perl. Perl 6 is going to be a complete rewrite and cleanup of the language, possibly with changes as fundamental and far-reaching as those between perl 4 and perl5. It will reorganize the whole perl world, not just the "perl on the web" part of it.
the words "Open Source" were also used in other fields from software (eg. in the military intelligence field, where it meant something like "information that is accessible to the public". however, I think i'ts silly now to claim that Open Source is anything else than what the Open Source Initiative has defined as it. They've been overwhelmingly successful in getting the public to know this term, with *their* definition (a repackaged concept of Free Software). So, I'm sorry, but OSAS is no longer Open Source in my book, nor in most people's.
The difference between Open Source and Free Software is just a matter of focus (focus on freedom or on open development), of ideology, and of degree of purism (some borderline licences might get more easily accepted by Open Source advocates than by Free Software ones), but the main idea is the same: software where you get the source code, and the right to use, modify, alter, compile and distribute (incl. for profit) under the same conditions.
As many posts have said before me, most computer users are too dumb (or uninformed, or uninterested) to worry in about security *and do something about it* (i.e not opening dubious attachments). So I don't think much social engineering is needed on the part of viruses; we *will* have more ILOVEYOUs.
Anyway, what strikes me is that these email and msword viruses have on the whole been quite tame in their side-effects. The ILOVEYOU virus, aside from emailing itself to your whole addressbook, replaced all the.mp3 and.jpg files on your hard drive. Some graphics people may have lost actual work stored in.jpg files, but on the whole, I don't think much got destroyed aside from porn and mp3 collections. Yet, it woudl have been just as easy for the virus to erase all your data; just replace "mp3" with "doc" and see the *real* damage!
And then there's another, more insidious way, in which an email virus could do very serious harm: by randomly forwarding your emails to people. Imagine a virus that forwards each email in your inbox to one random person in your addressbook. Whoops, there go most companies' secrets!
Because if there isn't, I'm not sure if migrating to a different OS -- even a similar one like Linux -- would be easy, or even possible. (I'm trying to think of what it would involve, and I'm not liking it.)
are you sure migration would be *that* hard? Linux does have binary emulation of SCO/SysV, with the iBCS module. Back before the major databases were ported to Linux, people were running SCO versions of Oracle on Linux using this.
Slashdot Mirror
heh, I've never had the bad fortune of being pestered by a MS rep. I did once get a really funny piece of rep talk from an IBMer though: he was telling me that I should use java instead of perl for web development, and when I pushed with "why", his argument was "what if you need to port it to Linux?". the funny thing being that the perl in question has been running on Linux from the start.
write(4, "HEAD / HTTP/1.0\r\n", 17) = 17n \r\n", 1024) = 151
select(5, [0 4], NULL, NULL, NULL) = 1 (in [4])
read(4, "HTTP/1.1 302 Redirected\r\nServer: Microsoft-IIS/5.0\r\nDate: Tue, 29 Aug 2000 16:55:03 GMT\r\nLocation: http://lc2.law5.hotmail.passport.com/cgi-bin/logi
select(5, [0 4], NULL, NULL, NULL) = 1 (in [4])
read(4, "", 1024) = 0
notice how the server responds after the first \r\n from the client (when it's supposed to wait for \r\n\r\n, which signals the end of the HTTP headers), and how it only includes one \r\n at the end of its response, when it's supposed to include two (again, to signal the end of the http headers). www.hotmail.com right now (29Aug00, 1pm EST) is totally screwing up the http protocol.
Oh, and (3) is right too: if I send "HTTP/1.1" instead of "HTTP/1.0" it does exactly the same, pretends in its answer to be speaking HTTP/1.1, and still doesn't include the Connection: header.
I know that, but since most commercial apps are not open source, I said "commercial (not open source)" to clarify that i was talkign about those.
of course they *can* pay them, but do you see Sun recommending to one of its clients that it should pay Troll Tech a large fee? they would if there was nothing else around, or if they had some kind of partnership with TT, but otherwise I can see how they'd rather tell them to code for GNOME.
that is irrelevant. the KDE people are putting a GPL on a product that depends on Qt, and that's a perfectly clear indication that they intend to allow you to redistribute it. If they suddenly turned around and tried to sue you for redistributing KDE, no judge would listen to them for half a second.
the REAL licensing problem with KDE, is that you cna't write commercial (non open-source) apps for it, without paying Troll Tech. now, we free software hackers don't care much about this, but companies do. that's why you won't see Sun or IBM telling its ISVs that they should code for KDE, which is probably one of the big reasons why GNOME was picked over KDE for the onslaught of big-corp support. The only way Troll Tech could fix this would be LGPLing (not GPLing) Qt, but that would be quite squarely against their interests, so they won't do it.
other than that, this article didn't seem very convincing. Lots of babbling about politics and personal problems. I say, who cares. If you read the Linux Kernel mailing list, you'll see a lot of politics, conspiracy theories, and bitching and flaming even among the biggest developpers (including Linus himself). And you know what? It doesn't hamper kernel development -- it just moves it along. When there are disagreements, it's better to flame, say what you think, then look for common ground, than to pretend the disagreements aren't there. And no big project can exist without disagreements between people; not KDE, not GNOME, and not the linux kernel.
and then there's the technical arguments of KDE's superiority because of its greater consistency, which can be effectively countered by pointing out GNOME's greater openness (with multiple programming languages, its use of CORBA, and a non-toolkit-specific component model). I won't pass any hard judgements here: both consistency and openness are needed for a project to be good, and obivously KDE needs more of one and GNOME more of the other.
too bad Intel didn't think of the "Itanic" pun. I bet they're wishin they'd called it something else by now.
you forgot to add: multi-threaded apps are better for some things.
There are two ways of multi-threading an app: with threads that share everything (VM, open fds, cwd) but the stack, or with threads that share nothing but an area of shared memory. Under most OS's, the second is much slower than the first, which is why there's been this push towrdsa multi-threading in the first way. Both Solaris and NT have this problem, and when MS's interests coincide with Sun's, people just get the impression that that is "the way to go".
OTOH, if you look at Linux (and FreeBSD, and even Plan 9), both kinds of threading work well, with very fast context switches. Under Linux, processes switch almost as fast as threads. So you can choose between the two ways of multi-threading, not by "which is faster", but by "which is more appropriate to the app".
Programming with several execution contexts sharing a single VM space is tricky. You need very careful locking, to prevent one thread's data updates from stomping on another's. On SMP machines, you get accesses to the same physical memory from all the CPUs, which means more bus traffic needed to maintain cache coherence. Multi-threaded, shared-memory programming is only worth it if your app calls for it, i.e if your app has a lot of shared state that all the threads will be working on.
Multi-threading with a separate VM space is considerably easier: each thread (or process -- processes are just one kind of thread) runs fully protected from interference, and you can always set up a shared memory zone for whatever shared data is needed. Each processor is mostly working on separate areas of memory, so bus contention is lower. The downside being that this kind of app tends to use more memory than the former.
Finally, single-threaded, event-driven programming should not be counted out. It turns out to be the most appropriate, for a surprisingly large number of problems. In some cases, you're better off running several copies of a single-threaded server (say, one per CPU), than a multi-threaded one.
IMNSHO, the worst thing that has come out of both Java and NT is the unthinking assumption that all programs should be multi-threaded, with a shared memory space, and that all servers should necessarily use one thread per connection. Yes, there are many cases where this is good, but there are also many cases where other solutions are just as good in performance, and much simpler and more maintainable in programming. Just say no to Sun's and MS's thread hype!
in the case of KDE, you just can't build a commercial, non-free KDE application without paying Troll Tech. And *that* is what is makes KDE unacceptable as the ultimate free desktop for Linux and Unix. *Especially* for companies like Sun, who want to be able to make apps for whatever desktop they adopt, and these apps are not necessarily going to be all free. And they want to be able to tell ISVs that they should be coding for GNOME rather than Motif/CDE now, without having to tell them "code for KDE, and pay the Trolls everytime".
In the end, my opinion is that it's KDE's obstination to stick to Qt (and develop closely with it) that has ultimately doomed KDE as the mainstream Linux/Unix desktop. At the time KDE started, using Qt was the only expedient way to build a desktop, relatively quickly. But they chose to follow the Qt APIs very closely, without building layers of abstraction between the toolkit and their apps, and this has continued up to now, when KParts is intimately tied to Qt. Contrast this with GNOME, whose component model (Bonobo) is toolkit independent, and then the components that use it happen to also use GTK calls. Considering Troll Tech's decision (very justifiable for them as a business -- i'm not trying to criticize them) not to make Qt freely available for non-free development, the KDE team should have taken a step back after the 1.0 release, and either work on the failed Harmony project to re-create a LGPL Qt replacement, or switched their efforts to GTK, helped the C++ bindings mature, and ported their stuff on it. If they'd done that, we'd probably only have one desktop environment now, and Miguel de Icaza might well be a KDE hacker. But that didn't happen, and GNOME is now reaping the benefits of its more far-reaching vision, in the form of significant commercial support.
I say, good luck to both teams :)
anyway, in case anyone wants a more authoritative source for "Mozilla is the best at standards compliance", http://www.richinstyle.com/bugs/table.ht ml is the place to go.
my experience is that Galeon isn't quite ready for heavy use yet, but Mozilla pretty damn near is. I've been using M17 quite a bit for the last week, and I haven't had a single crash yet. The odd page that won't load, form entry field that grows and shrinks by a pixel randomly (pushing the rest of the page up and down.. real funny effect!), some UI oddities, sure, but it has basically rendered everything I've thrown at it, and done a good job of it. Once you get past the half-a-second redraw sluggishness, it's already much better than Netscape 4.7x.
Galeon, OTOH, still has some very basic functionality missing: you can't scroll up and down with the arrow keys, space and backspace; "see source" isn't there, forms have some problems, right-button menus aren't there yet, downloads don't work, much is missing from the preferences menu, etc etc.
it also has some very good points: the interface loads *fast* (faster than NS4.7, and much much faster than mozilla), what works, works pretty well. I wouldn't be surprised at all if Galeon surpassed Mozilla in usability, and got all the features it needs, pretty soon. But for the moment I can't say it's usable for day-to-day browsing yet, and Mozilla is.
no, it's currently Mozilla that does the best job of standards compliance, on a count-the-points basis. IE is a relatively close second, but Mozilla does *that* better. now, of course, IE is a whole lot more stable than Mozilla. then again, Mozilla isn't even quite beta yet.
because OSs are layered things, and the lower levels (the kernel and drivers) are not anymore "designed to be a desktop OS" than designed to be anything else. The Linux kernel can be the foundation for a perfectly good destkop OS, it's just all the Unix command-line and /etc/configuration stuff that's historically tied to it. No-one's preventing YOU from making a desktop OS on top of the Linux kernel, that doesn't even use /bin/sh. For that matter, no one's preventing you from writing your own kernel either, but you'd better have some really good new ideas to put in it, to be worth the effort.
In the meantime, GNOME and KDE are moving forward, and doing the right thing: putting a pretty user interface on the whole system (which means that the average user ultimately doesn't have to touch the command line unless he actually wants to), while stayign reasonably close to the Unix way-of-doing-things, and keeping interoperability with more traditional Unix desktops (X11 + whichever wm).
If AMD wants to be shipping X86-86 boxes soon (like early next year), they really need a solid, working, 64-bit OS for it. Linux being what it is, it will get ported over no matter what, but *very early* availability of Linux may well be what makes or breaks the X86-64. I sure hope that AMD, or some partner, will soon make public an internal port of GCC and Linux. If they haven't done it, they'd better start one, like now.
now that's an understatement if I ever saw one. can't "seem to quite get rid of" Sun, Lotus, Borland and Oracle? Sun's business is booming, Lotus is part of IBM, and Oracle is now *bigger* than Microsoft. I don't see MS getting anywhere near "getting rid" of these companies.
as of now, mozilla is my main browser. it finally got to the point where it works better than NS4.7x in day to day use. the latest NS 4.74 for linux was even more unstable than the previous ones: it crashes whenever you open a few windows (with lots of middle clicking) and then close a few with ^W. so that's it, exit netscape, enter mozilla. the UI feels slower, but the rendering is so much faster that it more than makes up for it. with the classic skin, bigger fonts and JS off, it's pretty damn usable.
as for my work, I actually work for an internet company that has already realized that Linux and Free Software are good things, and where management actually cares more about what you have to say than about what your watch is made of. if yours doesn't, hey, we're hiring =)
as long as I get to do cool stuff, I won't =)are you kidding? why would I want to spend my $$ on a GOLD WATCH of all things? of all the things I could do with my attention, time and money, choosing a watch that "conveys status and meaning to the rest of society" ranks pretty damn near the bottom.
$5 casio (or no brand) watches are the best. you can buy a whole box of them, and take the next one when yours goes in the washing machine or falls behind the bed or whatever.
in any case, we should take these tests with a large grain of salt. there are MANY factors unaccounted for: driver quality for the hardware used on each OS, IDE settings (hdparm on Linux), choice of filesystem, sync/async mounts, softupdates or not on BSD, journaling or not, and the large can of worms that is kernel tuning (did they do any?).
at least there are a few things we can tell kind of reliably from these tests: 1) the BSDs and Linux are all great; Solaris/x86 is generally slower (but may have better SMP, which wasn't tested here), 2) Linux 2.4 is a real improvement over 2.2, and 3) nfs and network stuff is faster when the client and the server use the same OS flavor.
you could more accurately say that CGI has been losing its reputation as the best (or normal) way to do dynamic webpages, and *that* is a great thing in itself, since CGI (one fork/exec per page, yay!) sucks rocks. Perl has very good support for the CGI model, wiht the CGI.pm module, and mod_perl for Apache has two very good CGI emulations (Registry and PerlRun, with different tradeoffs in how much faster they are, and how much cleaner they require your code to be). However, emulating CGI is *NOT* the only, or the best way to use build dynamic pages with Perl.
The web-dev world has already pretty much come to the conclusion that URLs must be mapped to their content, not to a directory of scripts. As usual with Perl, There Is More Than Way To Do It; you have modules to embed stright Perl code into html pages (Embperl), modules that implement a higher-level componentized model (HTML::Mason, Apache::ASP, the Templating Toolkit, and others), and buzzword-compliant modules that go the XML/XSL way (AxKit).
As for perl6, I don't think it'll have a very direct impact in the way people do web development with perl. Perl 6 is going to be a complete rewrite and cleanup of the language, possibly with changes as fundamental and far-reaching as those between perl 4 and perl5. It will reorganize the whole perl world, not just the "perl on the web" part of it.
The difference between Open Source and Free Software is just a matter of focus (focus on freedom or on open development), of ideology, and of degree of purism (some borderline licences might get more easily accepted by Open Source advocates than by Free Software ones), but the main idea is the same: software where you get the source code, and the right to use, modify, alter, compile and distribute (incl. for profit) under the same conditions.
Anyway, what strikes me is that these email and msword viruses have on the whole been quite tame in their side-effects. The ILOVEYOU virus, aside from emailing itself to your whole addressbook, replaced all the .mp3 and .jpg files on your hard drive. Some graphics people may have lost actual work stored in .jpg files, but on the whole, I don't think much got destroyed aside from porn and mp3 collections. Yet, it woudl have been just as easy for the virus to erase all your data; just replace "mp3" with "doc" and see the *real* damage!
And then there's another, more insidious way, in which an email virus could do very serious harm: by randomly forwarding your emails to people. Imagine a virus that forwards each email in your inbox to one random person in your addressbook. Whoops, there go most companies' secrets!
are you sure migration would be *that* hard? Linux does have binary emulation of SCO/SysV, with the iBCS module. Back before the major databases were ported to Linux, people were running SCO versions of Oracle on Linux using this.