How much more could we squeeze into that spectrum if they re-did it taking into account those fabulous new mpeg4 codecs that allow DVD quality data streams for only 150-200 KB/s.
Nice idea, but you've got to draw a line in the sand somewhere and standardize on that. MPEG-4 will no doubt be bettered in a few years, do you make everyone upgrade then? What about the next codec after that? And after that? If you make people upgrade, sure it's good for sales, and you'll get more channels into the same bandwidth, but pretty soon most people will object to being gouged and won't bother buying new TVs at all, leaving a confused mess of legacy standards that become a nightmare to support, and the manufacturers bankrupt.
People are used to upgrading their computers fairly regularly and there are often compelling reasons to upgrade, which is why this tactic works there - although notice how many ordinary people still have ancient computers sitting on their desks. TVs last a lot longer - maybe 10 years for a decent one, longer if you're lucky. The tactic would fall flat on its face here - look at the difficulty getting everyone to switch over to the existing digital standards, and they have a lot more going for them than just extra channels over the existing standard.
Perhaps it would be possible to download the codec to the receiver, to take advantage of new developments - but typically, newer codecs require more processing power, and you can't download a new CPU. In any case, MPEG4 isn't actually that much of an improvement over MPEG2, if at all, for proper broadcast-quality video, as it's optimized for minimum bandwidth rather than maximum quality. Even the best quality DivXes look kinda poor compared to DVD.
I'm fairly confident digital TV will still be using MPEG2 in 15 years time - that's still less than half the time that colour NTSC has been around.
So if I don't buy into the "everything is disposable" routine and am still using a ten-year old tv in 2006, suddenly I will be treated only to static and a few pirate tv channels being broadcast from teenagers' backyards(until the FCC shuts them down of course).
No. You will buy a $99 (maybe even less) box that sits on top of your TV and decodes the digital signal so that your old TV can display it. Every other form of digital TV does this currently, and in fact I have yet to see TVs with integrated digital cable or satellite decoders. In the UK the government is considering giving them away to the stragglers if digital terrestrial TV hasn't taken off enough by the time the analogue signals are shut off. Perhaps the FCC might do the same if they're desperate for the frequencies. You get more channels and better picture and sound.
In any case, 2006 is only the date when all new TVs must have built-in decoders - it says nothing about the actual shutoff date for analogue transmissions. In the UK that's set for 2010, although that could change by a year or two in either direction depending on adoption rates and how the government plays it, and the UK is a little bit ahead of the US in the adoption curve.
and the basis for KDE (and, indeed, current versions of Opera). Qt is Norwegian.
TrollTech especially is becoming a very important player in the software industry. They are at the vanguard of fighting Microsoft in both the desktop space with Qt/KDE and in the embedded space with Qt/embedded and Qtopia (as used in the Sharp Zaurus). They are already a great advertisement for and asset to Norway, and if they can keep it up could easily become one of the most important software companies in the world.
In this light I'm not suprised at all that the Norwegian government is opening up to alternatives. By supporting the local software industry, Norway can a) reduce its imports of foreign proprietary software, b) help increase its exports of software, and c) reduce the reliance on all forms of proprietary software (both TrollTech and Opera are extremely Linux and free software friendly). This adds up to a boost for the Norwegian economy, secures local jobs and increases tax revenues flowing to the government. All in all a big win for Norway.
Let's hope the Norwegians really do take it a stage further and start choosing some of their own software. It's a big leap to make but ultimately the Norwegian people will benefit.
These are just a few off the top of my head, there's plenty more. The Mac has (or had, at least) its fair share too, e.g. MacPaint, MacDraw, MacWrite, MacAMP/Macast.
You see, it's just a way of associating the program with the environment where it runs. The fact that KDE app developers love to associate their apps with KDE via the name suggests to me that they generally think very highly of KDE. Call it 'platform patriotism', if you will. End-users like it because it sounds like the app is specifically designed for the environment and follows the same style guidelines and conventions. Never underestimate the power of a name.
Why do you think WinZip became the dominant zip archiver on Windows? I'm pretty sure it wasn't the first, it doesn't come from the people who invented the zip format, it isn't free like some Windows zip archivers (nasty nagware) and I don't think it has the best user interface either (although that's arguable).
In short, it's just good marketing for an app, and that matters as much to free software authors as it does to commercial developers.
I would hope that in the future developers would start putting a small description of their program within the About menu item.
Ummm, have you actually used KDE or are you simply pontificating pointlessly?
Open Konqueror. Go to Help->About Konqueror. In the about box that pops up, on the default 'About' tab, it says: 'Web browser, file manager,...' which sums up pretty well what Konq does.
Similarly, in the same place in KMail: 'The KDE Email client'.
Or in Kate: 'Kate - KDE Advanced Text Editor'.
Or in KSirc: 'KDE Irc Client'.
Or in Konsole: 'X terminal for use with KDE.'
Pretty much every KDE program has exactly this. You get the about dialog for free when you use the KDE framework, and all the developer has to do is fill in a few blanks.
Not to mention, of course, that the app gets a description in the K Menu as well - for instance, KMail's entry looks like: KMail (Mail Client)
Perhaps GNOME doesn't do these things, I can't tell you (I haven't had GNOME 1.4 installed for about a year and GNOME 2.0 was installed for a total of about an hour whilst I checked it out and decided I didn't like it) but as far as KDE is concerned, you're dead wrong.
GNOME 2.0 has been rushed out of the door, just like GNOME 1.0 was.
The 1.4->2.0 development cycle has been a lot longer than originally anticipated, due to a big influx of developers (Thanks Sun!) and lots of core systems changing quite radically, coupled with some pretty piss-poor project management (now where have I heard THAT before?). In the mean time, KDE has been gaining a very large amount of traction as the most popular Linux desktop, and Sun has been wanting to push Solaris 9 out the door ASAP.
So GNOME had to release now, really, if they had any hope of keeping the users they have and for Sun to get Solaris 9 out approximately on schedule.
KDE underwent a similar change about 2 years ago, in the 1.1.2->2.0 transition, and not everyone was convinced then that KDE would survive, but it did, and look where they are now. Of course, KDE had the advantage of doing it first - although KDE 2.0 was far from perfect UI-wise, it had a considerable lead on GNOME in changing to a component-based architecture, so there was a very big Unique Selling Point for it at the time which GNOME 2.0 does not now have.
It took KDE 2 further major releases to turn the framework they built into a really nice desktop, and I suspect it will be similar for GNOME. The big question is whether the framework that was built for GNOME 2.0 will be good enough for their future plans... time will tell.
Personally I'm sticking with KDE3 for now. There are certainly issues with KDE, mostly in terms of speed and size, which themselves mostly stem from the choice of C++ rather than C, but these are being fixed one by one. KDE3 is now quite snappy, actually quite a bit faster than GNOME 2.0 on my Debian machine once you've got past logging in (all those double-buffered GTK+ 2.0 widgets are smooth and dandy, but they sure as hell ain't fast). Also, right now, KDE absolutely has the edge on both functionality and usability. Konqueror in particular is way out in front - indeed, for me at least, it's the best file manager on ANY platform. Nautilus is good, don't get me wrong, but Konq is breathtaking.
I'll reassess the situation when GNOME 2.2 is out. 2.2 should be the first mature release of the new framework, then we'll really get to see whether it's good enough to compete. I'm hopeful, a lot of the new framework looks good but either needs loose ends tidying up or needs someone to use it properly. Let's keep our fingers crossed. KDE is a class act to go up against though - they crank out the releases on time every 6 months, they seem to have a consistent vision of where they're going, they know where their flaws are, and they have yet to make a serious error. GNOME can't afford any more releases like this one if it wants to stay in the game.
Note that, according to the author of the Savage driver, he has no ProSavage DDR hardware to test on, so don't bet on it, but hopefully it should work (as with most drivers, it's just a matter of adding a hardware ID to make it work, assuming the hardware vendor hasn't messed around too much since the previous version, which is unlikely in this case)...
Hope this helps some people...
When the rest of the world cannot fight back...
on
X-45 Makes Debut Flight
·
· Score: 5, Insightful
...through conventional means, then the rest of the world must play dirty.
Increasing automation of weaponry, and now, total remote control has led and will lead to fewer and fewer deaths of American servicemen and women. This, in turn, removes the single biggest reason for the American political establishment to hold back from launching into war; if there are no body bags flying home, who is going to bother voting these politicians out of office? If a victory can be gained quickly and the opposing side forced to follow the American Way, generating a tidy profit in the process for those American companies that will help them see the light, it is entirely good political karma. Where once a diplomatic solution would have been applied, politicans will be all too keen to apply military solutions instead. No risk, all gain.
America cannot expect those in the world who do not share her views to sit idly by whilst this happens. When people are fighting for what they believe to be their country or their way of life, they will continue to fight back no matter what the military imbalance may be against them. This can be seen, for instance, in the current Israel/Palestine conflict, where despite being massively outgunned and confined to very limited areas, the Palestinians continue to get back up off the floor and keep fighting.
Notice how the Palestinians fight back. They do not have a conventional army, so they must choose other means. Currently, their method of choice seems to be the suicide bomb, and they are called terrorists by the Israelis. The Palestinians, of course, who believe that they are fighting to regain their homeland, call them martyrs.
This is what lies in store for America should she choose to go down this path. Without fear of being voted out of office thanks to the technology, American politicians will throw the country into many wars, and no doubt she will win them in spectacular fashion. However, the opposition will fight back, not through conventional means but through 'terrorism'. It is easy to infiltrate a country as proud of its freedoms as America. What lies in store then? Suicide bombs? Information warfare? Or worse?
We have already seen this scenario once, with September 11th. I am firmly of the belief that the key driving force behind Bin Laden is that he feels his homeland, Saudi Arabia, is being 'occupied' by American forces stationed there since the Gulf War. Of course there is much more to it than that, but it is all too convenient that his anti-American rage became prominent only in the years following the Gulf War.
When this starts to happen, how do you stop it? The obvious way is to restrict those very freedoms that allow the enemy to infiltrate and perpetrate this 'terrorism'. Then what happened to the 'American Way', the very thing that the war was meant to be protecting in the first place?
It's time we started thinking about some of the consequences of the great superiority in American military technology, before those consequences come back to haunt us.
OpenGL 2.0 addresses exactly your concerns - a vendor-neutral shader programming language, and this is precisely why you're seeing 3Dlabs pushing hard for it. It seems they will be first to market with a fully programmable graphics pipeline, and they need the software technology to go with it...
DirectX 9 also addresses the same issues and provides a standard shader language (actually DirectX 8.1 has a standard shader language already, but it lacks a certain amount of the programmability that will be present in DirectX 9), but there are a lot of reasons for the graphics card vendors to favour OpenGL over DirectX. For instance:
There are a lot of users of high-end 3D hardware for whom Windows is anathema. Think about all the effects shops that traditionally have used IRIX and are now moving over to Linux... DirectX ties the cards to Windows, OpenGL does not. This is a growing, and more importantly, prestige market for high-end PC 3D vendors... Linux is bringing them to the PC from SGI/IRIX solutions, and is bringing them sales with it. I think NVIDIA understand this one, just a shame few of the other 3D vendors do yet...
There are an awful lot of 3D apps that are heavily tied into OpenGL and rewriting them for DirectX would be a serious undertaking, whilst modifying them for OpenGL 2.0 to take advantage of the new shader features and extra programmability of the graphics pipeline will be a relatively simple task in comparison.
What if Microsoft decided to get into the 3D market by buying one of the existing major players? Sure, Microsoft might be responsive to the 3D vendors now, but I suspect they wouldn't be if they had a vested interest in one of the players. Perhaps it seems unlikely, but it seems Microsoft has ambitions in the hardware business - witness the X-Box. It's a doomsday scenario from the point of view of the 3D vendors, sure, but no doubt it's something that a few vendors have thought about.
Even if Microsoft doesn't do such a thing, OpenGL allows them 3D vendors room to breathe - they can implement new features as they please without Microsoft having to give them the nod.
Hopefully OpenGL 2.0 will see a resurgence in OpenGL use. I don't like the idea of the 3D market being controlled by Microsoft, and I don't think the 3D vendors do either. Kudos to 3DLabs for leading the way!
The specs were great, but the actual implementation and drivers, well, sucked hard.
Sure, the Permedia wasn't the quickest card on the block in its time, and neither was the Permedia 2 nor the Permedia 3...
But both the NT and Win9x drivers were absolutely 100% rock-solid, the OpenGL implementation was flawless and very, very fast, and the card supported a whole bunch of features that no other consumer-level chipset at the time supported, like anisotropic filtering, or multiple video overlay windows at once. The RAMDACs were really good on the Permedia 2 also - razor-sharp, much much better than the TNT2 I ended up replacing it with. It was also rather faster at GUI acceleration than the TNT2, which was a surprise and a disappointment.
Really it was a semi-pro card at consumer-level prices. It would never have been the card you bought if you wanted the ultimate Quake framerate, but it absolutely oozed quality.
It's the only graphics card I've ever used that hasn't annoyed me in some way, be it dodgy image quality (NVIDIA, S3), unstable drivers (ATI, NVIDIA), bus latency greediness (NVIDIA, S3, Matrox, often leads to choppy, stuttering audio), or just being dog-slow (all the usual suspects - hello Trident, earth calling). I've never used a 3dfx card for more than a few minutes so I can't really comment on them, but I suspect their poor OpenGL support would have annoyed me greatly.
If only 3Dlabs had 3d-accelerated Linux drivers (preferably open source) I'd buy another one in a heartbeat. I've been disappointed with every other card I've had since my Permedia 2...
Funny name, yes, but it's rapidly become my second-favourite MUA (after KMail) and certainly my favourite on Windows. It has support for both PGP and S/MIME encryption and signing (although it uses its own built-in PGP implementation which I'm not entirely happy about). It's not free in any sense of the word either (it's 30-day trial shareware), but hey, this is Windows we're talking about.
The X extentions are so damn complicated that no ones using them, KDE isnt using Xrender, Gnome isnt using Xrender, hell even Enlightenment isnt using Xrender, the only people who seem to be able to make Xrender work, are the programmers working on it.
This only goes to advertise to the world exactly how little you know about X and how little attention should be paid to your misinformed rants about it.
Fact: Qt 2.2 and later (and by extension, all recent versions of KDE) have been using the Render extension to display anti-aliased text for over a year. This was achieved through support of the Xft library, which uses Render to composite text on-screen.
Fact: Qt 3 and up composite QPixmaps onscreen using... yes, the Render extension (allowing for a full 8-bit alpha channel). This is used to great effect throughout KDE 3, where it is used for alpha-blending of icons, translucent menus, and various other neat effects, all with hardware acceleration where it is available.
Fact: GTK+ 2 and up composite GdkPixbufs using... the Render extension (again, allowing for a full 8-bit alpha channel). I'm sure it'll be used in GNOME 2 for all sorts of neat eye candy.
Fact: Xft (which of course, uses Render) support has been hacked into Mozilla. I point this out especially, as in previous posts on/. you seem to pride yourself on being an ardent supporter of Mozilla...
NO where else have I seen alpha channeling in linux than from keith packard the creator of the Xrender extention.
Open your eyes then. It's everywhere, certainly all over my desktop anyway. If you want to live in the past, feel free. If you want to ignore it, feel free. Spreading misinformed, baseless FUD about one of the most significant modernizations to have happened to X in its entire lifespan isn't appreciated however.
What good is an overly complicated undocumented hard to use API on top of a bloated badly designed implementation of X?
The Render extension is a sensible, well-thought out solution to many of X's previous shortcomings. It's not perfect, but then - it's not finished yet. As for documentation, what do you need exactly? The wire protocol for Render is pretty comprehensively documented, and if you're merely trying to use it in an Xlib program, well, there's always the source code to look at. Yes, that's not perfect, but Render is the work of just Keith, and XFree86 is short-staffed enough as it is. Again - it's not finished yet! In any case, it seems that's enough for Trolltech and the GTK+ developers...
I'm also going to argue here that XFree86 isn't bloated and neither is it badly designed. What it is is massively short of good developers, especially those that are interested in working on the internals of the X server as opposed to just getting the latest and greatest features of their new graphics card working. It's an engineering project as big as the Linux kernel or KDE or GNOME, but with only about 5 people working on the core parts. Is it any wonder it develops more slowly?
Of course, if you were that concerned about X, I'd suggest you go and start hacking code for it, because that's the only way it's going to get better. Except, you're not a graphics programmer are you? Because if you were, you wouldn't have made such baseless allegations about X, and certainly wouldn't have made such basic factual errors as you did in your post.
Hardly surprising given what the OS/2 Win16 compatibility layer was: Windows 3.1 run in a virtual 286 (thus in standard, not enhanced mode, which is why some apps wouldn't run), without the Program Manager. IIRC there were two versions of OS/2 you could buy at one point, one with a cut-down copy of Win3.1 included (that Microsoft let them include it was a legacy from agreements signed during the Microsoft/IBM co-operation days, although Microsoft was still getting a licence fee from it) and a cheaper version which asked you for your Win3.1 disks during installation.
A much more fair comparison would be with Win4Lin, which attempts to do much the same thing with Windows 98, i.e. run it in a virtual machine without Explorer, and display the application windows on an X desktop.
Win4Lin is actually a more impressive achievement, as in order to run Win98 it has to virtualize a 386 in protected mode, which is hard, as opposed to virtualizing a 286, which is really really easy (the 386 and above has hardware especially designed to do this).
Either way, whether you run Win16 apps in OS/2 or anything Win98 can run in Win4Lin, you have paid the Microsoft tax and are running Microsoft code.
The other approach to running Windows software on other systems is to reimplement the Windows API. Some projects that do this are basically ports of Microsoft code (like Mainsoft's MainWin, which is used in the HP-UX and Solaris versions of IE). Just two projects have ever done this without using any Microsoft code: Wabi and Wine.
Wabi was very successful in its time, providing a complete Win16 layer on lots of UNIXes, and something that even Wine doesn't do: an i386 emulator for people who want to run Windows apps on non-IA32 architectures. Unfortunately it never got much Win32 support and, being a proprietary product, died a death a few years ago.
So we're left with Wine, the most ambitious Windows emulation project of them all: efficiently reimplementing all of the Win16 and Win32 APIs and ABIs, without any Microsoft code, and all as free software.
it seems like the developers are more interested in using the code for proprietary emulation for running specific programs (games, plugins) or porting (corel stuff, etc.) than producing a general, Free, universal windows emulator.
They are effectively rewriting about 30% of Windows, with only Microsoft's published documentation and reverse engineering as references. They have to be bug-for-bug compatible (this is the real killer). The core team is absolutely tiny compared to Microsoft's Windows development group.
Is it any surprise that they are trying to do what they can as they get things working? They are doing stuff that people would have thought near-impossible just a couple of years ago, even by an extremely well-funded corporate behemoth like Sun or IBM.
It would seem that Wine is the most underappreciated of all the major free software projects out there, which is such a shame given its promise.
Give Wine some time. I know it's been a long wait already, but the pieces are falling into place right now, and it shouldn't be too long (measured in Wine time, of course;) before Wine gets to version 1.0. When that happens, expect repercussions for years to come.
Amazingly enough, the receptionist knew right off the bat. Helvetica.
I don't know if Michigan road signs are different (never been), but in the rest of the US it's not Helvetica that's used. The Federal Highway Administration has its own set of typefaces that aren't really all that similar to Helvetica.
Knock-offs of the most common US highway typeface are available here. For me it's a lot more readable and a lot more attractive than Helvetica.
Yes, I'm another font obsessive. When I'm not looking after their network, I'm a designer for a sign company, so I guess it's my job to know these things.
As for Knuth (trying to get back on topic here), he's done an awful lot for both computer science as a whole and for digital typesetting, but what on earth was he on when he designed Computer Modern Roman? Ok, it's instantly recognizable, but it's also butt ugly and not very readable even on paper (too spidery, it would be a lot better if the horizontal stem widths were wider). On a low-res computer screen, it's a typeface disaster.
Why not *pick* to copy Apple's HCI and adopt it for the Linux desktop?
Did it ever occur to you that the Mac UI is not the be-all and end-all of user interface design? No, because the Mac UI is 'holy' and many proponents of it adopt a 'holier-than-thou' attitude, yourself included. I can't deny that MacOS 9.x is pretty good from an HCI point of view, but is it as good as some Mac disciples make it out to be? Hardly.
There are actually quite a number of areas where MacOS 9.x is deficient compared to other systems, from a usability point of view. Let's list a few of the major ones, shall we?
The Task Switcher - requires 2 clicks to switch application, compared to 1 click with a Windows-style taskbar. This is one of the disadvantages of having a single top-level menubar, as there isn't enough screen real estate to have a taskbar as well. Of course OS X has both a panel and a top-level menubar, which is great. Except that now about a third of your screen is unavailable for application windows.
The Finder - yes, Finder has usability problems. People crow about the Finder being 'spatial', meaning that directory windows and the icons contained within retain the same size and position as when they were previously opened. This is good, as the human brain is very good at remembering sizes and positions. What isn't mentioned is the side effect this causes - when every directory is opened in a new window, the screen rapidly fills up with windows, overwhelming the user. It is possible to tell the Finder to close the previous directory window when opening a new one, but only with a non-obvious keyboard modifier when double-clicking. Also, if the previous directory window has been closed, it is now impossible to navigate backwards. Other systems (Windows included) have found solutions to this problem - why hasn't the Mac?
Context Menus - The lack of a second button on the standard Mac mouse is for some a boon in terms of simplicity. However, for anyone past beginner level it is a serious usability handicap. Context menus have been shown to be a major enhancement to mousing efficiency, but by and large, Mac apps ignore them as they require use of a keyboard modifier or a non-standard mouse. It is amusing to note that the Mac, the most mouse-centric of all desktops, requires the keyboard for something as simple as a context menu. Which brings me on to...
Keyboard navigation - or the lack of it. You're stuffed on a Mac if you can't use the mouse. The menubar is totally off limits to you, which makes the computer all but useless. The Finder allows a certain amount of keyboard navigation, but again, without access to the menubar you have a problem. Remember, not everyone has the faculties to use a mouse, and if this is the case for you, forget every other question about usability - a Mac just isn't usable.
There are more usability problems than this - these are just the first that came off the top of my head. Note also that both Windows and the Linux GUIs have avoided all these problems, and also come up with some good ideas that Apple hasn't even touched on - like the universal viewer application (Explorer, Konqueror, Nautilus), or thumbnailing of all pictures, not just the ones that the creator app decided to attach a thumbnail to.
Perhaps it isn't such a good idea to be blindly copying the Mac after all?
Don't even get me started on OS X, right now it's an ill thought-out usability nightmare. I'm sure it will get better, but right now it's the last place to be looking for usability ideas. It's pretty, yes, but pretty does not equal easy to use.
Of course, the problem is that most people don't have access to a Mac and don't know what it's like to use a Mac and don't understand the Mac gestalt, otherwise they'd be using Macs already...
Suuuuure. When you finally wake up and pull your head out of the sand, be sure to let us know, ok?
In the meantime, the rest of us can get on with using and improving our GUI experience, pulling the best ideas from existing GUIs as well as inventing new ideas. Blindly following anyone is a seriously poor idea.
So can anyone prove that these aren't just screenshots of Windows 2000 with a stardock skin?
I can't prove it to you beyond doubt, but I know KDE when I see it, and this is it. The folder icon on the desktop is a dead giveaway (all the other icons seem to be customised, but this one has been left as the KDE default), as are the handles on the panel applets, which appear to be from Qt's built-in Windows style. Also, the window decorations (close/maximise/minimise buttons) are the KWin 'Redmond' style. Note the gradient on those buttons, Win2k's are flat. Note also the inconsistency between the applet handles on the panel and the toolbar handles in IE and Word - if nothing else this should prove that this isn't a WindowBlinds skin.
I have previously run both IE and Word successfully under WINE, and Notes is also supposed to work - yes, WINE even sets the right icons in the taskbar as the Lindows screenshots show.
So, it's pretty obvious to me that this is indeed Linux, and it's real. All it is is a distro with a slightly customized KDE and WINE setup to launch Windows apps. No great shakes, I can do all this already on my Debian box, and you can do it too on any distro that includes KDE and WINE.
If you still don't believe me, it'd be pretty easy to knock up similar screenshots under any of the major distros. Anyone fancy a go? I won't get a chance until I get home tomorrow...
If you're still not sure after all that, you're going to have to (gasp, shock, horror) actually sit down in front of a Linux box and see it in action yourself.
...or (horror of horrors) compile glibc yourself with Jakub Jelinek's prelinker patches, if you can find them (they seem to have disappeared off the net).
The dynamic linking of libraries is by far the biggest cause of KDE program startup slowness. A big desktop environment has a lot of shared libraries to link to an application at runtime, it's expensive computationally (particularly for C++ libraries), and the way the glibc dynamic linker works right now, it's done every time an application is started or a library is dlopen()'ed (such as when embedding a KPart). It can also cause swap thrashing on machines with limited memory (the entire library must be read into memory to perform the address relocation, only after relocation can the VM drop pages of the library) and obviously, disk contention between this swapping and the application loading can slow things down even further.
What the prelinking patches do (don't get them confused with the objprelink hack which, while useful, is not a long-term or efficient solution) is move the linking time from application startup time to system startup time. A tool runs at system startup, immediately after ldconfig runs, which loads and relocates libraries in its search path, then notes down the relocation addresses. Then, later, when the dynamic linker is asked by an application to load a library, it simply uses the values that were cached earlier. Any libraries that have not been 'prelinked' are simply relocated as normal. The linker also makes sure that non-prelinked libraries are not relocated into the same address space as any prelinked libraries that are not currently loaded.
The next major version of glibc will hopefully include library prelinking by default, but I haven't been following glibc development closely enough to know for sure. Let's keep our fingers crossed. Note that it's not just KDE that will benefit from this, Mozilla will gain a great deal (it, like KDE, is mostly C++ code split into many shared libraries) and even GNOME will benefit a little - doing the dynamic linking on C libraries still costs processor time, although it's much less than with C++ libraries.
The next biggest cause of KDE startup slowness is icon loading - currently every app has to search through the entire set of available icons on startup in order to load the icons that it needs. Not very efficient. Given that KDE has several hundred icons available already and that is likely to increase over time, it needs a solution. Waldo Bastian is apparently working on an icon server for KDE 3.0, which will do that search once, cache the data, and then respond with appropriate icons when an app asks, rather than forcing the apps to do it themselves every time. I'm hoping it also makes it easier and faster to do image compositing (overlays and so forth) with icons.
To sum up: glibc 2.3 together with KDE 3.0 should make a huge improvement to app startup (and KPart embedding) time, and, assuming the KDE guys are tight with their code, may even make KDE 3.0 usable on machines that couldn't effectively run KDE 2.x.
I'd be the first to admit that I much prefer KDE/Qt, both from a user and technical viewpoint, but it is excellent to see GNOME and GTK+ applications making great strides too.
There was a point not so long ago where I feared that GTK+ and GNOME had lost their way completely, and that would have been sad - I think the friendly (and sometimes not-so-friendly;) rivalry and cross-pollination between the systems has been a bigger win than the split of resources has been a loss. Neither system can afford to sit on their laurels for too long or else the other will take up the slack and make them irrelevant.
It does remain to be seen, however, what will happen with GTK+/GNOME 2.0 - it has been a very long time in coming, and in the meantime KDE 2.x has built up a very large (but not unassailable) head of steam. It's very important that the GNOME guys get 2.0 right (not like the 1.0 release - remember that disaster?) if they want to continue to be more than a bit-part player.
I watch the mailing lists with interest... it's a great soap opera:)
The machine freezes EVERY time because of memory shortages. The kernel can't allocate pages for incoming network traffic, causing a backlog, causing processes to hang, causing further backlog.. then powie an unresponsive machine.
This was a common problem with kernels from about 2.4.1 up to 2.4.9 - the machine would gradually eat into swap further and further, failing to release no-longer-used swapspace, until it would go Out Of Memory (OOM) and attempt to kill the process that was eating all the memory. Frequently it would pick the wrong process to kill (sometimes even killing init) or would end up deadlocking.
I agree with you - that is no way for a virtual memory system to behave.
However, the Linux development process moves quickly once people get annoyed enough to actually do something about it, and that's precisely what has happened. Starting with 2.4.10, a new, simpler VM system has been used in the official Linus kernels, and I can say with some confidence that it has solved all the major problems with the 2.4 VM system, and continues to get significantly faster with every release.
If you haven't actually tried a new kernel yet (and from your problems it seems that you haven't), I suggest that you do - it's made the world of difference for me.
At the same time, the old 2.4 VM has lived on in the -ac series of kernels, and has become a great deal better there - some competition has made a big difference. Almost all of the major areas where it behaved badly have been fixed. However, my own impression is that it is still somewhat slower than the new VM.
The choice is yours which you want to run - my own recommendation would be for the new VM in the official Linus kernels, but others may disagree.
[OOM Killer] NEWS FLASH they took this feature out because it was buggy.
Umm, no they didn't - it continues to exist in both the new VM in 2.4.13 and the old VM in the most recent 2.4.13-ac kernels. It does, however, now work correctly in both VMs. There are some philosphical arguments over whether killing processes is the best way of handling an Out Of Memory situation, but it is surely better than deadlocking the box, which is what most VM systems (including the famed FreeBSD's) do when OOM occurs.
It's been getting better with each dot release but it's still nothing you'd want to bet money on.
All I can say is that the new VM works great for me and lots of other people, even under extreme load. I can certainly understand your pain if you're using an older 2.4 kernel, but please try a recent one - the difference is astounding.
If you're still having problems with recent kernels, then I'm sure linux-kernel@vger.kernel.org would love to hear from you - and would certainly be a lot more useful to you than ranting on Slashdot. Getting the VM right is now priority number 1 for the kernel hackers.
Isn't that almost exactly what Adobe were suing Macromedia over? Has the US Patent Office granted both of them almost exactly the same patent?
This could get interesting...
Qt/embedded is already the best choice
on
Palm OS Spinoff
·
· Score: 3, Informative
Running Qt/Embedded has all sorts of disadvantages, however:
You can't use X11 remote display for development on/for the handheld anymore.
Use VNC instead then. VNC is also much more useful than X once the palmtop is out in the wild - palmtops don't usually have constant network access when they're in your pocket, and VNC can detach and reattach easily to existing sessions, even if you change your IP address in the mean time. X requires a constant network connection or else the app that you're running over X dies.
You can't share the handheld screen between applications written in different toolkits anymore.
And this is a bad thing? Personally I'd be very happy to see embedded Linux not making the same usability mistakes that desktop Linux has in the past, and which it is only now recovering from. Lots of toolkits == inconsistent interface == usability problems. Diversity is great, but there are places where it is inappropriate, and user interface is one of them. Not to mention the bloat aspect of having multiple toolkits...
You are tied to a single toolkit for handheld development.
See above.
Don't forget that Qt/embedded is also API-compatible with Qt/X11, which means that porting Qt apps from the Linux desktop is a cinch - and that's how Opera and Konq/e have been so rapidly successful - they are both based on Qt. Don't underestimate the importance of having a good browser for a palmtop. The only browsers I've seen for X11 that are optimized for display on a small palmtop screen are... Opera and Konq/e. You might as well run them under Qt/embedded.
How many full-blown browsers do you know written in FLTK or Java? Maybe when there's a nice tiny browser for FLTK using Gecko as a rendering engine there'll be something to talk about.
As for size, well, perhaps TinyX+FLTK+Blackbox really is no bigger than Qt/e. But think about what you get with Qt - Signals and Slots, a fast and very powerful canvas widget, full-blown Unicode support, in fact, all the nice features that have made Qt a huge success on the desktop. And, as I've said above, porting the multitude of existing Qt desktop apps is a no-brainer. Not to mention of course that the superb QPE is available, so if you want a complete environment for your users, it's just a compile away. No additional coding required.
FLTK doesn't offer any of this. In fact, no current X11 toolkit other than Qt itself offers all this. If you start adding other toolkits on top of TinyX then you can make up for some of the more important features... but oops, there goes your size, and your consistent interface.
If you have political problems with Qt, then say. You certainly seem to be short on valid technical problems.
I'm sorry but I have a huge problem with running KDE when there's a dependency on proprietary software.
Sigh. How many times does this have to be explained before people get it?
Qt is Open Source software.
The X11 version (which is what KDE depends on) is licensed under either the GPL or the QPL, at your choosing. If you develop proprietary software (i.e. under a license that is incompatible with either the GPL or the QPL), then a paid-for commercial license is required. This is how TrollTech make their money. Either way, you get full source code.
Even Richard Stallman has given his blessing to KDE and Qt's licensing scheme.
One concern that goes through my mind when I look at the not very stunning performance of Crusoe is the effectiveness of VLIW (very long instruction word) processors.
Both Transmeta and Intel have bet that VLIW processors are the way forward. Intel's Itanium and Transmeta's Crusoe are both based around the VLIW concept. Transmeta hides the VLIW nature of Crusoe behind the 'Code Morphing' software that allows the chip to be IA32-compatible - Intel's IA64 architecture gives compilers raw access to the VLIW nature of the processor, and has (very slow) on-chip emulation of IA32.
Between them, they make up the only commercial VLIW processors around, and both are very poor in terms of performance compared to more conventional modern processors, whilst at the same time introducing some enormous obstacles to overcome - IA64 requires some very major changes to the way compilers work, and Crusoe requires major extra complexity in the form of the Code Morphing translation layer.
I don't wish to jump the gun, but I think this means things don't look too bright for the VLIW concept. Evolutionary enhancements to conventional RISC/CISC processors appear able to continue Moore's Law for many years yet. AMD has outright rejected VLIW for its future 64-bit strategy (x86-64) and none of the other major CPU manufacturers seem to be jumping on board either.
Have Transmeta and Intel made a very large strategic mistake? VLIW looks good on paper, but is it effective on a practical level?
It will certainly be interesting to see what happens with future Crusoe and IA64 processors.
Not biased, just practical
on
Mozilla 0.9.5
·
· Score: 2, Interesting
First there IS NO standard Window manager in linux.
Correct. However, KDE is the de-facto standard. Of the major distributors: Mandrake, SuSE, Caldera and (now) Turbolinux use KDE as the default. Only RedHat uses GNOME as default. Debian has no distinction between the two (at least in the forthcoming Woody release) - and previous releases have used WindowMaker as the default.
I dont know any distro which comes with just KDE.
Caldera? Big name in 'business' Linux desktops. All the major distros ship both KDE and GNOME apart from Caldera, which only ships KDE.
Konq will never be an IE because it will never be standard because there is no standard Linux Browser.
If you keep saying it it might not happen. But look at the evidence: All but one of the major Linux distros use KDE by default. Konqueror is the default browser for all those KDE desktops. Isn't that how IE got popular? It was just the first browser that new users came across. Unless a seismic shift occurs in the Linux desktop world, Konqueror is going to be the first browser that most new users discover. Sorry. Perhaps the mozilla team could push the distros a bit harder to get included as the default? (KDE doesn't have to use Konqueror as the browser...)
Konq is not the fastest at rendering, Opera and MOzilla absolutely destroy it in terms of rendering speed, I tested myself.
Are you sure? Subjectively, Konq seems the fastest browser I've used, but I think that is mostly due to its incremental rendering of tables and the visible relayouting it does. Some people hate that. I really like it. It's particularly useful if you read a lot of slashdot over a modem link - no waiting for the whole page to load before it's rendered.:)
Konq is not powerful enough, its years behind Mozilla, and its on the level of say Opera.
In what way?
KHTML renders the vast majority of sites at least as well as Gecko - in some cases better, especially on brain-dead sites that rely on IE quirks to look right. Where's Gecko's anti-aliased font support on X11? Where's the UI to change User Agent? Ok, Konqui doesn't have a password manager. That would be nice to have. Please, be more specific on what is missing from Konqueror.
Because jack of all trades = master of none, A browser should be the best BROWSER
Then tell that Netscape, who decided Mozilla should be an email client, news client, IRC client, instant messenger and HTML editor as WELL as a browser. If that's not being a jack of all trades, then I don't know what is. Using that as an argument for Mozilla over Konqueror is total hypocrisy.
Slashdot Mirror
How much more could we squeeze into that spectrum if they re-did it taking into account those fabulous new mpeg4 codecs that allow DVD quality data streams for only 150-200 KB/s.
Nice idea, but you've got to draw a line in the sand somewhere and standardize on that. MPEG-4 will no doubt be bettered in a few years, do you make everyone upgrade then? What about the next codec after that? And after that? If you make people upgrade, sure it's good for sales, and you'll get more channels into the same bandwidth, but pretty soon most people will object to being gouged and won't bother buying new TVs at all, leaving a confused mess of legacy standards that become a nightmare to support, and the manufacturers bankrupt.
People are used to upgrading their computers fairly regularly and there are often compelling reasons to upgrade, which is why this tactic works there - although notice how many ordinary people still have ancient computers sitting on their desks. TVs last a lot longer - maybe 10 years for a decent one, longer if you're lucky. The tactic would fall flat on its face here - look at the difficulty getting everyone to switch over to the existing digital standards, and they have a lot more going for them than just extra channels over the existing standard.
Perhaps it would be possible to download the codec to the receiver, to take advantage of new developments - but typically, newer codecs require more processing power, and you can't download a new CPU. In any case, MPEG4 isn't actually that much of an improvement over MPEG2, if at all, for proper broadcast-quality video, as it's optimized for minimum bandwidth rather than maximum quality. Even the best quality DivXes look kinda poor compared to DVD.
I'm fairly confident digital TV will still be using MPEG2 in 15 years time - that's still less than half the time that colour NTSC has been around.
So if I don't buy into the "everything is disposable" routine and am still using a ten-year old tv in 2006, suddenly I will be treated only to static and a few pirate tv channels being broadcast from teenagers' backyards(until the FCC shuts them down of course).
No. You will buy a $99 (maybe even less) box that sits on top of your TV and decodes the digital signal so that your old TV can display it. Every other form of digital TV does this currently, and in fact I have yet to see TVs with integrated digital cable or satellite decoders. In the UK the government is considering giving them away to the stragglers if digital terrestrial TV hasn't taken off enough by the time the analogue signals are shut off. Perhaps the FCC might do the same if they're desperate for the frequencies. You get more channels and better picture and sound.
In any case, 2006 is only the date when all new TVs must have built-in decoders - it says nothing about the actual shutoff date for analogue transmissions. In the UK that's set for 2010, although that could change by a year or two in either direction depending on adoption rates and how the government plays it, and the UK is a little bit ahead of the US in the adoption curve.
Really, there is an easy way out.
and the basis for KDE (and, indeed, current versions of Opera). Qt is Norwegian.
TrollTech especially is becoming a very important player in the software industry. They are at the vanguard of fighting Microsoft in both the desktop space with Qt/KDE and in the embedded space with Qt/embedded and Qtopia (as used in the Sharp Zaurus). They are already a great advertisement for and asset to Norway, and if they can keep it up could easily become one of the most important software companies in the world.
In this light I'm not suprised at all that the Norwegian government is opening up to alternatives. By supporting the local software industry, Norway can a) reduce its imports of foreign proprietary software, b) help increase its exports of software, and c) reduce the reliance on all forms of proprietary software (both TrollTech and Opera are extremely Linux and free software friendly). This adds up to a boost for the Norwegian economy, secures local jobs and increases tax revenues flowing to the government. All in all a big win for Norway.
Let's hope the Norwegians really do take it a stage further and start choosing some of their own software. It's a big leap to make but ultimately the Norwegian people will benefit.
Do you ever see Windows applications that are called 'W-whatever'?
No, but there's plenty of Windows software that has a name containing 'Win'.
For example:
WinZip
Winamp
WinAce
WinRAR
WinDVD
CDRWin
WinDoctor
WinDAC
WinPopUp
WinRoute
WinMX
CygWin
These are just a few off the top of my head, there's plenty more. The Mac has (or had, at least) its fair share too, e.g. MacPaint, MacDraw, MacWrite, MacAMP/Macast.
You see, it's just a way of associating the program with the environment where it runs. The fact that KDE app developers love to associate their apps with KDE via the name suggests to me that they generally think very highly of KDE. Call it 'platform patriotism', if you will. End-users like it because it sounds like the app is specifically designed for the environment and follows the same style guidelines and conventions. Never underestimate the power of a name.
Why do you think WinZip became the dominant zip archiver on Windows? I'm pretty sure it wasn't the first, it doesn't come from the people who invented the zip format, it isn't free like some Windows zip archivers (nasty nagware) and I don't think it has the best user interface either (although that's arguable).
In short, it's just good marketing for an app, and that matters as much to free software authors as it does to commercial developers.
I would hope that in the future developers would start putting a small description of their program within the About menu item.
Ummm, have you actually used KDE or are you simply pontificating pointlessly?
Open Konqueror. Go to Help->About Konqueror. In the about box that pops up, on the default 'About' tab, it says: 'Web browser, file manager, ...' which sums up pretty well what Konq does.
Similarly, in the same place in KMail: 'The KDE Email client'.
Or in Kate: 'Kate - KDE Advanced Text Editor'.
Or in KSirc: 'KDE Irc Client'.
Or in Konsole: 'X terminal for use with KDE.'
Pretty much every KDE program has exactly this. You get the about dialog for free when you use the KDE framework, and all the developer has to do is fill in a few blanks.
Not to mention, of course, that the app gets a description in the K Menu as well - for instance, KMail's entry looks like:
KMail (Mail Client)
Perhaps GNOME doesn't do these things, I can't tell you (I haven't had GNOME 1.4 installed for about a year and GNOME 2.0 was installed for a total of about an hour whilst I checked it out and decided I didn't like it) but as far as KDE is concerned, you're dead wrong.
GNOME 2.0 has been rushed out of the door, just like GNOME 1.0 was.
The 1.4->2.0 development cycle has been a lot longer than originally anticipated, due to a big influx of developers (Thanks Sun!) and lots of core systems changing quite radically, coupled with some pretty piss-poor project management (now where have I heard THAT before?). In the mean time, KDE has been gaining a very large amount of traction as the most popular Linux desktop, and Sun has been wanting to push Solaris 9 out the door ASAP.
So GNOME had to release now, really, if they had any hope of keeping the users they have and for Sun to get Solaris 9 out approximately on schedule.
KDE underwent a similar change about 2 years ago, in the 1.1.2->2.0 transition, and not everyone was convinced then that KDE would survive, but it did, and look where they are now. Of course, KDE had the advantage of doing it first - although KDE 2.0 was far from perfect UI-wise, it had a considerable lead on GNOME in changing to a component-based architecture, so there was a very big Unique Selling Point for it at the time which GNOME 2.0 does not now have.
It took KDE 2 further major releases to turn the framework they built into a really nice desktop, and I suspect it will be similar for GNOME. The big question is whether the framework that was built for GNOME 2.0 will be good enough for their future plans... time will tell.
Personally I'm sticking with KDE3 for now. There are certainly issues with KDE, mostly in terms of speed and size, which themselves mostly stem from the choice of C++ rather than C, but these are being fixed one by one. KDE3 is now quite snappy, actually quite a bit faster than GNOME 2.0 on my Debian machine once you've got past logging in (all those double-buffered GTK+ 2.0 widgets are smooth and dandy, but they sure as hell ain't fast). Also, right now, KDE absolutely has the edge on both functionality and usability. Konqueror in particular is way out in front - indeed, for me at least, it's the best file manager on ANY platform. Nautilus is good, don't get me wrong, but Konq is breathtaking.
I'll reassess the situation when GNOME 2.2 is out. 2.2 should be the first mature release of the new framework, then we'll really get to see whether it's good enough to compete. I'm hopeful, a lot of the new framework looks good but either needs loose ends tidying up or needs someone to use it properly. Let's keep our fingers crossed. KDE is a class act to go up against though - they crank out the releases on time every 6 months, they seem to have a consistent vision of where they're going, they know where their flaws are, and they have yet to make a serious error. GNOME can't afford any more releases like this one if it wants to stay in the game.
Oh well... byebye karma
although not in the main XFree86 4.2.0 release.
Download the driver here.
Note that, according to the author of the Savage driver, he has no ProSavage DDR hardware to test on, so don't bet on it, but hopefully it should work (as with most drivers, it's just a matter of adding a hardware ID to make it work, assuming the hardware vendor hasn't messed around too much since the previous version, which is unlikely in this case)...
Hope this helps some people...
...through conventional means, then the rest of the world must play dirty.
Increasing automation of weaponry, and now, total remote control has led and will lead to fewer and fewer deaths of American servicemen and women. This, in turn, removes the single biggest reason for the American political establishment to hold back from launching into war; if there are no body bags flying home, who is going to bother voting these politicians out of office? If a victory can be gained quickly and the opposing side forced to follow the American Way, generating a tidy profit in the process for those American companies that will help them see the light, it is entirely good political karma. Where once a diplomatic solution would have been applied, politicans will be all too keen to apply military solutions instead. No risk, all gain.
America cannot expect those in the world who do not share her views to sit idly by whilst this happens. When people are fighting for what they believe to be their country or their way of life, they will continue to fight back no matter what the military imbalance may be against them. This can be seen, for instance, in the current Israel/Palestine conflict, where despite being massively outgunned and confined to very limited areas, the Palestinians continue to get back up off the floor and keep fighting.
Notice how the Palestinians fight back. They do not have a conventional army, so they must choose other means. Currently, their method of choice seems to be the suicide bomb, and they are called terrorists by the Israelis. The Palestinians, of course, who believe that they are fighting to regain their homeland, call them martyrs.
This is what lies in store for America should she choose to go down this path. Without fear of being voted out of office thanks to the technology, American politicians will throw the country into many wars, and no doubt she will win them in spectacular fashion. However, the opposition will fight back, not through conventional means but through 'terrorism'. It is easy to infiltrate a country as proud of its freedoms as America. What lies in store then? Suicide bombs? Information warfare? Or worse?
We have already seen this scenario once, with September 11th. I am firmly of the belief that the key driving force behind Bin Laden is that he feels his homeland, Saudi Arabia, is being 'occupied' by American forces stationed there since the Gulf War. Of course there is much more to it than that, but it is all too convenient that his anti-American rage became prominent only in the years following the Gulf War.
When this starts to happen, how do you stop it? The obvious way is to restrict those very freedoms that allow the enemy to infiltrate and perpetrate this 'terrorism'. Then what happened to the 'American Way', the very thing that the war was meant to be protecting in the first place?
It's time we started thinking about some of the consequences of the great superiority in American military technology, before those consequences come back to haunt us.
OpenGL 2.0 addresses exactly your concerns - a vendor-neutral shader programming language, and this is precisely why you're seeing 3Dlabs pushing hard for it. It seems they will be first to market with a fully programmable graphics pipeline, and they need the software technology to go with it...
DirectX 9 also addresses the same issues and provides a standard shader language (actually DirectX 8.1 has a standard shader language already, but it lacks a certain amount of the programmability that will be present in DirectX 9), but there are a lot of reasons for the graphics card vendors to favour OpenGL over DirectX. For instance:
Hopefully OpenGL 2.0 will see a resurgence in OpenGL use. I don't like the idea of the 3D market being controlled by Microsoft, and I don't think the 3D vendors do either. Kudos to 3DLabs for leading the way!
The specs were great, but the actual implementation and drivers, well, sucked hard.
Sure, the Permedia wasn't the quickest card on the block in its time, and neither was the Permedia 2 nor the Permedia 3...
But both the NT and Win9x drivers were absolutely 100% rock-solid, the OpenGL implementation was flawless and very, very fast, and the card supported a whole bunch of features that no other consumer-level chipset at the time supported, like anisotropic filtering, or multiple video overlay windows at once. The RAMDACs were really good on the Permedia 2 also - razor-sharp, much much better than the TNT2 I ended up replacing it with. It was also rather faster at GUI acceleration than the TNT2, which was a surprise and a disappointment.
Really it was a semi-pro card at consumer-level prices. It would never have been the card you bought if you wanted the ultimate Quake framerate, but it absolutely oozed quality.
It's the only graphics card I've ever used that hasn't annoyed me in some way, be it dodgy image quality (NVIDIA, S3), unstable drivers (ATI, NVIDIA), bus latency greediness (NVIDIA, S3, Matrox, often leads to choppy, stuttering audio), or just being dog-slow (all the usual suspects - hello Trident, earth calling). I've never used a 3dfx card for more than a few minutes so I can't really comment on them, but I suspect their poor OpenGL support would have annoyed me greatly.
If only 3Dlabs had 3d-accelerated Linux drivers (preferably open source) I'd buy another one in a heartbeat. I've been disappointed with every other card I've had since my Permedia 2...
Does anyone know a decent Windows email client (i.e. not Pegasus or Outlook) which does handle PGP messages?
Might I suggest The Bat!?
Funny name, yes, but it's rapidly become my second-favourite MUA (after KMail) and certainly my favourite on Windows. It has support for both PGP and S/MIME encryption and signing (although it uses its own built-in PGP implementation which I'm not entirely happy about). It's not free in any sense of the word either (it's 30-day trial shareware), but hey, this is Windows we're talking about.
The X extentions are so damn complicated that no ones using them, KDE isnt using Xrender, Gnome isnt using Xrender, hell even Enlightenment isnt using Xrender, the only people who seem to be able to make Xrender work, are the programmers working on it.
This only goes to advertise to the world exactly how little you know about X and how little attention should be paid to your misinformed rants about it.
NO where else have I seen alpha channeling in linux than from keith packard the creator of the Xrender extention.
Open your eyes then. It's everywhere, certainly all over my desktop anyway. If you want to live in the past, feel free. If you want to ignore it, feel free. Spreading misinformed, baseless FUD about one of the most significant modernizations to have happened to X in its entire lifespan isn't appreciated however.
What good is an overly complicated undocumented hard to use API on top of a bloated badly designed implementation of X?
The Render extension is a sensible, well-thought out solution to many of X's previous shortcomings. It's not perfect, but then - it's not finished yet. As for documentation, what do you need exactly? The wire protocol for Render is pretty comprehensively documented, and if you're merely trying to use it in an Xlib program, well, there's always the source code to look at. Yes, that's not perfect, but Render is the work of just Keith, and XFree86 is short-staffed enough as it is. Again - it's not finished yet! In any case, it seems that's enough for Trolltech and the GTK+ developers...
I'm also going to argue here that XFree86 isn't bloated and neither is it badly designed. What it is is massively short of good developers, especially those that are interested in working on the internals of the X server as opposed to just getting the latest and greatest features of their new graphics card working. It's an engineering project as big as the Linux kernel or KDE or GNOME, but with only about 5 people working on the core parts. Is it any wonder it develops more slowly?
Of course, if you were that concerned about X, I'd suggest you go and start hacking code for it, because that's the only way it's going to get better. Except, you're not a graphics programmer are you? Because if you were, you wouldn't have made such baseless allegations about X, and certainly wouldn't have made such basic factual errors as you did in your post.
Wine is considerably more, err, byzantine.
Hardly surprising given what the OS/2 Win16 compatibility layer was: Windows 3.1 run in a virtual 286 (thus in standard, not enhanced mode, which is why some apps wouldn't run), without the Program Manager. IIRC there were two versions of OS/2 you could buy at one point, one with a cut-down copy of Win3.1 included (that Microsoft let them include it was a legacy from agreements signed during the Microsoft/IBM co-operation days, although Microsoft was still getting a licence fee from it) and a cheaper version which asked you for your Win3.1 disks during installation.
A much more fair comparison would be with Win4Lin, which attempts to do much the same thing with Windows 98, i.e. run it in a virtual machine without Explorer, and display the application windows on an X desktop.
Win4Lin is actually a more impressive achievement, as in order to run Win98 it has to virtualize a 386 in protected mode, which is hard, as opposed to virtualizing a 286, which is really really easy (the 386 and above has hardware especially designed to do this).
Either way, whether you run Win16 apps in OS/2 or anything Win98 can run in Win4Lin, you have paid the Microsoft tax and are running Microsoft code.
The other approach to running Windows software on other systems is to reimplement the Windows API. Some projects that do this are basically ports of Microsoft code (like Mainsoft's MainWin, which is used in the HP-UX and Solaris versions of IE). Just two projects have ever done this without using any Microsoft code: Wabi and Wine.
Wabi was very successful in its time, providing a complete Win16 layer on lots of UNIXes, and something that even Wine doesn't do: an i386 emulator for people who want to run Windows apps on non-IA32 architectures. Unfortunately it never got much Win32 support and, being a proprietary product, died a death a few years ago.
So we're left with Wine, the most ambitious Windows emulation project of them all: efficiently reimplementing all of the Win16 and Win32 APIs and ABIs, without any Microsoft code, and all as free software.
it seems like the developers are more interested in using the code for proprietary emulation for running specific programs (games, plugins) or porting (corel stuff, etc.) than producing a general, Free, universal windows emulator.
They are effectively rewriting about 30% of Windows, with only Microsoft's published documentation and reverse engineering as references. They have to be bug-for-bug compatible (this is the real killer). The core team is absolutely tiny compared to Microsoft's Windows development group.
Is it any surprise that they are trying to do what they can as they get things working? They are doing stuff that people would have thought near-impossible just a couple of years ago, even by an extremely well-funded corporate behemoth like Sun or IBM.
It would seem that Wine is the most underappreciated of all the major free software projects out there, which is such a shame given its promise.
Give Wine some time. I know it's been a long wait already, but the pieces are falling into place right now, and it shouldn't be too long (measured in Wine time, of course ;) before Wine gets to version 1.0. When that happens, expect repercussions for years to come.
Amazingly enough, the receptionist knew right off the bat. Helvetica.
I don't know if Michigan road signs are different (never been), but in the rest of the US it's not Helvetica that's used. The Federal Highway Administration has its own set of typefaces that aren't really all that similar to Helvetica.
Knock-offs of the most common US highway typeface are available here. For me it's a lot more readable and a lot more attractive than Helvetica.
Yes, I'm another font obsessive. When I'm not looking after their network, I'm a designer for a sign company, so I guess it's my job to know these things.
As for Knuth (trying to get back on topic here), he's done an awful lot for both computer science as a whole and for digital typesetting, but what on earth was he on when he designed Computer Modern Roman? Ok, it's instantly recognizable, but it's also butt ugly and not very readable even on paper (too spidery, it would be a lot better if the horizontal stem widths were wider). On a low-res computer screen, it's a typeface disaster.
Why not *pick* to copy Apple's HCI and adopt it for the Linux desktop?
Did it ever occur to you that the Mac UI is not the be-all and end-all of user interface design? No, because the Mac UI is 'holy' and many proponents of it adopt a 'holier-than-thou' attitude, yourself included. I can't deny that MacOS 9.x is pretty good from an HCI point of view, but is it as good as some Mac disciples make it out to be? Hardly.
There are actually quite a number of areas where MacOS 9.x is deficient compared to other systems, from a usability point of view. Let's list a few of the major ones, shall we?
What isn't mentioned is the side effect this causes - when every directory is opened in a new window, the screen rapidly fills up with windows, overwhelming the user. It is possible to tell the Finder to close the previous directory window when opening a new one, but only with a non-obvious keyboard modifier when double-clicking. Also, if the previous directory window has been closed, it is now impossible to navigate backwards. Other systems (Windows included) have found solutions to this problem - why hasn't the Mac?
There are more usability problems than this - these are just the first that came off the top of my head. Note also that both Windows and the Linux GUIs have avoided all these problems, and also come up with some good ideas that Apple hasn't even touched on - like the universal viewer application (Explorer, Konqueror, Nautilus), or thumbnailing of all pictures, not just the ones that the creator app decided to attach a thumbnail to.
Perhaps it isn't such a good idea to be blindly copying the Mac after all?
Don't even get me started on OS X, right now it's an ill thought-out usability nightmare. I'm sure it will get better, but right now it's the last place to be looking for usability ideas. It's pretty, yes, but pretty does not equal easy to use.
Of course, the problem is that most people don't have access to a Mac and don't know what it's like to use a Mac and don't understand the Mac gestalt, otherwise they'd be using Macs already...
Suuuuure. When you finally wake up and pull your head out of the sand, be sure to let us know, ok?
In the meantime, the rest of us can get on with using and improving our GUI experience, pulling the best ideas from existing GUIs as well as inventing new ideas. Blindly following anyone is a seriously poor idea.
So can anyone prove that these aren't just screenshots of Windows 2000 with a stardock skin?
I can't prove it to you beyond doubt, but I know KDE when I see it, and this is it. The folder icon on the desktop is a dead giveaway (all the other icons seem to be customised, but this one has been left as the KDE default), as are the handles on the panel applets, which appear to be from Qt's built-in Windows style. Also, the window decorations (close/maximise/minimise buttons) are the KWin 'Redmond' style. Note the gradient on those buttons, Win2k's are flat. Note also the inconsistency between the applet handles on the panel and the toolbar handles in IE and Word - if nothing else this should prove that this isn't a WindowBlinds skin.
I have previously run both IE and Word successfully under WINE, and Notes is also supposed to work - yes, WINE even sets the right icons in the taskbar as the Lindows screenshots show.
So, it's pretty obvious to me that this is indeed Linux, and it's real. All it is is a distro with a slightly customized KDE and WINE setup to launch Windows apps. No great shakes, I can do all this already on my Debian box, and you can do it too on any distro that includes KDE and WINE.
If you still don't believe me, it'd be pretty easy to knock up similar screenshots under any of the major distros. Anyone fancy a go? I won't get a chance until I get home tomorrow...
If you're still not sure after all that, you're going to have to (gasp, shock, horror) actually sit down in front of a Linux box and see it in action yourself.
...or (horror of horrors) compile glibc yourself with Jakub Jelinek's prelinker patches, if you can find them (they seem to have disappeared off the net).
The dynamic linking of libraries is by far the biggest cause of KDE program startup slowness. A big desktop environment has a lot of shared libraries to link to an application at runtime, it's expensive computationally (particularly for C++ libraries), and the way the glibc dynamic linker works right now, it's done every time an application is started or a library is dlopen()'ed (such as when embedding a KPart). It can also cause swap thrashing on machines with limited memory (the entire library must be read into memory to perform the address relocation, only after relocation can the VM drop pages of the library) and obviously, disk contention between this swapping and the application loading can slow things down even further.
What the prelinking patches do (don't get them confused with the objprelink hack which, while useful, is not a long-term or efficient solution) is move the linking time from application startup time to system startup time. A tool runs at system startup, immediately after ldconfig runs, which loads and relocates libraries in its search path, then notes down the relocation addresses. Then, later, when the dynamic linker is asked by an application to load a library, it simply uses the values that were cached earlier. Any libraries that have not been 'prelinked' are simply relocated as normal. The linker also makes sure that non-prelinked libraries are not relocated into the same address space as any prelinked libraries that are not currently loaded.
The next major version of glibc will hopefully include library prelinking by default, but I haven't been following glibc development closely enough to know for sure. Let's keep our fingers crossed. Note that it's not just KDE that will benefit from this, Mozilla will gain a great deal (it, like KDE, is mostly C++ code split into many shared libraries) and even GNOME will benefit a little - doing the dynamic linking on C libraries still costs processor time, although it's much less than with C++ libraries.
The next biggest cause of KDE startup slowness is icon loading - currently every app has to search through the entire set of available icons on startup in order to load the icons that it needs. Not very efficient. Given that KDE has several hundred icons available already and that is likely to increase over time, it needs a solution. Waldo Bastian is apparently working on an icon server for KDE 3.0, which will do that search once, cache the data, and then respond with appropriate icons when an app asks, rather than forcing the apps to do it themselves every time. I'm hoping it also makes it easier and faster to do image compositing (overlays and so forth) with icons.
To sum up: glibc 2.3 together with KDE 3.0 should make a huge improvement to app startup (and KPart embedding) time, and, assuming the KDE guys are tight with their code, may even make KDE 3.0 usable on machines that couldn't effectively run KDE 2.x.
I'd be the first to admit that I much prefer KDE/Qt, both from a user and technical viewpoint, but it is excellent to see GNOME and GTK+ applications making great strides too.
There was a point not so long ago where I feared that GTK+ and GNOME had lost their way completely, and that would have been sad - I think the friendly (and sometimes not-so-friendly ;) rivalry and cross-pollination between the systems has been a bigger win than the split of resources has been a loss. Neither system can afford to sit on their laurels for too long or else the other will take up the slack and make them irrelevant.
It does remain to be seen, however, what will happen with GTK+/GNOME 2.0 - it has been a very long time in coming, and in the meantime KDE 2.x has built up a very large (but not unassailable) head of steam. It's very important that the GNOME guys get 2.0 right (not like the 1.0 release - remember that disaster?) if they want to continue to be more than a bit-part player.
I watch the mailing lists with interest... it's a great soap opera :)
The machine freezes EVERY time because of memory shortages. The kernel can't allocate pages for incoming network traffic, causing a backlog, causing processes to hang, causing further backlog.. then powie an unresponsive machine.
This was a common problem with kernels from about 2.4.1 up to 2.4.9 - the machine would gradually eat into swap further and further, failing to release no-longer-used swapspace, until it would go Out Of Memory (OOM) and attempt to kill the process that was eating all the memory. Frequently it would pick the wrong process to kill (sometimes even killing init) or would end up deadlocking.
I agree with you - that is no way for a virtual memory system to behave.
However, the Linux development process moves quickly once people get annoyed enough to actually do something about it, and that's precisely what has happened. Starting with 2.4.10, a new, simpler VM system has been used in the official Linus kernels, and I can say with some confidence that it has solved all the major problems with the 2.4 VM system, and continues to get significantly faster with every release.
If you haven't actually tried a new kernel yet (and from your problems it seems that you haven't), I suggest that you do - it's made the world of difference for me.
At the same time, the old 2.4 VM has lived on in the -ac series of kernels, and has become a great deal better there - some competition has made a big difference. Almost all of the major areas where it behaved badly have been fixed. However, my own impression is that it is still somewhat slower than the new VM.
The choice is yours which you want to run - my own recommendation would be for the new VM in the official Linus kernels, but others may disagree.
[OOM Killer]
NEWS FLASH they took this feature out because it was buggy.
Umm, no they didn't - it continues to exist in both the new VM in 2.4.13 and the old VM in the most recent 2.4.13-ac kernels. It does, however, now work correctly in both VMs. There are some philosphical arguments over whether killing processes is the best way of handling an Out Of Memory situation, but it is surely better than deadlocking the box, which is what most VM systems (including the famed FreeBSD's) do when OOM occurs.
It's been getting better with each dot release but it's still nothing you'd want to bet money on.
All I can say is that the new VM works great for me and lots of other people, even under extreme load. I can certainly understand your pain if you're using an older 2.4 kernel, but please try a recent one - the difference is astounding.
If you're still having problems with recent kernels, then I'm sure linux-kernel@vger.kernel.org would love to hear from you - and would certainly be a lot more useful to you than ranting on Slashdot. Getting the VM right is now priority number 1 for the kernel hackers.
Isn't that almost exactly what Adobe were suing Macromedia over? Has the US Patent Office granted both of them almost exactly the same patent?
This could get interesting...
Running Qt/Embedded has all sorts of disadvantages, however:
You can't use X11 remote display for development on/for the handheld anymore.
Use VNC instead then. VNC is also much more useful than X once the palmtop is out in the wild - palmtops don't usually have constant network access when they're in your pocket, and VNC can detach and reattach easily to existing sessions, even if you change your IP address in the mean time. X requires a constant network connection or else the app that you're running over X dies.
You can't share the handheld screen between applications written in different toolkits anymore.
And this is a bad thing? Personally I'd be very happy to see embedded Linux not making the same usability mistakes that desktop Linux has in the past, and which it is only now recovering from. Lots of toolkits == inconsistent interface == usability problems. Diversity is great, but there are places where it is inappropriate, and user interface is one of them. Not to mention the bloat aspect of having multiple toolkits...
You are tied to a single toolkit for handheld development.
See above.
Don't forget that Qt/embedded is also API-compatible with Qt/X11, which means that porting Qt apps from the Linux desktop is a cinch - and that's how Opera and Konq/e have been so rapidly successful - they are both based on Qt. Don't underestimate the importance of having a good browser for a palmtop. The only browsers I've seen for X11 that are optimized for display on a small palmtop screen are... Opera and Konq/e. You might as well run them under Qt/embedded.
How many full-blown browsers do you know written in FLTK or Java? Maybe when there's a nice tiny browser for FLTK using Gecko as a rendering engine there'll be something to talk about.
As for size, well, perhaps TinyX+FLTK+Blackbox really is no bigger than Qt/e. But think about what you get with Qt - Signals and Slots, a fast and very powerful canvas widget, full-blown Unicode support, in fact, all the nice features that have made Qt a huge success on the desktop. And, as I've said above, porting the multitude of existing Qt desktop apps is a no-brainer. Not to mention of course that the superb QPE is available, so if you want a complete environment for your users, it's just a compile away. No additional coding required.
FLTK doesn't offer any of this. In fact, no current X11 toolkit other than Qt itself offers all this. If you start adding other toolkits on top of TinyX then you can make up for some of the more important features... but oops, there goes your size, and your consistent interface.
If you have political problems with Qt, then say. You certainly seem to be short on valid technical problems.
I'm sorry but I have a huge problem with running KDE when there's a dependency on proprietary software.
Sigh. How many times does this have to be explained before people get it?
Qt is Open Source software.
The X11 version (which is what KDE depends on) is licensed under either the GPL or the QPL, at your choosing. If you develop proprietary software (i.e. under a license that is incompatible with either the GPL or the QPL), then a paid-for commercial license is required. This is how TrollTech make their money. Either way, you get full source code.
Even Richard Stallman has given his blessing to KDE and Qt's licensing scheme.
Can I make it any clearer for you?
One concern that goes through my mind when I look at the not very stunning performance of Crusoe is the effectiveness of VLIW (very long instruction word) processors.
Both Transmeta and Intel have bet that VLIW processors are the way forward. Intel's Itanium and Transmeta's Crusoe are both based around the VLIW concept. Transmeta hides the VLIW nature of Crusoe behind the 'Code Morphing' software that allows the chip to be IA32-compatible - Intel's IA64 architecture gives compilers raw access to the VLIW nature of the processor, and has (very slow) on-chip emulation of IA32.
Between them, they make up the only commercial VLIW processors around, and both are very poor in terms of performance compared to more conventional modern processors, whilst at the same time introducing some enormous obstacles to overcome - IA64 requires some very major changes to the way compilers work, and Crusoe requires major extra complexity in the form of the Code Morphing translation layer.
I don't wish to jump the gun, but I think this means things don't look too bright for the VLIW concept. Evolutionary enhancements to conventional RISC/CISC processors appear able to continue Moore's Law for many years yet. AMD has outright rejected VLIW for its future 64-bit strategy (x86-64) and none of the other major CPU manufacturers seem to be jumping on board either.
Have Transmeta and Intel made a very large strategic mistake? VLIW looks good on paper, but is it effective on a practical level?
It will certainly be interesting to see what happens with future Crusoe and IA64 processors.
First there IS NO standard Window manager in linux.
Correct. However, KDE is the de-facto standard. Of the major distributors: Mandrake, SuSE, Caldera and (now) Turbolinux use KDE as the default. Only RedHat uses GNOME as default. Debian has no distinction between the two (at least in the forthcoming Woody release) - and previous releases have used WindowMaker as the default.
I dont know any distro which comes with just KDE.
Caldera? Big name in 'business' Linux desktops. All the major distros ship both KDE and GNOME apart from Caldera, which only ships KDE.
Konq will never be an IE because it will never be standard because there is no standard Linux Browser.
If you keep saying it it might not happen. But look at the evidence: All but one of the major Linux distros use KDE by default. Konqueror is the default browser for all those KDE desktops. Isn't that how IE got popular? It was just the first browser that new users came across. Unless a seismic shift occurs in the Linux desktop world, Konqueror is going to be the first browser that most new users discover. Sorry. Perhaps the mozilla team could push the distros a bit harder to get included as the default? (KDE doesn't have to use Konqueror as the browser...)
Konq is not the fastest at rendering, Opera and MOzilla absolutely destroy it in terms of rendering speed, I tested myself.
Are you sure? Subjectively, Konq seems the fastest browser I've used, but I think that is mostly due to its incremental rendering of tables and the visible relayouting it does. Some people hate that. I really like it. It's particularly useful if you read a lot of slashdot over a modem link - no waiting for the whole page to load before it's rendered. :)
Konq is not powerful enough, its years behind Mozilla, and its on the level of say Opera.
In what way?
KHTML renders the vast majority of sites at least as well as Gecko - in some cases better, especially on brain-dead sites that rely on IE quirks to look right. Where's Gecko's anti-aliased font support on X11? Where's the UI to change User Agent? Ok, Konqui doesn't have a password manager. That would be nice to have. Please, be more specific on what is missing from Konqueror.
Because jack of all trades = master of none, A browser should be the best BROWSER
Then tell that Netscape, who decided Mozilla should be an email client, news client, IRC client, instant messenger and HTML editor as WELL as a browser. If that's not being a jack of all trades, then I don't know what is. Using that as an argument for Mozilla over Konqueror is total hypocrisy.