I have to say that what Linux really needs is a free top-notch vector font editor, something along the lines of Fontographer.
You mean, like pfaedit? It's almost a carbon copy of Fontographer, and very good it is for editing fonts too.
The tools (pfaedit) have been usable for about 18 months though, but still no-one is having a serious go at fixing fonts. I don't think people realise just how much time and effort goes into a font. My day job is as a graphic designer, I draw things all day, mostly using vector graphics, so I like to think I have a handle on what I'm doing and I can draw with curves quicker than most. In a past life I put together a couple of typefaces for a corporate client, and this is from my experience of that (I used Fontographer to begin with, then switched to Fontlab later on because Fontographer can't do TrueType hinting worth a damn - I do wish pfaedit had cloned Fontlab).
To go from nothing but an idea to a set of outlines covering iso-8859-1, that's about 4-5 days of solid full-time work - for a fairly simple sans-serif font in regular weight - add another day each for bold, italic and bold italic, add some more on if it's a more complicated style of typeface. Getting the kerning (spacing between characters) right is another couple of days work if you want it perfect.
Then, the nightmare part - hinting. Hinting... let's just say it's about as fun as pulling teeth without anaesthetic. To get good results on-screen, you need to allow about 2-3 hours - per character. If you want it to work correctly on more than one platform, double that. Fortunately lots of characters in the iso-8859-1 set are compound, formed of a letter and various accents and so forth, so you can just copy and paste these, but still you can easily end up spending several weeks on it - and it's the most unrewarding, boring and soul-destroying work I've ever done. Then repeat for bold, italic and bold italic.
It's all very well saying that people will re-hint dodgy fonts for fun, but you try it and see how long you last before giving up and going back to something rewarding, like writing an IRC client or GIMPing together a new wallpaper. I hope FreeType's autohinter everntually gets good enough that we can just give up on hinting.
but where there's a native control, wxWindows uses it.
Except where it decides not to, like the file dialog, which isn't anything like the GTK+ version.
I have to agree with the other poster about this: wxWindows does suffer a little from the fact it wraps widgets rather than emulating them. Layouts don't quite match from platform to platform, because the underlying toolkit has different ideas about where to put the widgets. A layout that works well with the GTK+ backend often looks scruffy in Windows, and vice versa. Sometimes the underlying widgets behave in subtly different ways, which makes the interface not behave correctly on one platform. It's tough to fix this without resorting to a lot of platform tweaks #ifdef'ed around the code, which partially defeats the point of a cross-platform toolkit.
Audacity is the canonical example, and probably the highest-profile wxWindows app too: it doesn't really look and feel like a GTK+ app when on X11, and on Windows it doesn't quite look or feel right there either, and that's with quite a lot of tweaking for platforms.
C's interface is very stable. C++'s varies from vendor to vendor and from compiler version to compiler version
This used to be true, but there is now a standard C++ ABI on Linux which all the major compilers now follow, gcc included (from 3.2 onwards). This should now be a concern of the past... about time too.
[dlopen/dlsym etc.] C++'s interface is just too messy to support this.
Which is of course why KDE uses this technique almost everywhere, dynamically loading C++ plugins on demand. KDE's component architecture (KParts) is built around doing exactly this. I think the Mozilla and OpenOffice.org component systems also work in essentially the same way. It does involve a little extra overhead (you use a ComponentFactory to create the object whose methods you call) but it's pretty minimal.
It's just as easy for the programmer as it is to dlopen a C library and call functions, if not easier.
and it became a heavy anchor around Be's neck, because web page compatibility ended up sucking.
The differences here being that:
KHTML already has very good web page compatibility, in fact for a rendering engine that most designers hadn't even heard of until very recently, let alone tested against, it's outstandingly good
Web designers won't ignore a browser made by Apple, so even if KHTML sucked, which it doesn't, designers would hack their pages to work
The *Linux community as a whole* seems to prefer KDE? What are you *smoking*? Look at the quantities of software for each, look at what the most popular distribution is.
Every poll, every survey, every popularity contest that I can remember in the last 2 years has voted KDE as 'Best Desktop Environment', including Linux Journal's Reader's Choice awards, which frankly ought to be biased towards GNOME, if you believe the theories, because of LJ's mostly North American audience. Simple as that.
Forgetting of course all the newbie Linux users who don't vote in these things, and in my experience tend to head straight towards KDE because of its familiarity for Windows refugees...
As for software - well, number one, the Linux community are not all developers. Second, I dispute the idea that GNOME/GTK has more software. Well, perhaps it used to, but GNOME 2.0 has thrown that advantage away completely. And much of that software was half-finished and duplicated 19 other projects because GNOME didn't adopt one. How many Xine frontends does a desktop need anyway?
And as for distros... haven't you met a Red Hat user who uses KDE? I've met plenty. In fact, more of them than use GNOME... but hey, that's just the circles I move in.
AbiWord isn't a Gnome app but you'd never know, it integrates nicely etc and is a good deal more active than KWord seems to be. Ditto for Gnumeric and KSpread. Noatun is just a joke, really, but it's kind of the "official" KDE media player.
You read in the article about there being something of a cultural difference between the two camps: USA vs. Europe, noisy vs. getting on with it. Well, this is the perfect example. You think AbiWord is far more active than KWord. It has more developers, more mailing list messages, more CVS commits, more releases. But look at the current in-development versions of both of them, and compare them with what they were like a year ago. I think you'll find the comparison doesn't come out in AbiWord's favour. Partly this is architectural - there's FAR more code sharing and reuse in KOffice/KDE/Qt than in AbiWord/GTK, partly because the balance of talking about it/doing it is further towards the doing it end with KWord than with AbiWord. I guess this also explains why Slashdot appears to have a tendency towards GNOME whilst the Linux community as a whole seems to prefer KDE.
And don't diss Noatun: you might not like it but from my point of view it's far nicer than anything else available. It plays all my music, has a good equalizer, does effects, the interface looks and works like everything else on my desktop (although it doesn't have to), and most important of all, happily hides itself down in the system tray when I want it out of the way and stays there. The KDE 3.1 version embeds Xine to play video: now it's the only media player I use. I love it.
On the other hand, the KDE usability effort seems to be going nowhere quickly
I take it you've not used KDE 3.1 yet then? There's some good improvements in there.
And let's face it, GNOME usability still has a long long way to go *cough*GTK+ file dialog*cough*
Faster transfer speeds (Firewire2 will leave SATA in the dust).
Firewire 2 = 800 Mbps = 100MBps
SATA = 150MBps
Firewire 2 faster? Don't think so. Sure, Firewire 2 will ramp up to twice that speed eventually, but so will SATA...
SATA is also a lot simpler to implement: chipset manufacturers can reuse most of their old, highly-optimized Parallel ATA controller core. Similarly, OS writers can reuse most of their old ATA drivers. SATA has less overhead than Firewire, it's designed for data storage and data storage alone, and it doesn't do daisy chaining.
Firewire's a nice technology, and it would work for hooking hard drives up internally, but it doesn't do the job as well as SATA does, it's over-complicated (and thus expensive), doesn't have the track record, and probably most importantly, has some serious political opposition (Intel anyone?). It's always going to be the Cinderella of the ball.
The issue isn't that Apple can choose KHTML, it's more a case of why.
Other people have pointed out the corporate aspects, that Apple might not like the fact that AOL has tight control over the direction that Mozilla is headed simply by sheer weight of numbers of developers. I'd like to bring up a different reason: have you actually had a look at the Gecko source recently? It has turned into a bloated, crufty mess with many peculiar hacks to satisfy Mozilla's cross-platform nature (it seems NSPR/XPCOM is not quite abstracted enough as portability code has crept in elsewhere) and to work around deficiencies in the W3C specifications. For a browser that was started again from scratch because it was felt the previous version (remember the Netscape 5.0 code dump? ugh) was way too bloated and crufty to continue work on it, that's very sad.
In contrast, KHTML has stayed pretty lean, partly because I think Qt is a better GUI platform abstraction than NSPR/XPCOM, and partly because it has had to due to the tiny size of the development team: with only a handful of people contributing code, the code needs to be as clean and obvious as is humanly possible simply for the project to survive. It will be interesting to see whether KHTML can continue to be so lean with the addition of a bunch of full-time Apple developers onto the team.
For all the bitching about KHTML's CSS compliance, I probably ought to point out that whilst it's not necessarily quite as good as Gecko (although I have a nice testcase using floats that Gecko has never got right but KHTML aces) it's (in my tests) better at CSS than any version of IE or Opera so far.
It's been fashionable to diss anything other than Gecko since Mozilla hit 1.0. I think that needs to stop: not everyone likes Gecko, both users and developers, and it certainly is not inherently superior, despite its current marginal lead in standards compliance (and lets not forget how it now trails in performance). Open Source does not need to get behind one browser, in exactly the same way that it doesn't need to get behind one desktop either, or one word processor or one toolkit. Choice is good, and rabid Mozilla fans should be especially conscious of this, because Moz would be toast otherwise thanks to IE.
It's also tragic that I only feel confident enough to say this without getting modded down into oblivion in an article that is so obviously a loss for Gecko/Mozilla, but hey, that's Slashdot for you.
Happy Konqueror user since 2000 - yes, I remember when it could barely render Slashdot correctly - and chuffed to bits that Apple agrees with his choice. Nice to be vindicated sometimes.
From my point of view what killed TW was a gradual, slow change in the kind of stories they showed. When I used to watch TW religiously, back in the mid-late 80's, the vast majority of their items were to do with either consumer technology inventions (CD's, home computers and so on) or physical sciences (string theory, birth of the universe, or, more paractically, the first mention I ever heard of quantum computing and quantum encryption back in 1988 or so). During the 90's, in what seemed to me to be a misguided attempt to win ratings, the show gradually changed to a more human-interest type show, all about biology, genetics, medicine, until by the late 1990's that was all there was: no inventions, no physical science news, no astronomy, just item after item of medical discoveries, biotechnology, with the odd reference to the BBC's 'Webwise' project to get people hooked up to the Internet.
That was when I stopped watching it, it just didn't interest me any more. I appreciate the importance of medicine and the biological sciences (although these interest me less than the physical sciences and associated inventions), but there just wasn't anything else on TW, and it got boring because of this.
I don't think I'm alone in feeling this - I've met quite a few geeky Tomorrow's World ex-fans who say the same thing, they just stopped running the stories that interested them. It's quite a tragedy - in an attempt to make the programme trendier and gain mainstream audience share, they completely killed off their core audience, and the production team seemed to have absolutely no idea what the problem was. It's entirely the BBC's own fault.
Oh well, here's hoping they'll wake up one day, realize their mistake and revive it, just like they have with Doctor Who.
N.B. The last sentence used a technique known as irony. Some of you may wish to study and attempt to understand it.
This is just another facet of the kernel developers' jihad against binary modules. Presumption of guilt does not imply bad code, it implies prejudice(*).
Recent drivers are better than they used to be, but the nvidia kernel module really, genuinely has had a LOT of problems. I have a machine with a Geforce2 that will stay up for months when using the open-source nv XFree86 driver (which uses no in-kernel code at all), but using the nvidia binary drivers oopsed at least once a day with random memory management errors and would freeze hard about once every 3-4 days. It finally seems to be fixed in the most recent release of the binary drivers. And let's not even go anywhere near AGP support - even with the most recent drivers, if I leave the AGP support on I am guaranteed a wedged machine within 5 minutes of starting X, whether I tell the driver to use the kernel or its own agpgart support. I'm not using weird hardware either - this is a PIII Abit motherboard with Intel BX chipset - about as standard as you can get. The card is flawless in Win2k with AGP on, again using the nvidia reference drivers. If I swap the Geforce2 out for the old Rage128 I have lying about, that works flawlessly in Linux too, 3D, AGP and all, but it's a lot slower than the Geforce. Oh, and I'm using stock Linux kernels, no distro-specific stuff or strange patches. The only option that I could see in the kernel that might make a difference is using the local APIC on the PIII as opposed to using the XT-PIC, as this can mess with the interrupt delivery timings and delivering an interrupt which the driver isn't expecting might wedge it, but I tried it both ways with the same results. It ought to just work though, right?
Therfore, the only conclusion that I can draw is that the nvidia Linux binary driver is buggy, particularly with regard to its handling of AGP. I don't think I'm alone in reaching this conclusion either - I have heard plenty of fairly similar bug reports. I can't begin to debug it myself because I don't have the source to the nvidia driver. I've reported it to nvidia. I haven't bothered pestering the kernel developers with it because it's plainly not their fault and there is nothing they can do to rectify the situation.
I admit I've not tried it in another motherboard, but why then does it work in Win2k flawlessly? Ok, Win2k is also using binary drivers - but then, when was the last time you mailed an NT kernel developer with a driver bug report? You don't, you mail the driver developer if they give you an address or simply sit tight if you don't have one. That's all the Linux developers are asking too.
Put simply, the reason the Linux kernel developers tell you to piss off if you're using the nvidia binary driver is because 99% of the time that is the problem, and if you're too stupid to be able to realise that and attempt to reproduce it without the nvidia driver loaded, then you're too stupid to provide a decent bug report and your mail might as well go straight to/dev/null. Most kernel developers are drowning alive in email as it is, and that's email that's got useful stuff in it. They have better things to do, like fixing bugs in code that they have the possibility to fix.
(*) Please don't flame me for calling Linus a racist.
I'm not. I'm flaming you for being stupid and not understanding the issues involved.
As has been pointed out, Rosegarden is a sequencer, not notation software - there's an overlap but sequencers tend not to be very good at being notation software - the focus of the software is different. Having toyed with Rosegarden-4... let's just say its notation is basic, although it's shaping up to be a good sequencer.
I like noteedit myself, it's proper notation software and seems to be the nearest thing Linux has to Finale or Sibelius. It does a nice job, exports to Lilypond, MusiXTeX and a couple of other formats for printed output, and even supports guitar tabs (very useful, and something that you have to pay even more for in Finale). Mind, I don't have very complicated requirements for notation software, all I do is typeset my band's songs for posterity.
BTW let's keep the toolkit jibes out of it, shall we? It's appropriate in a story about X toolkits, but this isn't one, here it looks like partisan flamebait. Besides, if you use Bluecurve or Keramik/Geramik, they look very nearly the same anyway, so no problem, right?
There's only a single "killer app" on Linux that's written in Qt -- licq, the best-of-breed Linux ICQ client
Discounting of course the whole of KOffice, the only Linux office suite that's nice to use. Or Konqueror, the web browser, file manager and universal viewer that's actually good to use and does what it says on the tin. Or KPPP, the only friendly GUI way of getting online if you're on dialup. Or Quanta, the nicest HTML editor. Or Kate, the all-round best GUI text editor. Or KDevelop, the best IDE by miles. Or Scribus, the only DTP program on Linux worth a damn. Or Rosegarden-4 or MusE, the only halfway-usable music sequencers on Linux. Or Karbon14, now part of KOffice, not quite there yet but a vector drawing program like Sodipodi that, unlike Sodipodi, doesn't drive you barking mad.
GTK+ has more applications in number, I agree, although not anything like the 5:1 ratio you think, and few of them are large and complex. Only two of the apps you gave as examples, the GIMP and Sodipodi, could really be described as large and complex, and both of them have a reputation for having a terrible user interface. The rest of the apps you gave are all fairly small and limited in scope - a music player, a couple of p2p apps, a system monitor. Personally I think that says a lot about GTK+'s suitability for writing large applications.
Compare that with Qt, which has Scribus, Rosegarden-4, MusE, KDevelop and Karbon14 as large and complex killer apps, all of which have quite decent user interfaces, and all of which have smaller development teams than the GIMP or Sodipodi. Heck, Scribus was written almost entirely by one person! You'll note also that there aren't too many specialist commercial applications being written in GTK+ - where are the medical imaging apps or the geological survey apps, to pick two that TrollTech shows off as success stories? Or of course there's Opera, or the HancomOffice stuff. Or all the PDA stuff for the Zaurus. If the commercial licensing was really a problem for Qt, don't you think these would have been written in GTK+ or wxWindows instead?
There's this persistent myth put about by some people that no-one is writing apps with Qt, and it simply isn't true. You're just choosing not to look at them.
If you use Linux, you *will* be using gtk at some point
Not really. The only GTK+ apps I keep around these days are the GIMP and Sodipodi and they are such pigs to use I often find myself booting a VMware Win2k session to use Photoshop and Illustrator instead, even for quite small tasks. The only non-Qt app I find I use regularly is OpenOffice.org, and that's only because it's the only thing that will reliably open MS Office files - if I'm starting a new document I prefer KWord or KSpread, they play nicely with the rest of my desktop, are lighter on my system, and are easier to use.
Sun probably decided that it couldn't control the KDE people, so the GNOME approach gave it more freedom to do things the way it wants to.
You're almost certainly right on this point.;)
Of course, freedom for Sun isn't necessarily a good thing for the end user - or the volunteer developer. Witness all the moaning about the direction GNOME 2.x is headed from... end users and volunteer developers.
my my, how do you get a +4 for a comment about GTK being broken everywhere cept with X and you have ZERO DETAILS to back that statement up
Because it's the truth. GTK+ 1.4 and 2.0 both work on Win32, but they are both exceptionally buggy - have you tried using the GIMP Windows port? It's not a good experience, and that's not just because the GIMP has a terrible interface anyway. GTK+ apps running on Windows don't look or behave like Windows apps either, they behave like... GTK+ apps. Sticks out like a sore thumb. Second, GTK+ doesn't run on MacOS X at all, not natively, anyway. The X11 version works if you have an X server installed on the Mac, but that just means you're running the X11 version, so my original statement still holds true.
I'm not saying GTK+ is crap, it's just not designed to be cross-platform (assuming you count X11 as a single platform, and I do) and it shows. I was taking issue with the idea that GTK+ is a sensible toolkit to choose if you want cross-platform apps, which the original post in this thread suggested. If you want cross-platform GUI apps, choose Qt or wxWindows - or heck, Java/Swing if you're a masochist, but don't choose GTK+, it would be a dumb choice.
QT costs money for other platforms. GTK is free everywhere.
Qt works properly on other platforms. GTK+ is broken everywhere except X11 (doesn't work, or is very buggy, doesn't look like a native app).
If you are going to recommend an alternative to Qt for cross-platform GUI development, you do yourself a great disservice by suggesting GTK+. Try wxWindows instead - a much better alternative than GTK+, although it does still have issues.
One of the biggest problems I've found when developin free software is I'll think "Ooo... this toolkit/framework has the features I need" (happened with GTK+ about a year ago) and then it'll take a month to find documentation or guides about it or figure it out from scratch myself.
So use Qt rather than GTK+ then.;)
Seriously, the Qt documentation is superb. Complete, comprehensive, up-to-date, easy to read and navigate, and with a very good set of tutorials that range from a simple 'Hello World' app through to a full-blown game and a charting app. It's excellent even by Windows standards - but then, it has to be, because it gets sold with that documentation on Windows. Check it out here.
Don't assume that simply because some X toolkits have poor documentation (and unfortunately GTK+ is one of the poorer examples) that all of them do.
It's nothing wrong with the POSIX threads implementation, its perfectly adequate, it's just that the FreeBSD scheduler don't do on the internals of the userprocesses.
Ok, let's get this straight. FreeBSD's default pthread implementation is an entirely userspace affair, everything occurs within a single process and the thread library does co-operative scheduling of threads within the process. Not quite sure what you're getting at when you talk about writing your own thread scheduler, the pthread specification requires that the thread library schedules and run your threads for you. A thread library that doesn't make sure threads get scheduled isn't really a thread library anyway, is it?
It works, just about, I'll give it that. However, I wouldn't call it perfectly adequate, it sucks donkey balls. It is slow, inefficient, and prone to threads blocking the whole process. It doesn't take advantage of SMP. You link to the re-entrant libc version, libc_r instead of the normal libc, and libc_r is incomplete, which means that quite a lot of pthread-using code that works fine on other platforms craps out on FreeBSD. Forget about realtime threads - you can attempt to create them, but without kernel assistance they can never be truly realtime, so it's not really a full pthread implementation anyway. Worst of all, it's buggy - it doesn't take a lot of load for very long for things to start behaving erratically.
Ok, that's just the default FreeBSD pthreads, and there are better alternatives - ironically probably the best is LinuxThreads, the standard Linux pthreads before NPTL, which attempts to do 1:1 kernel threading. It seems to work ok, but it's a whole lot slower than it is on Linux, because there's no screaming-fast clone() syscall like there is on Linux and precious little other kernel assistance. It's a little buggy too, not suprising given that it's not running on the platform which it was designed for, although it's bearable. Having to link to something in ports just to get halfway-usable threads is a really dumb situation for FreeBSD to be in, and a total PITA for developers who want their threaded software to run on FreeBSD too.
This ought to be all fixed in FreeBSD 5.0, it's getting a new pthread implementation using KSEs (Kernel Scheduled Entities), basically M:N threading like most modern OS'es use (and which Linux NPTL appears to have just obsoleted as a concept;), but it isn't finished yet and FreeBSD 5.0 isn't out. Meanwhile, threading in FreeBSD 4.x is still dreadful.
But, when are they going to provide an friggin' LVM?
Err... Linux 2.4 has included Sistina's LVM for some time. 2.6 will have a more generalized kernel interface, the Device Mapper, that will allow both version 2 of the Sistina LVM, and the IBM alternative, EVMS, to be built on top. Or at least, that's what Linus seems to have decided on for the moment.
The Device Manager looks pretty, too.
I think that perhaps you are confused. Device manager? And a pretty one, at that? No LVM? Hmm, ok. Maybe you need some spelling help: L-i-n-u-x spells Linux, not Windows 2000.;)
Amazing, I've been running FreeBSD since 2.8 and I've never had an unresponsive system even while doing a build world; I guess the 2.4 kernel is alot worse than imagined.
This is, by and large, the fault of the scheduler, largely unchanged in 10 years and described by Linus, even whilst he wrote it, as a 'hack'. However, it worked, and Linus, being the extremely sensible and conservative maintainer that he is, kept it until recently - process schedulers are difficult things to get right, and their performance is crucial to the performance of the kernel as a whole. Not to mention that for the tasks that Linux has been used for historically, primarily low-volume server tasks on low-end hardware, it isn't really a bottleneck.
Still, the scheduler has been gutted and rewritten for 2.6 by Ingo Molnar - the now somewhat-famous O(1) scheduler, which performs much more fairly under load, and dispenses with almost all of the strange pauses and scheduling glitches under load. Current vendor kernels based on 2.4 (Red Hat's and SuSE's at least, I think) have had the O(1) scheduler backported to them as well. In fact, if you're running near enough any current 2.4 kernel other than mainline, you get the O(1) scheduler and your share of scheduling fairness.
The new scheduler is also a fundamental basis for Linux 2.6's new NPTL 1:1 threading, which has so far proved spectacularly (record-breakingly?) fast. Hmm, on second thoughts, perhaps I probably shouldn't mention threads and FreeBSD in the same post. I mean, isn't this the same FreeBSD that's still waiting for a single half-decent pthread implementation? Oh well, better hope 5.0 is out soon...
After all, which would you rather have, a computer, or the ability to read?
Of course what you seem to have forgotten is that a computer is a great way of getting reading teaching out to areas of the world where there is very little or no existing educational infrastructure, and improving it where it does exist. If the computers have internet access, all the better, because then the student can communicate with teachers elsewhere. Sure, it's perhaps not as good as having a real, physical teacher there in the village, but it's a hell of a lot cheaper.
My nephew (age 4) learnt to read almost entirely using a computer, and he probably learnt earlier than he would have done without it, simply because the computer was always available to teach him (unlike his parents or nursery teachers). If it works for my nephew I don't see why it can't work for rural Indians - both children and adults.
Instead of talking about the real issue, we are railing against Red Hat, because it isn't blatantly off-topic.
No, we are railing against Red Hat because they are, through their actions, deliberately perpetuating this myth that Taiwan is somehow not a country in its own right, and because I do not feel that this is an appropriate action for a company that supposedly puts the freedoms of its users - including its Taiwanese users - first. Red Hat is the one that stands accused of hypocrisy here.
This entire thread is so fucking hypocritical.
So a matter which is initially noticed and brought to our attention by Taiwanese Linux users, which they complain and bitch about, which they start an online petition for, where they feel that Red Hat is trampling on their toes - am I not allowed to stand by them and stick up for them? Because I know if I was in their position, I would be VERY pissed off, and rightfully so. How does it amount to hypocrisy that I am willing to speak out in their defence?
Don't give me the BS about the fact that I should only care about world events that I have no direct control over. I do care about these things, and I have done what is within my power - how many of you have written to your representative or gone on a political demonstration in the last 6 months? I have. But currently I am sitting in front of my computer, this issue has come to my attention today, so I am using what I feel is an appropriate and effective forum to air my views and try to get the message across. Why do you have a problem with that?
lets not try and pin the "One China Doctrine" on them for something they are hardly even perpetuating.
But this is the whole point! This is exactly the doctrine that Red Hat is perpetuating, whether you deny it or not. I, and over 4000 Taiwanese Linux users, don't think this is right.
The important thing to notice about the word "supercomputer" is that it's singular.
Ok. The word 'cluster' is also singular. Big deal.
A supercomputer is a single system image; this is implicit in the definition.
Like I said, whose definition?
I already know that some types of supercomputer work better for certain types of problems than others, all I'm doing is nitpicking at your pulled-from-the-air definition of a supercomputer that somehow magically defines that a cluster of machines cannot also be a supercomputer. Sure, they may only be individual machines connected via a network, but you use such a cluster as a single large, powerful supercomputer, even if it's not a single system image. What about MOSIX clusters? Whilst strictly speaking they are not single system image, they behave like they are - indeed, from a programming point of view they're all but indistinguishable from a single image NUMA machine, and using switched Gigabit Ethernet (cheap these days) the internode latency and bandwidth isn't too horrid either.
Your overstrict definition of 'supercomputer' makes you sound like you work for one of the old-guard manufacturers like SGI or Cray threatened by the rise of cluster supercomputers.
My argument is that clusters, arrays, NUMA machines, SMP machines, with both conventional and vector processors - these can all be 'supercomputers', because although the hardware design and programming techniques are quite different for each type, the end result for all of them is a single system (not necessarily a single system image) that solves numerical problems very quickly. They are just different types of supercomputer. If I could convince all the world's population to do maths with an abacus all at once, and I could somehow divide up the work sensibly and then collate the answers, then yes, that would be a supercomputer too - a human supercomputer, although not a particularly fast one.
What company do you work for, and what symbol is it traded under? Because the REST of us know that something as simple as a flag could be re-added by one of the 21 million Taiwaneese, if they so desire.
Ok, well let's continue, shall we? I'll submit a patch to KDE removing the US flag, because you're not a sovereign nation, you're simply a renegade province of the UK and as such, you don't need a flag. Right?
Damnit, there are some things that are more important than making money! Like freedom and democracy? Things that Taiwan has, and mainland China doesn't. It's bad enough that governments around the world have kow-towed to this Chinese insanity, but a 'free software' company?
It's not even like it makes a lot of sense economically - although the potential Chinese market is huge, the vast majority are way too poor to even afford a PC, let alone consider paying for software. Whereas Taiwan is an extremely rich, extremely high-tech country that manufactures most of the components in your PC, and doesn't bat an eyelid at the idea of paying for software. Red Hat have also quite possibly blown their chances of getting any kind of cooperation or investment from Taiwanese tech giants like Via.
A supercomputer is a single system image. Some people call large clusters "supercomputers," but technically they're wrong.
Says who?
Once upon a time 'supercomputer' meant 'any computer made by Seymour Cray', and this was reasonable, because he (probably) invented the concept. Then there was the mid-80's loose but widely-accepted definition 'any computing system that can do more than 200 MIPS'. Then MIPS went out of fashion and processors got faster and it was 'anything that does more than a GigaFlop'. Or there's the US Department of Commerce definition which was 'any computing system that does more than 195 Mtops (Million theoretical operations per second)' during the 80's, which then got changed to 1500 Mtops and is probably something different now.
Note that most Linux cluster systems would meet the requirements of most of these - indeed, most single-CPU computers today would meet most of these requirements, which is how Apple manages to get away with calling the G4 a 'supercomputer'.
Really, these days 'supercomputer' means absolutely anything you want it to be, although if I had to define it, I think probably the fairest definition would be 'anything that can run the LINPACK benchmark suite and get on the Top500 list'.
Silly it might be - that doesn't stop people from attempting it though, and buying and using supercomputers to do it with.
Fact is, any new innovation in trading quickly becomes used by everyone who has a serious enough stake.
Sure. But every time you improve the model, in theory at least you get a short period of having an advantage over everyone else - until they improve their statistical model to match or beat yours. Even if your advantage only lasts a day, and even if it's only a minor advantage, that's easily long enough to make up the cost of the supercomputer and the programming time, and then some, at least if you're a major investor.
No-one said this was something you or I would benefit directly from - at least, not unless you have a stake in the investors doing the market analyses - but to the major market investors, if it gives them an advantage, even a temporary one, good luck to them.
Supercomputers like this one are great for big calculation; not so much for big data.
If all you're doing is storing data and then retrieving subsets of it on demand, then sure, I agree. Most databases are like that - but not all. Some databases do more complicated processing than search, sort, split and join, some have to do some heavy manipulation of every record, and in these cases, CPU speed is just as important as memory or disk speed, if not more so.
Case in point: SETI. Terabytes of raw data collected from radio telescopes, no doubt stored in a large database in Berkeley, divided up into manageable records indexed by time and position in the sky. The data is absolutely worthless though, without colossal amounts of processing. So they build their own network of donated CPU time - a global data processing system - in order to turn that worthless data into something worthwhile. It isn't the disks or memory that limits speed of data processing, it's the CPU.
Of coure, if they'd had the money they could have simply bought a single machine to do all the data storage and processing, but it would still have been CPU-bound rather than disk or memory-bound. There are plenty of more conventional systems where everything is done on one physical machine, but still have the same problem of being bound by CPU.
I guess it depends on how you define a database - is a system that does complex processing of data as well as storage and retrieval still a database, or is it something else?
Slashdot Mirror
I have to say that what Linux really needs is a free top-notch vector font editor, something along the lines of Fontographer.
You mean, like pfaedit? It's almost a carbon copy of Fontographer, and very good it is for editing fonts too.
The tools (pfaedit) have been usable for about 18 months though, but still no-one is having a serious go at fixing fonts. I don't think people realise just how much time and effort goes into a font. My day job is as a graphic designer, I draw things all day, mostly using vector graphics, so I like to think I have a handle on what I'm doing and I can draw with curves quicker than most. In a past life I put together a couple of typefaces for a corporate client, and this is from my experience of that (I used Fontographer to begin with, then switched to Fontlab later on because Fontographer can't do TrueType hinting worth a damn - I do wish pfaedit had cloned Fontlab).
To go from nothing but an idea to a set of outlines covering iso-8859-1, that's about 4-5 days of solid full-time work - for a fairly simple sans-serif font in regular weight - add another day each for bold, italic and bold italic, add some more on if it's a more complicated style of typeface. Getting the kerning (spacing between characters) right is another couple of days work if you want it perfect.
Then, the nightmare part - hinting. Hinting... let's just say it's about as fun as pulling teeth without anaesthetic. To get good results on-screen, you need to allow about 2-3 hours - per character. If you want it to work correctly on more than one platform, double that. Fortunately lots of characters in the iso-8859-1 set are compound, formed of a letter and various accents and so forth, so you can just copy and paste these, but still you can easily end up spending several weeks on it - and it's the most unrewarding, boring and soul-destroying work I've ever done. Then repeat for bold, italic and bold italic.
It's all very well saying that people will re-hint dodgy fonts for fun, but you try it and see how long you last before giving up and going back to something rewarding, like writing an IRC client or GIMPing together a new wallpaper. I hope FreeType's autohinter everntually gets good enough that we can just give up on hinting.
but where there's a native control, wxWindows uses it.
Except where it decides not to, like the file dialog, which isn't anything like the GTK+ version.
I have to agree with the other poster about this: wxWindows does suffer a little from the fact it wraps widgets rather than emulating them. Layouts don't quite match from platform to platform, because the underlying toolkit has different ideas about where to put the widgets. A layout that works well with the GTK+ backend often looks scruffy in Windows, and vice versa. Sometimes the underlying widgets behave in subtly different ways, which makes the interface not behave correctly on one platform. It's tough to fix this without resorting to a lot of platform tweaks #ifdef'ed around the code, which partially defeats the point of a cross-platform toolkit.
Audacity is the canonical example, and probably the highest-profile wxWindows app too: it doesn't really look and feel like a GTK+ app when on X11, and on Windows it doesn't quite look or feel right there either, and that's with quite a lot of tweaking for platforms.
C's interface is very stable. C++'s varies from vendor to vendor and from compiler version to compiler version
This used to be true, but there is now a standard C++ ABI on Linux which all the major compilers now follow, gcc included (from 3.2 onwards). This should now be a concern of the past... about time too.
[dlopen/dlsym etc.] C++'s interface is just too messy to support this.
Which is of course why KDE uses this technique almost everywhere, dynamically loading C++ plugins on demand. KDE's component architecture (KParts) is built around doing exactly this. I think the Mozilla and OpenOffice.org component systems also work in essentially the same way. It does involve a little extra overhead (you use a ComponentFactory to create the object whose methods you call) but it's pretty minimal. It's just as easy for the programmer as it is to dlopen a C library and call functions, if not easier.
and it became a heavy anchor around Be's neck, because web page compatibility ended up sucking.
The differences here being that:
So there's no comparison really.
The *Linux community as a whole* seems to prefer KDE? What are you *smoking*? Look at the quantities of software for each, look at what the most popular distribution is.
Every poll, every survey, every popularity contest that I can remember in the last 2 years has voted KDE as 'Best Desktop Environment', including Linux Journal's Reader's Choice awards, which frankly ought to be biased towards GNOME, if you believe the theories, because of LJ's mostly North American audience. Simple as that.
Forgetting of course all the newbie Linux users who don't vote in these things, and in my experience tend to head straight towards KDE because of its familiarity for Windows refugees...
As for software - well, number one, the Linux community are not all developers. Second, I dispute the idea that GNOME/GTK has more software. Well, perhaps it used to, but GNOME 2.0 has thrown that advantage away completely. And much of that software was half-finished and duplicated 19 other projects because GNOME didn't adopt one. How many Xine frontends does a desktop need anyway?
And as for distros... haven't you met a Red Hat user who uses KDE? I've met plenty. In fact, more of them than use GNOME... but hey, that's just the circles I move in.
AbiWord isn't a Gnome app but you'd never know, it integrates nicely etc and is a good deal more active than KWord seems to be. Ditto for Gnumeric and KSpread. Noatun is just a joke, really, but it's kind of the "official" KDE media player.
You read in the article about there being something of a cultural difference between the two camps: USA vs. Europe, noisy vs. getting on with it. Well, this is the perfect example. You think AbiWord is far more active than KWord. It has more developers, more mailing list messages, more CVS commits, more releases. But look at the current in-development versions of both of them, and compare them with what they were like a year ago. I think you'll find the comparison doesn't come out in AbiWord's favour. Partly this is architectural - there's FAR more code sharing and reuse in KOffice/KDE/Qt than in AbiWord/GTK, partly because the balance of talking about it/doing it is further towards the doing it end with KWord than with AbiWord. I guess this also explains why Slashdot appears to have a tendency towards GNOME whilst the Linux community as a whole seems to prefer KDE.
And don't diss Noatun: you might not like it but from my point of view it's far nicer than anything else available. It plays all my music, has a good equalizer, does effects, the interface looks and works like everything else on my desktop (although it doesn't have to), and most important of all, happily hides itself down in the system tray when I want it out of the way and stays there. The KDE 3.1 version embeds Xine to play video: now it's the only media player I use. I love it.
On the other hand, the KDE usability effort seems to be going nowhere quickly
I take it you've not used KDE 3.1 yet then? There's some good improvements in there. And let's face it, GNOME usability still has a long long way to go *cough*GTK+ file dialog*cough*
Faster transfer speeds (Firewire2 will leave SATA in the dust).
Firewire 2 = 800 Mbps = 100MBps
SATA = 150MBps
Firewire 2 faster? Don't think so. Sure, Firewire 2 will ramp up to twice that speed eventually, but so will SATA...
SATA is also a lot simpler to implement: chipset manufacturers can reuse most of their old, highly-optimized Parallel ATA controller core. Similarly, OS writers can reuse most of their old ATA drivers. SATA has less overhead than Firewire, it's designed for data storage and data storage alone, and it doesn't do daisy chaining.
Firewire's a nice technology, and it would work for hooking hard drives up internally, but it doesn't do the job as well as SATA does, it's over-complicated (and thus expensive), doesn't have the track record, and probably most importantly, has some serious political opposition (Intel anyone?). It's always going to be the Cinderella of the ball.
The issue isn't that Apple can choose KHTML, it's more a case of why.
Other people have pointed out the corporate aspects, that Apple might not like the fact that AOL has tight control over the direction that Mozilla is headed simply by sheer weight of numbers of developers. I'd like to bring up a different reason: have you actually had a look at the Gecko source recently? It has turned into a bloated, crufty mess with many peculiar hacks to satisfy Mozilla's cross-platform nature (it seems NSPR/XPCOM is not quite abstracted enough as portability code has crept in elsewhere) and to work around deficiencies in the W3C specifications. For a browser that was started again from scratch because it was felt the previous version (remember the Netscape 5.0 code dump? ugh) was way too bloated and crufty to continue work on it, that's very sad.
In contrast, KHTML has stayed pretty lean, partly because I think Qt is a better GUI platform abstraction than NSPR/XPCOM, and partly because it has had to due to the tiny size of the development team: with only a handful of people contributing code, the code needs to be as clean and obvious as is humanly possible simply for the project to survive. It will be interesting to see whether KHTML can continue to be so lean with the addition of a bunch of full-time Apple developers onto the team.
For all the bitching about KHTML's CSS compliance, I probably ought to point out that whilst it's not necessarily quite as good as Gecko (although I have a nice testcase using floats that Gecko has never got right but KHTML aces) it's (in my tests) better at CSS than any version of IE or Opera so far.
It's been fashionable to diss anything other than Gecko since Mozilla hit 1.0. I think that needs to stop: not everyone likes Gecko, both users and developers, and it certainly is not inherently superior, despite its current marginal lead in standards compliance (and lets not forget how it now trails in performance). Open Source does not need to get behind one browser, in exactly the same way that it doesn't need to get behind one desktop either, or one word processor or one toolkit. Choice is good, and rabid Mozilla fans should be especially conscious of this, because Moz would be toast otherwise thanks to IE.
It's also tragic that I only feel confident enough to say this without getting modded down into oblivion in an article that is so obviously a loss for Gecko/Mozilla, but hey, that's Slashdot for you.
Happy Konqueror user since 2000 - yes, I remember when it could barely render Slashdot correctly - and chuffed to bits that Apple agrees with his choice. Nice to be vindicated sometimes.
From my point of view what killed TW was a gradual, slow change in the kind of stories they showed. When I used to watch TW religiously, back in the mid-late 80's, the vast majority of their items were to do with either consumer technology inventions (CD's, home computers and so on) or physical sciences (string theory, birth of the universe, or, more paractically, the first mention I ever heard of quantum computing and quantum encryption back in 1988 or so). During the 90's, in what seemed to me to be a misguided attempt to win ratings, the show gradually changed to a more human-interest type show, all about biology, genetics, medicine, until by the late 1990's that was all there was: no inventions, no physical science news, no astronomy, just item after item of medical discoveries, biotechnology, with the odd reference to the BBC's 'Webwise' project to get people hooked up to the Internet.
That was when I stopped watching it, it just didn't interest me any more. I appreciate the importance of medicine and the biological sciences (although these interest me less than the physical sciences and associated inventions), but there just wasn't anything else on TW, and it got boring because of this.
I don't think I'm alone in feeling this - I've met quite a few geeky Tomorrow's World ex-fans who say the same thing, they just stopped running the stories that interested them. It's quite a tragedy - in an attempt to make the programme trendier and gain mainstream audience share, they completely killed off their core audience, and the production team seemed to have absolutely no idea what the problem was. It's entirely the BBC's own fault.
Oh well, here's hoping they'll wake up one day, realize their mistake and revive it, just like they have with Doctor Who.
N.B. The last sentence used a technique known as irony. Some of you may wish to study and attempt to understand it.
This is just another facet of the kernel developers' jihad against binary modules. Presumption of guilt does not imply bad code, it implies prejudice(*).
Recent drivers are better than they used to be, but the nvidia kernel module really, genuinely has had a LOT of problems. I have a machine with a Geforce2 that will stay up for months when using the open-source nv XFree86 driver (which uses no in-kernel code at all), but using the nvidia binary drivers oopsed at least once a day with random memory management errors and would freeze hard about once every 3-4 days. It finally seems to be fixed in the most recent release of the binary drivers. And let's not even go anywhere near AGP support - even with the most recent drivers, if I leave the AGP support on I am guaranteed a wedged machine within 5 minutes of starting X, whether I tell the driver to use the kernel or its own agpgart support. I'm not using weird hardware either - this is a PIII Abit motherboard with Intel BX chipset - about as standard as you can get. The card is flawless in Win2k with AGP on, again using the nvidia reference drivers. If I swap the Geforce2 out for the old Rage128 I have lying about, that works flawlessly in Linux too, 3D, AGP and all, but it's a lot slower than the Geforce. Oh, and I'm using stock Linux kernels, no distro-specific stuff or strange patches. The only option that I could see in the kernel that might make a difference is using the local APIC on the PIII as opposed to using the XT-PIC, as this can mess with the interrupt delivery timings and delivering an interrupt which the driver isn't expecting might wedge it, but I tried it both ways with the same results. It ought to just work though, right?
Therfore, the only conclusion that I can draw is that the nvidia Linux binary driver is buggy, particularly with regard to its handling of AGP. I don't think I'm alone in reaching this conclusion either - I have heard plenty of fairly similar bug reports. I can't begin to debug it myself because I don't have the source to the nvidia driver. I've reported it to nvidia. I haven't bothered pestering the kernel developers with it because it's plainly not their fault and there is nothing they can do to rectify the situation.
I admit I've not tried it in another motherboard, but why then does it work in Win2k flawlessly? Ok, Win2k is also using binary drivers - but then, when was the last time you mailed an NT kernel developer with a driver bug report? You don't, you mail the driver developer if they give you an address or simply sit tight if you don't have one. That's all the Linux developers are asking too.
Put simply, the reason the Linux kernel developers tell you to piss off if you're using the nvidia binary driver is because 99% of the time that is the problem, and if you're too stupid to be able to realise that and attempt to reproduce it without the nvidia driver loaded, then you're too stupid to provide a decent bug report and your mail might as well go straight to /dev/null. Most kernel developers are drowning alive in email as it is, and that's email that's got useful stuff in it. They have better things to do, like fixing bugs in code that they have the possibility to fix.
(*) Please don't flame me for calling Linus a racist.
I'm not. I'm flaming you for being stupid and not understanding the issues involved.
As has been pointed out, Rosegarden is a sequencer, not notation software - there's an overlap but sequencers tend not to be very good at being notation software - the focus of the software is different. Having toyed with Rosegarden-4... let's just say its notation is basic, although it's shaping up to be a good sequencer.
I like noteedit myself, it's proper notation software and seems to be the nearest thing Linux has to Finale or Sibelius. It does a nice job, exports to Lilypond, MusiXTeX and a couple of other formats for printed output, and even supports guitar tabs (very useful, and something that you have to pay even more for in Finale). Mind, I don't have very complicated requirements for notation software, all I do is typeset my band's songs for posterity.
BTW let's keep the toolkit jibes out of it, shall we? It's appropriate in a story about X toolkits, but this isn't one, here it looks like partisan flamebait. Besides, if you use Bluecurve or Keramik/Geramik, they look very nearly the same anyway, so no problem, right?
There's only a single "killer app" on Linux that's written in Qt -- licq, the best-of-breed Linux ICQ client
Discounting of course the whole of KOffice, the only Linux office suite that's nice to use. Or Konqueror, the web browser, file manager and universal viewer that's actually good to use and does what it says on the tin. Or KPPP, the only friendly GUI way of getting online if you're on dialup. Or Quanta, the nicest HTML editor. Or Kate, the all-round best GUI text editor. Or KDevelop, the best IDE by miles. Or Scribus, the only DTP program on Linux worth a damn. Or Rosegarden-4 or MusE, the only halfway-usable music sequencers on Linux. Or Karbon14, now part of KOffice, not quite there yet but a vector drawing program like Sodipodi that, unlike Sodipodi, doesn't drive you barking mad.
GTK+ has more applications in number, I agree, although not anything like the 5:1 ratio you think, and few of them are large and complex. Only two of the apps you gave as examples, the GIMP and Sodipodi, could really be described as large and complex, and both of them have a reputation for having a terrible user interface. The rest of the apps you gave are all fairly small and limited in scope - a music player, a couple of p2p apps, a system monitor. Personally I think that says a lot about GTK+'s suitability for writing large applications.
Compare that with Qt, which has Scribus, Rosegarden-4, MusE, KDevelop and Karbon14 as large and complex killer apps, all of which have quite decent user interfaces, and all of which have smaller development teams than the GIMP or Sodipodi. Heck, Scribus was written almost entirely by one person! You'll note also that there aren't too many specialist commercial applications being written in GTK+ - where are the medical imaging apps or the geological survey apps, to pick two that TrollTech shows off as success stories? Or of course there's Opera, or the HancomOffice stuff. Or all the PDA stuff for the Zaurus. If the commercial licensing was really a problem for Qt, don't you think these would have been written in GTK+ or wxWindows instead?
There's this persistent myth put about by some people that no-one is writing apps with Qt, and it simply isn't true. You're just choosing not to look at them.
If you use Linux, you *will* be using gtk at some point
Not really. The only GTK+ apps I keep around these days are the GIMP and Sodipodi and they are such pigs to use I often find myself booting a VMware Win2k session to use Photoshop and Illustrator instead, even for quite small tasks. The only non-Qt app I find I use regularly is OpenOffice.org, and that's only because it's the only thing that will reliably open MS Office files - if I'm starting a new document I prefer KWord or KSpread, they play nicely with the rest of my desktop, are lighter on my system, and are easier to use.
Sun probably decided that it couldn't control the KDE people, so the GNOME approach gave it more freedom to do things the way it wants to.
You're almost certainly right on this point. ;)
Of course, freedom for Sun isn't necessarily a good thing for the end user - or the volunteer developer. Witness all the moaning about the direction GNOME 2.x is headed from... end users and volunteer developers.
my my, how do you get a +4 for a comment about GTK being broken everywhere cept with X and you have ZERO DETAILS to back that statement up
Because it's the truth. GTK+ 1.4 and 2.0 both work on Win32, but they are both exceptionally buggy - have you tried using the GIMP Windows port? It's not a good experience, and that's not just because the GIMP has a terrible interface anyway. GTK+ apps running on Windows don't look or behave like Windows apps either, they behave like... GTK+ apps. Sticks out like a sore thumb. Second, GTK+ doesn't run on MacOS X at all, not natively, anyway. The X11 version works if you have an X server installed on the Mac, but that just means you're running the X11 version, so my original statement still holds true.
I'm not saying GTK+ is crap, it's just not designed to be cross-platform (assuming you count X11 as a single platform, and I do) and it shows. I was taking issue with the idea that GTK+ is a sensible toolkit to choose if you want cross-platform apps, which the original post in this thread suggested. If you want cross-platform GUI apps, choose Qt or wxWindows - or heck, Java/Swing if you're a masochist, but don't choose GTK+, it would be a dumb choice.
QT costs money for other platforms. GTK is free everywhere.
Qt works properly on other platforms. GTK+ is broken everywhere except X11 (doesn't work, or is very buggy, doesn't look like a native app).
If you are going to recommend an alternative to Qt for cross-platform GUI development, you do yourself a great disservice by suggesting GTK+. Try wxWindows instead - a much better alternative than GTK+, although it does still have issues.
One of the biggest problems I've found when developin free software is I'll think "Ooo... this toolkit/framework has the features I need" (happened with GTK+ about a year ago) and then it'll take a month to find documentation or guides about it or figure it out from scratch myself.
So use Qt rather than GTK+ then. ;)
Seriously, the Qt documentation is superb. Complete, comprehensive, up-to-date, easy to read and navigate, and with a very good set of tutorials that range from a simple 'Hello World' app through to a full-blown game and a charting app. It's excellent even by Windows standards - but then, it has to be, because it gets sold with that documentation on Windows. Check it out here.
Don't assume that simply because some X toolkits have poor documentation (and unfortunately GTK+ is one of the poorer examples) that all of them do.
It's nothing wrong with the POSIX threads implementation, its perfectly adequate, it's just that the FreeBSD scheduler don't do on the internals of the userprocesses.
Ok, let's get this straight. FreeBSD's default pthread implementation is an entirely userspace affair, everything occurs within a single process and the thread library does co-operative scheduling of threads within the process. Not quite sure what you're getting at when you talk about writing your own thread scheduler, the pthread specification requires that the thread library schedules and run your threads for you. A thread library that doesn't make sure threads get scheduled isn't really a thread library anyway, is it?
It works, just about, I'll give it that. However, I wouldn't call it perfectly adequate, it sucks donkey balls. It is slow, inefficient, and prone to threads blocking the whole process. It doesn't take advantage of SMP. You link to the re-entrant libc version, libc_r instead of the normal libc, and libc_r is incomplete, which means that quite a lot of pthread-using code that works fine on other platforms craps out on FreeBSD. Forget about realtime threads - you can attempt to create them, but without kernel assistance they can never be truly realtime, so it's not really a full pthread implementation anyway. Worst of all, it's buggy - it doesn't take a lot of load for very long for things to start behaving erratically.
Ok, that's just the default FreeBSD pthreads, and there are better alternatives - ironically probably the best is LinuxThreads, the standard Linux pthreads before NPTL, which attempts to do 1:1 kernel threading. It seems to work ok, but it's a whole lot slower than it is on Linux, because there's no screaming-fast clone() syscall like there is on Linux and precious little other kernel assistance. It's a little buggy too, not suprising given that it's not running on the platform which it was designed for, although it's bearable. Having to link to something in ports just to get halfway-usable threads is a really dumb situation for FreeBSD to be in, and a total PITA for developers who want their threaded software to run on FreeBSD too.
This ought to be all fixed in FreeBSD 5.0, it's getting a new pthread implementation using KSEs (Kernel Scheduled Entities), basically M:N threading like most modern OS'es use (and which Linux NPTL appears to have just obsoleted as a concept ;), but it isn't finished yet and FreeBSD 5.0 isn't out. Meanwhile, threading in FreeBSD 4.x is still dreadful.
But, when are they going to provide an friggin' LVM?
Err... Linux 2.4 has included Sistina's LVM for some time. 2.6 will have a more generalized kernel interface, the Device Mapper, that will allow both version 2 of the Sistina LVM, and the IBM alternative, EVMS, to be built on top. Or at least, that's what Linus seems to have decided on for the moment.
The Device Manager looks pretty, too.
I think that perhaps you are confused. Device manager? And a pretty one, at that? No LVM? Hmm, ok. Maybe you need some spelling help: L-i-n-u-x spells Linux, not Windows 2000. ;)
Amazing, I've been running FreeBSD since 2.8 and I've never had an unresponsive system even while doing a build world; I guess the 2.4 kernel is alot worse than imagined.
This is, by and large, the fault of the scheduler, largely unchanged in 10 years and described by Linus, even whilst he wrote it, as a 'hack'. However, it worked, and Linus, being the extremely sensible and conservative maintainer that he is, kept it until recently - process schedulers are difficult things to get right, and their performance is crucial to the performance of the kernel as a whole. Not to mention that for the tasks that Linux has been used for historically, primarily low-volume server tasks on low-end hardware, it isn't really a bottleneck.
Still, the scheduler has been gutted and rewritten for 2.6 by Ingo Molnar - the now somewhat-famous O(1) scheduler, which performs much more fairly under load, and dispenses with almost all of the strange pauses and scheduling glitches under load. Current vendor kernels based on 2.4 (Red Hat's and SuSE's at least, I think) have had the O(1) scheduler backported to them as well. In fact, if you're running near enough any current 2.4 kernel other than mainline, you get the O(1) scheduler and your share of scheduling fairness.
The new scheduler is also a fundamental basis for Linux 2.6's new NPTL 1:1 threading, which has so far proved spectacularly (record-breakingly?) fast. Hmm, on second thoughts, perhaps I probably shouldn't mention threads and FreeBSD in the same post. I mean, isn't this the same FreeBSD that's still waiting for a single half-decent pthread implementation? Oh well, better hope 5.0 is out soon...
After all, which would you rather have, a computer, or the ability to read?
Of course what you seem to have forgotten is that a computer is a great way of getting reading teaching out to areas of the world where there is very little or no existing educational infrastructure, and improving it where it does exist. If the computers have internet access, all the better, because then the student can communicate with teachers elsewhere. Sure, it's perhaps not as good as having a real, physical teacher there in the village, but it's a hell of a lot cheaper.
My nephew (age 4) learnt to read almost entirely using a computer, and he probably learnt earlier than he would have done without it, simply because the computer was always available to teach him (unlike his parents or nursery teachers). If it works for my nephew I don't see why it can't work for rural Indians - both children and adults.
Instead of talking about the real issue, we are railing against Red Hat, because it isn't blatantly off-topic.
No, we are railing against Red Hat because they are, through their actions, deliberately perpetuating this myth that Taiwan is somehow not a country in its own right, and because I do not feel that this is an appropriate action for a company that supposedly puts the freedoms of its users - including its Taiwanese users - first. Red Hat is the one that stands accused of hypocrisy here.
This entire thread is so fucking hypocritical.
So a matter which is initially noticed and brought to our attention by Taiwanese Linux users, which they complain and bitch about, which they start an online petition for, where they feel that Red Hat is trampling on their toes - am I not allowed to stand by them and stick up for them? Because I know if I was in their position, I would be VERY pissed off, and rightfully so. How does it amount to hypocrisy that I am willing to speak out in their defence?
Don't give me the BS about the fact that I should only care about world events that I have no direct control over. I do care about these things, and I have done what is within my power - how many of you have written to your representative or gone on a political demonstration in the last 6 months? I have. But currently I am sitting in front of my computer, this issue has come to my attention today, so I am using what I feel is an appropriate and effective forum to air my views and try to get the message across. Why do you have a problem with that?
lets not try and pin the "One China Doctrine" on them for something they are hardly even perpetuating.
But this is the whole point! This is exactly the doctrine that Red Hat is perpetuating, whether you deny it or not. I, and over 4000 Taiwanese Linux users, don't think this is right.
The important thing to notice about the word "supercomputer" is that it's singular.
Ok. The word 'cluster' is also singular. Big deal.
A supercomputer is a single system image; this is implicit in the definition.
Like I said, whose definition?
I already know that some types of supercomputer work better for certain types of problems than others, all I'm doing is nitpicking at your pulled-from-the-air definition of a supercomputer that somehow magically defines that a cluster of machines cannot also be a supercomputer. Sure, they may only be individual machines connected via a network, but you use such a cluster as a single large, powerful supercomputer, even if it's not a single system image. What about MOSIX clusters? Whilst strictly speaking they are not single system image, they behave like they are - indeed, from a programming point of view they're all but indistinguishable from a single image NUMA machine, and using switched Gigabit Ethernet (cheap these days) the internode latency and bandwidth isn't too horrid either.
Your overstrict definition of 'supercomputer' makes you sound like you work for one of the old-guard manufacturers like SGI or Cray threatened by the rise of cluster supercomputers.
My argument is that clusters, arrays, NUMA machines, SMP machines, with both conventional and vector processors - these can all be 'supercomputers', because although the hardware design and programming techniques are quite different for each type, the end result for all of them is a single system (not necessarily a single system image) that solves numerical problems very quickly. They are just different types of supercomputer. If I could convince all the world's population to do maths with an abacus all at once, and I could somehow divide up the work sensibly and then collate the answers, then yes, that would be a supercomputer too - a human supercomputer, although not a particularly fast one.
What company do you work for, and what symbol is it traded under? Because the REST of us know that something as simple as a flag could be re-added by one of the 21 million Taiwaneese, if they so desire.
Ok, well let's continue, shall we? I'll submit a patch to KDE removing the US flag, because you're not a sovereign nation, you're simply a renegade province of the UK and as such, you don't need a flag. Right?
Damnit, there are some things that are more important than making money! Like freedom and democracy? Things that Taiwan has, and mainland China doesn't. It's bad enough that governments around the world have kow-towed to this Chinese insanity, but a 'free software' company?
It's not even like it makes a lot of sense economically - although the potential Chinese market is huge, the vast majority are way too poor to even afford a PC, let alone consider paying for software. Whereas Taiwan is an extremely rich, extremely high-tech country that manufactures most of the components in your PC, and doesn't bat an eyelid at the idea of paying for software. Red Hat have also quite possibly blown their chances of getting any kind of cooperation or investment from Taiwanese tech giants like Via.
I just don't get it. What's going on here?
A supercomputer is a single system image. Some people call large clusters "supercomputers," but technically they're wrong.
Says who?
Once upon a time 'supercomputer' meant 'any computer made by Seymour Cray', and this was reasonable, because he (probably) invented the concept. Then there was the mid-80's loose but widely-accepted definition 'any computing system that can do more than 200 MIPS'. Then MIPS went out of fashion and processors got faster and it was 'anything that does more than a GigaFlop'. Or there's the US Department of Commerce definition which was 'any computing system that does more than 195 Mtops (Million theoretical operations per second)' during the 80's, which then got changed to 1500 Mtops and is probably something different now.
Note that most Linux cluster systems would meet the requirements of most of these - indeed, most single-CPU computers today would meet most of these requirements, which is how Apple manages to get away with calling the G4 a 'supercomputer'.
Really, these days 'supercomputer' means absolutely anything you want it to be, although if I had to define it, I think probably the fairest definition would be 'anything that can run the LINPACK benchmark suite and get on the Top500 list'.
Nice try at creative redefinition though.
simple economics shows why the above is silly.
Silly it might be - that doesn't stop people from attempting it though, and buying and using supercomputers to do it with.
Fact is, any new innovation in trading quickly becomes used by everyone who has a serious enough stake.
Sure. But every time you improve the model, in theory at least you get a short period of having an advantage over everyone else - until they improve their statistical model to match or beat yours. Even if your advantage only lasts a day, and even if it's only a minor advantage, that's easily long enough to make up the cost of the supercomputer and the programming time, and then some, at least if you're a major investor.
No-one said this was something you or I would benefit directly from - at least, not unless you have a stake in the investors doing the market analyses - but to the major market investors, if it gives them an advantage, even a temporary one, good luck to them.
Supercomputers like this one are great for big calculation; not so much for big data.
If all you're doing is storing data and then retrieving subsets of it on demand, then sure, I agree. Most databases are like that - but not all. Some databases do more complicated processing than search, sort, split and join, some have to do some heavy manipulation of every record, and in these cases, CPU speed is just as important as memory or disk speed, if not more so.
Case in point: SETI. Terabytes of raw data collected from radio telescopes, no doubt stored in a large database in Berkeley, divided up into manageable records indexed by time and position in the sky. The data is absolutely worthless though, without colossal amounts of processing. So they build their own network of donated CPU time - a global data processing system - in order to turn that worthless data into something worthwhile. It isn't the disks or memory that limits speed of data processing, it's the CPU.
Of coure, if they'd had the money they could have simply bought a single machine to do all the data storage and processing, but it would still have been CPU-bound rather than disk or memory-bound. There are plenty of more conventional systems where everything is done on one physical machine, but still have the same problem of being bound by CPU.
I guess it depends on how you define a database - is a system that does complex processing of data as well as storage and retrieval still a database, or is it something else?