Irritating wheel-reinvention, to an extent - NetBeans/Forte covers a lot of the same ground for pluggable IDEs - NetBeans 3 already supports Java, various scripting languages, XML, CVS, and has branched out into C/C++ support, and has a mature plugin API that works very well, based on dropping JavaBeans components conforming to particular interfaces into the IDE.
And, worst of all, despite Eclipse's much-vaunted "It's not Swing/Awt!" approach, I've found that the Netbeans Swing UI actually seems to be pretty good on my Linux box, while I've been hearing reports of Eclips'es GUI sucking on Linux.
In Eclipse's favour, it'll probably inherit VisualAge's GUI Beanbox from IBM, and that's much better than forte's Beanbox.
So far I haven't seen any evidence of cooperation between Eclipse and NetBeans. Sigh.
1/2p coins haven't been legal tender in Ireland for quite a while now (I think they were phased out in the 80s - I'm 23 and barely remember them), and the old 10p was replaced by a smaller coin about the size of the old 5p, while the old 5p was replaced by a really tiny coin. We also had 20p coins (a bit smaller than the old 10p and a bit bigger than the newer one) and (big, thin) £1 coins introduced.
The new 1-cent coin is even smaller in diameter than the old irish 1/2p (it's a little thicker, though).
I always liked our Irish coins, because they had nice pictures of animals on them, and you could "pluck" the "strings" on the harp on the other side, and each "string" really did make a sound with a different pitch (though the sounds were sort of claack-clack-cliick-click), rather than the ugly thingies and wrinkly people's heads on british and most other countries' coins.
The new Irish-issue euros still have the harp on the "national" side, but the euro-side motifs are really boring looking, with a sort of "modern" look that you just know will date astonishingly quickly, like shiny plastic furniture in the 70s.
Because winmodems are a fundamentally stupid idea, you idiot troll, and G400s aren't. Think about it: With a winmodem you're wasting 10% of your CPU time doing the modulation and demodulation - something a custom chip in a real modem can do. G400s are the OPPPOSITE IDEA - you're offloading 3D and display processing that would take CPU time onto a custom chipset.
Nothing, but: hush... don't tell the French, they'll notice and demand it be changed...
Re:Windowmaker (the UNIX way) vs KDE (Windows way)
on
Window Maker 0.80 Released
·
· Score: 3, Informative
Well, I just run KDE 2 with its Windomaker/Step-style theme, and turn off a lot of the crap.;-)
(That's something that some people fail to grasp about KDE - it just defaults to looking vaguely ms-windows-like)
Regarding the fonts, my fonts look lovely with KDE once I switched to using the antialiased ones - Qt and KDE can use the new XRENDER/Xft font subsystem of XFree86 these days.
Another problem a lot of people have is that they are running their X Server at 75dpi, when in fact many modern displays are closer to 100-120dpi (mine's 120dpi...) - I've yet to see a distro configure this properly (for a quick fix, start X with the command line -dpi option set to something approximating your display, or configure it in your XF86Config file). Since correct font rendering depends on knowing the physical size of your display, most people end up with really tiny looking fonts, since their X server thinks the display has a lower DPI than it really has.
Regarding the load time of KDE - one major problem has been traced to the inefficient way the standard dynamic linker loads C++ shared library files - a new release of the linker will fix that, and produces a huge improvement in C++-on-linux application startup times in general (this is not just a KDE problem). Coupled with the slowly-stabilising-to-de-facto-standard C++ ABI given to use by gcc 3.x, this should make linux C++ development easier and much less painful than it has been historically.
Personally, I'm not all that fond of C++, but lots of people are, and lots of commercial/niche applications on Win32 and commercial proprietary unix are in C++, so making C++ on linux work better is definitely worthwhile.
Older Gameboys weren't backlit. Didn't stop millions of people buying them and playing them.
All in all, I'm quite happy with my GBA, and can see it fine during daylight ("daylight, what's that?" cry 10,000 slashdot geeks) or with any electric lights at approx 60 watt tungsten-filament-bulb equivalent or above - i.e. anywhere I'd normally care to play it - and for those places where I wouldn't normally play it, there's GBA-compatible (with cable-pass-through) white-led worm lights available now (at least here in Ireland), which work fine for me.
Honestly, you didn't expect to play older gameboys in the dark without a light, why should the GBA be different? Historically, backlit color handhelds didn't do well in the marketplace, because their battery life was so short, and seeing as the GBA is targetted at kids, who will mainly be using it in daylight anyway, one would hope.
Now, if you live inside the artic circle, I suppose that the constant darkness in winter could make it a little more difficult...;-)
However, there's no two ways about it, VMWare is intrinsically a kludge, because the x86 architecture as it stands today simply wasn't designed to be fully virtualisable (irritatingly, 32-bit x86s CAN fully virtualise 16-bit x86 code - dunno why intel didn't make the conceptual leap to doing the same for the 32-bit stuff - perhaps IBM had patents on it or something, thanks to their POWER architecture, for all I know.)
And true virtualisation, mainframe-style, needs not just CPU support, but support from lots more of the hardware in the computer system.
So, VMWare is part virtualiser, part emulator.
The open source VMWare clone, plex86, similarly, has a lot in common with the bochs x86 emulator.
It's all very clever, but the PeeCee architecture is simply vile, and definitely an example of the "Eat shit, 10 billion flies can't be wrong" effect - even way, way back, there were better designed hardware architectures than the PC available for similar prices - the dominance of the PC arose partly because it was easy to semi-legally produce IBMPC-compatible clones, and partly through non-technological forces (i.e. lying salesmen and marketers combined with completely computer-clueless businessmen who believed them).
Not in the last version I used. But if you mention it to the developers, I'm sure they'll see the utility of configurable kerning - after all, I was using Amiga GUI word processors/DTP packages a decade ago with such control. It'd all be doable now that Qt and KDE have switched to the new Xft==Freetype+XRender font rendering engine, which exposes such things to the programmer in a sane manner, unlike the old server-side X font system.
It always amazes me how linux people are willing to say "Microsoft Windows is crap, but Office is good" - when in fact, Office is crap in many of the ways windows is, it's just most linux people don't understand DTP....
This behaviour is being fixed as we speak - it involves an extension to the X Server called R'n'R for "resize and rotate". This will allow for the resizing behaviour you want, however, just like when windows made the transition to on-the-fly resizing, applications will need to be patched if they want notification of the resize if they want to do anything complicated, like responding to changes in the screen physical, dots-per-inch, resolution. This will be less annoying than it sounds, because most applications these days use Qt or gtk, which can abstract away such things. (this is important for serious word processing and graphics design, where the program always wants to know the DPI of the screen, so that it can measure on-screen object in real units like inches and millimeters)
(aside: a pet hate of mine is that the installation/autoconfig process of most Linux distros with X leaves the X Server set to 75x75 DPI instead of getting the monitor dimensions from the monitor dpmi and/or confirming them with the user - my display is 120x120 DPI, so this is a definite irritation... Many windows systems aren't any better - they always seem to insist they are 96x96 DPI, even when they're not.).
As an extra gimmick, the R'n'R extension will also allow for on-the-fly 90-degree rotations of the display - not particularly relevant for desktop machines with CRTs, but for X on handhelds and tablets and workstations with those sweet LCD monitors that can be rotated, this means that you can have a choice of "portrait" and "landscape" - without restarting the display.
We already have anti-aliased text in X, and as a side effect, we also got the basics of a new alpha-compositing engine and a new x-client-side font model which makes more sense for most applications than the old server side fonts system.
I think the other planned eye-candy feature-burst for X is allowing prettier mouse cursors that are truecolor, blended, animated and so on. This is more important than it sounds, since a big,colorful, noticeable mouse cursor that's easily locatable is very important for accessibility for young children, older people and disabled people.
All in all - these things ARE being worked on, and at a pace which must be frightening to those in Redmond.
KDE KOffice kword aims to be frames-based wordprocessor, in which you do indeed "drag blocks of text around on screen and have it flow properly".
Unlike Open Office, which is constrained by the desire to be 100% feature (and bug) compatible with MS Office, KDE Koffice is free to try different, better UIs. OpenOffice is probably better for converts to linux from windows, but KDE's offerings are actually shaping up to be nicer for the "never seen a computer before" user - they're not afraid of doing things differently to MS Windows and MS Office, if it improves long-term usability.
Well, to disable the header on the first page in SO 5.2 the "proper" way, it's easy enough, just different to MS Office:
You can either use the "Stylist" window - Press F11 if it's not already up, click on the "Page Styles" icon in the stylist (Probably the fourth from the left) , and double-click "First Page".
Or if you have a particular hate of the stylist window (it's one of the things MS Office users seem to automatically turn off, since it's "different"), you can do it the long way:
On the first page, go to the menu
"Format/Styles/Catalog" - a dialog appears, which has a listbox where you can select "Page Styles", and then "First Page".
This will mark the page you're on as the "first page", and if you turn headers/footers on subsequently, they'll appear on all but that first page.
Using the stylist is actually faster than the equivalent operation in MS Word, IMHO - it's just people have already learnt the MS Word way, and if there's one thing people hate more than a bad user interface, it's a UI that's different to a bad one they've already taken the time to learn.
If you rename the extension on a.html or.rtf file to.doc, MS Word 97 and above transparently loads it - and a.rtf file has more than enough formatting control to make a stylish CV.
Also, Star Office 5.2, let alone 6.0, _exports_ simple documents like CVs and letters to word flawlessly in my experience - it's mainly things involving object embedding it stumbles on. (importing is a different matter - any "fast saved" documents from Office 97 will thoroughly screw up - but, of course, in this case, you want to export, not import.)
Having "more statistics" doesn't really matter much, if the statistics are badly done. "There are three kinds of lies - lies, damn lies, and statistics". Also having "more references" doesn't mean much - if the stuff people are referencing is crap - in fact, I've noticed, particularly among the "sciences" of economics, social studies, and psychology, a tendency for big groups of people to produce referencing love-ins, where they all reference eachother to make their papers look more authoritative.
As a mechanical engineer who has gone out with a couple of psychologists, I can confirm that the sort of crap that psychologists are taught is 95% pseudoscience compared to physics and chemistry. HOWEVER - the situation is improving, thanks largely to brain-scans (i.e. physicists) and biochemists getting involved.
Personally, I don't think psychology will be worth all that much as a *science* until we have real-time monitoring of brain processes at a very fine level of detail compared to today. As a body of knowledge composed of ad-hoc empirical rules, however, it's already working well enough for sheeple-control - i.e. we've already had the initial "industrial revolution" of psychology, and it's about as far along as early physics, with some things that a right and lots of things that are just plain wrong, that have yet to be whittled away by proper application of the scientific method.
It's easy to visualise 1-in-a-million if you think of a 1 metre cubed volume, and imagine a 1 centimetre cubed sugar cube in it. This brings 1-in-a-million into distinctly human-sized terms. 1-in-a-billion* is easily visualised as a 1-millimeter cube of dirt in a 1 metre volume of space. Using Volumes rather than lengths or areas to visualise "large" numbers brings them to comprehensible scales - Think of filling a medium sized cupboard with sugar cubes for an approximation to one million....
* 1000-million == 1000 000 000 == 1 "amercian" billion. Note that most British people now pretty much exclusively use the american definition of a billion (many people will still tell you that the British Billion is a million million, but if a British person says a billion, he now tends to mean an american billion, just to confuse you).
Re:BIOSes should not be operating system-specific.
on
LinuxBIOS Gains Steam
·
· Score: 3, Interesting
Grr... got the 1.02 EFI specification from Intel, it doesn't look like a technologically particularly bad way of doing things or anything, especially given that it's all quite logical and neat, despite the fact they're still trying for a degree of backward-compatibility (which is all parcelled off into its own little section, thankfully) - it's just an easily followed tree of c structures - it's a definite improvement on PC-AT BIOSes, but it's pretty much intel-architecture-specific, of course.
OF's forth-bytecode intended to act as cross-platform on-card boot-time init and bare-bones device drivers and so on is replaced by in-rom snippets of "PE32+" 32/64-bit IA code, etc., etc.
It's well-defined support for reading boot-time image files from FAT filesystems, and net-booting, should make the boot process a lot less painful for Microsoft OSes, and a bit less painful for Linux - actually, I presume the Linux-Itanium project's already got this sorted.
It's certainly well-suited for integration with Microsoft OSes (certain aspects, like the Vendor Device Path look tailor-made for their end-to-end "DRM OS" recently mentioned on/.:-(( ), and it definitely doesn't have the cool forthy hackability of OpenFirmware.;-) It's still a much better match than the legacy BIOS to modern 32/64-bit OSes though.
All that said, I think one could, in theory, have a BIOS that was largely x86 EFI and Open Firmware compliant at the same time, if a designer really put his mind to it - one could probably write an EFI-compliant implementation in a mixture of forth and asm in the first place, and have it call legacy x86 PC ("PCI ROM type 0"), Open Firmware ("PCI ROM type 1") or EFI ("Proposed PCI ROM type 3") boot code segments on the PCI cards as it saw fit! The "Firmware Boot Manager" that EFI eventually drops into could be a full forth console, for all intel care, by my reading of the spec, and producing the EFI/ACPI device tree from the Open Firmware tree or vice-versa would just be a "simple" transform, I suppose.
I very, very much doubt anyone will bother doing this, though, unless Apple paid them a very large bung to encourage the proliferation of OpenFirmware-compliant devices...
So the fix is in already, as usual. Obviously, they've wheel-reinvented, presumably because OF is (was (afaik it's lapsed, like Scheme)) an IEEE standard they didn't control.
Re:BIOSes should not be operating system-specific.
on
LinuxBIOS Gains Steam
·
· Score: 5, Interesting
I quite like OpenFirmware, but have yet to see a x86 PC motherboard which uses it - PPC ones do, of course. The specification standard includes support for x86 computers, but the mobo manufacturers have deals with the BIOS producers (if they're not already the same company), and the BIOS producers have deals with MS, which means they've had financial incentives for years for keeping the BIOS in the dark ages of DOS.
Most current BIOSes are extremely biased toward DOS and DOS-derivatives like windows 95 - they're pretty ill suited to even Windows 2000, I'm sure microsoft now would prefer them to be replaced too (but with something that still ties you to MS, of course - no doubt MS will be prodding at x86 BIOS manufacturers to get this).
At the same time, perhaps what's needed is a open standard for the provision of a wodge of on-mobo flash-ram - the main reason people want to replace the BIOS with linux, so that the OS loads in a blink of an eye, perhaps without even requiring a HD. It's just silly that the BIOS spends a good while screwing around in Real Mode when Linux (or newer versions of Windows!) just go back and do all the setup again...
I thik it's be REALLY nice to have an OpenFirmware-type BIOS on x86, but with a few megs of flash on the motherboard that one could load the OS kernel and perhaps an initrd from, instead of having to mess about with the harddrive.
Question - has there been any progress made on bringing the respective component models of KDE and GNOME any closer together? It'd be nice to be able to embed a Bonobo component in a KParts document, perhaps itself embedded in a StarOffice or even Mozilla framework. How fundamentally different are KParts/DCOP, Bonobo/CORBA, StarOffice/UNO, Mozilla/XPCOM, Java/JavaBeans, Microsoft OLE/COM, (probably Xt belongs in this list too...), will there ever be any hope of unifying them a bit better ???
Apart from anything else - you already can embed video into word doc files. One thing MS worked out way, way back, was a generalised "Object Linking and Embedding" (OLE) Framework, akin to KParts in KDE or Bonobo in GNOME, which are much less mature versions of the same concept.
You can embed essentially any data the system is equipped to handle in a word file, even sound samples and video clips. It's reasonably clever, though other systems did it before MS (as usual). It's a bit like a GUI analog of the way unix command line tools can be used together, and is more powerful than some CLI bigots like to admit. One thing I don't like about the windows model is that it doesn't make it as easy as it could be to work with the GUI components FROM the CLI (unless you regard VBScript + Windows Scripting Host as the true CLI of the box, rather than the anaemic MSDOS shell - perhaps not such a bad assumption). KDE makes it really easy via the "dcop" command line tool, and, in theory, GNOME Bonobo is scriptable via CORBA-aware command line tools. OS/2 and the Amiga via (A)Rexx, and Apple via Applescript, were other examples of systems that got this sort of thing sorted.
Part of the problem with "opening" the format is that, up until Word 2000, it's really a dump of RTF mixed with whatever OLE/COM structures are in memory at the time, and after Word 2000, it's still partly a dump of OLE/COM, mixed with snippets of XML - a lot of Microsoft, and third-party, Windows software works this way, actually. It's a quick, easy and reliable way of implementing load/save functionality - Java, too, has it's serialization API to do the same sort of thing.
This is one of the reasons Star Office has such similar functionality to MS Office - if you want data format compatibility, you need functional compatibility, so you program is constrained to WORK similarly to MS stuff - and, for the user-acceptable minimum compatibility, you need to duplicate excel, MS picture editor, MS formula editor, etc, as well. Although such components all appear to be one monolithic block called "MS Office", at the Windows operating system level, they're a jungle of interactng pieces.
As it is, you still get people surprised when the Autocad drawing they've embedded in a MS.doc file isn't editable on a computer without Autocad installed, and it's even worse for other things non-windows systems, since they may have very different applications. Thus, even though Star Office these days has the basic MS Word and Excel support down pretty well, it will take a bit of time before it's a general replacement. "Opening" the office document format isn't really all that much of a help in terms of additional information - the important thing is to stop MS taking legal action against those who use it, and to constrain MS themselves to stick to the documented document format (:-) ) and not make changes to produce gratituous incompatibilities - many of the changes from word version to word version are not gratituous, but are actually a symptom of microsoft improving (or just bloating) the core of the program.
I may or may not be a freak (NB. I'm european, so that might automatically qualify me as a freak in the american outlook), and I'm probably only a liberal in the non-newspeak/non-political-party usage of the word - a supporter of liberty - i.e. freedom.
Even if I were a psycho fascist, a gender-ambiguous pronoun would be useful to me - what if I'm planning to have someone killed, and don't know what sex they are yet ? Hey, what if I'm a psycho fascist planning to kill someone precisely because they're not definable male or female? A gender-ambiguous pronoun is useful to almost everyone, even if they're decidedly not liberal.
(disregarding most of above post, although he's right about the lost art of trolling.)
"tey" sounds quite cool, actually. However, just as we have come to need a gender-ambiguous pronoun, how about a singular/plural ambiguous one? "they" again ? once again, that solution devalues the original use of "they". Suggestions?
Yes, Java is the new COBOL. No, seriously - it's being used everywhere COBOL used to be in businesses. MS wants a piece of that market, and, no doubt, will get some, with C#.
What are your views on societal transparency, as put forward by David Brin in his book - "The Transparent Society - Will Technology force us to choose between Privacy and Freedom".? (chapter one available online)
In this book, Brin argues that, given the existence and proliferation of surveillance technology, one of the few ways to avoid a "Big Brother" scenario is to make the surveillance networks real-time public-access, and "democratic"/all-encompassing, so that "The watched may watch the watchers". Brin then expands upon the possibly viable, perhaps even pleasant, social structure that might then evolve, rather than the usual dystopian vision of a police state.
(Of course, Popper covered the same ground, but Brin's more accessible, and deals particularly with the technological enabling factors of open societies)
Brin's observation that "In any situation involving a conflict between privacy and accountability, people demand privacy for themselves and accountability for everyone else", is particularly applicable, in my view, to the online-privacy debates. One core insight is that it is the asymmetric flow of information that often gives one group power over another.
Well, not an acronym, but "Solar Chimney" already sounds pretty cool - they've actually been around since the 80s, though the oil companies used to do a good job of silencing people who talk about them in the mainstream press - I remember reading about plans for a pilot plant in Spain in 1984.
Well, there you go, then. Apple may not have invented it, but they managed to _tell_ people that you could use your computer for digital video.
e.g. You and I know that you can store and manipulate photographs on computer - but lots of people don't think to do that until they see a "My Pictures" folder thoughtfully provided for them. In a similar fashion, the Amiga was fully capable of Quicktime-like feats of multimedia in 1991 (I know, I had several), but it wasn't SOLD as such all that much (thanks largely to managerial and marketing incompetence in CBM, most of America and a fair bit of Europe seemed to think of the Amiga as solely a games machine).
That's a mistake that developers make a lot - they, being smart, can see that one can quite happily use a text editor to make out a shopping list, or even keep a load of lists in a general purpose database, but joe-average-IQ on the street may not even think to do so with the status-symbol computer he just paid a small fortune for, unless there's a "My Shopping List" button for him to click, even if it only opens up a window with a "My Shopping List" titlebar containing a limited text editor component tied to a shoddy little database. There are people in the Windows world who can, and have, paid quite a bit for such products, which one could knock together in 5 minutes in tcl/tk in the linux world.
Microsoft and Apple understand this very well - general purpose tools are often unsuitable for people because people often aren't imaginative enough to use them. As a Very Clever Person, I'm always vaguely disillusioned by the "inside the box" thinking of most people I meet,
but one must recognise that People Are Stupid.
Slashdot Mirror
Irritating wheel-reinvention, to an extent - NetBeans/Forte covers a lot of the same ground for pluggable IDEs - NetBeans 3 already supports Java, various scripting languages, XML, CVS, and has branched out into C/C++ support, and has a mature plugin API that works very well, based on dropping JavaBeans components conforming to particular interfaces into the IDE.
And, worst of all, despite Eclipse's much-vaunted "It's not Swing/Awt!" approach, I've found that the Netbeans Swing UI actually seems to be pretty good on my Linux box, while I've been hearing reports of Eclips'es GUI sucking on Linux.
In Eclipse's favour, it'll probably inherit VisualAge's GUI Beanbox from IBM, and that's much better than forte's Beanbox.
So far I haven't seen any evidence of cooperation between Eclipse and NetBeans. Sigh.
1/2p coins haven't been legal tender in Ireland for quite a while now (I think they were phased out in the 80s - I'm 23 and barely remember them), and the old 10p was replaced by a smaller coin about the size of the old 5p, while the old 5p was replaced by a really tiny coin. We also had 20p coins (a bit smaller than the old 10p and a bit bigger than the newer one) and (big, thin) £1 coins introduced.
The new 1-cent coin is even smaller in diameter than the old irish 1/2p (it's a little thicker, though).
I always liked our Irish coins, because they had nice pictures of animals on them, and you could "pluck" the "strings" on the harp on the other side, and each "string" really did make a sound with a different pitch (though the sounds were sort of claack-clack-cliick-click), rather than the ugly thingies and wrinkly people's heads on british and most other countries' coins.
The new Irish-issue euros still have the harp on the "national" side, but the euro-side motifs are really boring looking, with a sort of "modern" look that you just know will date astonishingly quickly, like shiny plastic furniture in the 70s.
Sigh... Feeding trolls one more time....
Because winmodems are a fundamentally stupid idea, you idiot troll, and G400s aren't. Think about it: With a winmodem you're wasting 10% of your CPU time doing the modulation and demodulation - something a custom chip in a real modem can do. G400s are the OPPPOSITE IDEA - you're offloading 3D and display processing that would take CPU time onto a custom chipset.
In summary: G400 good, WinModem bad.
Nothing, but: hush... don't tell the French, they'll notice and demand it be changed...
Well, I just run KDE 2 with its Windomaker/Step-style theme, and turn off a lot of the crap. ;-)
(That's something that some people fail to grasp about KDE - it just defaults to looking vaguely ms-windows-like)
Regarding the fonts, my fonts look lovely with KDE once I switched to using the antialiased ones - Qt and KDE can use the new XRENDER/Xft font subsystem of XFree86 these days.
Another problem a lot of people have is that they are running their X Server at 75dpi, when in fact many modern displays are closer to 100-120dpi (mine's 120dpi...) - I've yet to see a distro configure this properly (for a quick fix, start X with the command line -dpi option set to something approximating your display, or configure it in your XF86Config file). Since correct font rendering depends on knowing the physical size of your display, most people end up with really tiny looking fonts, since their X server thinks the display has a lower DPI than it really has.
Regarding the load time of KDE - one major problem has been traced to the inefficient way the standard dynamic linker loads C++ shared library files - a new release of the linker will fix that, and produces a huge improvement in C++-on-linux application startup times in general (this is not just a KDE problem). Coupled with the slowly-stabilising-to-de-facto-standard C++ ABI given to use by gcc 3.x, this should make linux C++ development easier and much less painful than it has been historically.
Personally, I'm not all that fond of C++, but lots of people are, and lots of commercial/niche applications on Win32 and commercial proprietary unix are in C++, so making C++ on linux work better is definitely worthwhile.
Older Gameboys weren't backlit. Didn't stop millions of people buying them and playing them.
;-)
All in all, I'm quite happy with my GBA, and can see it fine during daylight ("daylight, what's that?" cry 10,000 slashdot geeks) or with any electric lights at approx 60 watt tungsten-filament-bulb equivalent or above - i.e. anywhere I'd normally care to play it - and for those places where I wouldn't normally play it, there's GBA-compatible (with cable-pass-through) white-led worm lights available now (at least here in Ireland), which work fine for me.
Honestly, you didn't expect to play older gameboys in the dark without a light, why should the GBA be different? Historically, backlit color handhelds didn't do well in the marketplace, because their battery life was so short, and seeing as the GBA is targetted at kids, who will mainly be using it in daylight anyway, one would hope.
Now, if you live inside the artic circle, I suppose that the constant darkness in winter could make it a little more difficult...
However, there's no two ways about it, VMWare is intrinsically a kludge, because the x86 architecture as it stands today simply wasn't designed to be fully virtualisable (irritatingly, 32-bit x86s CAN fully virtualise 16-bit x86 code - dunno why intel didn't make the conceptual leap to doing the same for the 32-bit stuff - perhaps IBM had patents on it or something, thanks to their POWER architecture, for all I know.)
And true virtualisation, mainframe-style, needs not just CPU support, but support from lots more of the hardware in the computer system.
So, VMWare is part virtualiser, part emulator.
The open source VMWare clone, plex86, similarly, has a lot in common with the bochs x86 emulator.
It's all very clever, but the PeeCee architecture is simply vile, and definitely an example of the "Eat shit, 10 billion flies can't be wrong" effect - even way, way back, there were better designed hardware architectures than the PC available for similar prices - the dominance of the PC arose partly because it was easy to semi-legally produce IBMPC-compatible clones, and partly through non-technological forces (i.e. lying salesmen and marketers combined with completely computer-clueless businessmen who believed them).
Not in the last version I used. But if you mention it to the developers, I'm sure they'll see the utility of configurable kerning - after all, I was using Amiga GUI word processors/DTP packages a decade ago with such control. It'd all be doable now that Qt and KDE have switched to the new Xft==Freetype+XRender font rendering engine, which exposes such things to the programmer in a sane manner, unlike the old server-side X font system.
It always amazes me how linux people are willing to say "Microsoft Windows is crap, but Office is good" - when in fact, Office is crap in many of the ways windows is, it's just most linux people don't understand DTP....
This behaviour is being fixed as we speak - it involves an extension to the X Server called R'n'R for "resize and rotate". This will allow for the resizing behaviour you want, however, just like when windows made the transition to on-the-fly resizing, applications will need to be patched if they want notification of the resize if they want to do anything complicated, like responding to changes in the screen physical, dots-per-inch, resolution. This will be less annoying than it sounds, because most applications these days use Qt or gtk, which can abstract away such things. (this is important for serious word processing and graphics design, where the program always wants to know the DPI of the screen, so that it can measure on-screen object in real units like inches and millimeters)
(aside: a pet hate of mine is that the installation/autoconfig process of most Linux distros with X leaves the X Server set to 75x75 DPI instead of getting the monitor dimensions from the monitor dpmi and/or confirming them with the user - my display is 120x120 DPI, so this is a definite irritation... Many windows systems aren't any better - they always seem to insist they are 96x96 DPI, even when they're not.).
As an extra gimmick, the R'n'R extension will also allow for on-the-fly 90-degree rotations of the display - not particularly relevant for desktop machines with CRTs, but for X on handhelds and tablets and workstations with those sweet LCD monitors that can be rotated, this means that you can have a choice of "portrait" and "landscape" - without restarting the display.
We already have anti-aliased text in X, and as a side effect, we also got the basics of a new alpha-compositing engine and a new x-client-side font model which makes more sense for most applications than the old server side fonts system.
I think the other planned eye-candy feature-burst for X is allowing prettier mouse cursors that are truecolor, blended, animated and so on. This is more important than it sounds, since a big,colorful, noticeable mouse cursor that's easily locatable is very important for accessibility for young children, older people and disabled people.
All in all - these things ARE being worked on, and at a pace which must be frightening to those in Redmond.
KDE KOffice kword aims to be frames-based wordprocessor, in which you do indeed "drag blocks of text around on screen and have it flow properly".
Unlike Open Office, which is constrained by the desire to be 100% feature (and bug) compatible with MS Office, KDE Koffice is free to try different, better UIs. OpenOffice is probably better for converts to linux from windows, but KDE's offerings are actually shaping up to be nicer for the "never seen a computer before" user - they're not afraid of doing things differently to MS Windows and MS Office, if it improves long-term usability.
Well, to disable the header on the first page in SO 5.2 the "proper" way, it's easy enough, just different to MS Office:
You can either use the "Stylist" window - Press F11 if it's not already up, click on the "Page Styles" icon in the stylist (Probably the fourth from the left) , and double-click "First Page".
Or if you have a particular hate of the stylist window (it's one of the things MS Office users seem to automatically turn off, since it's "different"), you can do it the long way:
On the first page, go to the menu
"Format/Styles/Catalog" - a dialog appears, which has a listbox where you can select "Page Styles", and then "First Page".
This will mark the page you're on as the "first page", and if you turn headers/footers on subsequently, they'll appear on all but that first page.
Using the stylist is actually faster than the equivalent operation in MS Word, IMHO - it's just people have already learnt the MS Word way, and if there's one thing people hate more than a bad user interface, it's a UI that's different to a bad one they've already taken the time to learn.
If you rename the extension on a .html or .rtf file to .doc, MS Word 97 and above transparently loads it - and a .rtf file has more than enough formatting control to make a stylish CV.
Also, Star Office 5.2, let alone 6.0, _exports_ simple documents like CVs and letters to word flawlessly in my experience - it's mainly things involving object embedding it stumbles on. (importing is a different matter - any "fast saved" documents from Office 97 will thoroughly screw up - but, of course, in this case, you want to export, not import.)
Having "more statistics" doesn't really matter much, if the statistics are badly done. "There are three kinds of lies - lies, damn lies, and statistics". Also having "more references" doesn't mean much - if the stuff people are referencing is crap - in fact, I've noticed, particularly among the "sciences" of economics, social studies, and psychology, a tendency for big groups of people to produce referencing love-ins, where they all reference eachother to make their papers look more authoritative.
As a mechanical engineer who has gone out with a couple of psychologists, I can confirm that the sort of crap that psychologists are taught is 95% pseudoscience compared to physics and chemistry. HOWEVER - the situation is improving, thanks largely to brain-scans (i.e. physicists) and biochemists getting involved.
Personally, I don't think psychology will be worth all that much as a *science* until we have real-time monitoring of brain processes at a very fine level of detail compared to today. As a body of knowledge composed of ad-hoc empirical rules, however, it's already working well enough for sheeple-control - i.e. we've already had the initial "industrial revolution" of psychology, and it's about as far along as early physics, with some things that a right and lots of things that are just plain wrong, that have yet to be whittled away by proper application of the scientific method.
It's easy to visualise 1-in-a-million if you think of a 1 metre cubed volume, and imagine a 1 centimetre cubed sugar cube in it. This brings 1-in-a-million into distinctly human-sized terms. 1-in-a-billion* is easily visualised as a 1-millimeter cube of dirt in a 1 metre volume of space. Using Volumes rather than lengths or areas to visualise "large" numbers brings them to comprehensible scales - Think of filling a medium sized cupboard with sugar cubes for an approximation to one million....
* 1000-million == 1000 000 000 == 1 "amercian" billion. Note that most British people now pretty much exclusively use the american definition of a billion (many people will still tell you that the British Billion is a million million, but if a British person says a billion, he now tends to mean an american billion, just to confuse you).
Grr... got the 1.02 EFI specification from Intel, it doesn't look like a technologically particularly bad way of doing things or anything, especially given that it's all quite logical and neat, despite the fact they're still trying for a degree of backward-compatibility (which is all parcelled off into its own little section, thankfully) - it's just an easily followed tree of c structures - it's a definite improvement on PC-AT BIOSes, but it's pretty much intel-architecture-specific, of course.
/. :-(( ), and it definitely doesn't have the cool forthy hackability of OpenFirmware. ;-) It's still a much better match than the legacy BIOS to modern 32/64-bit OSes though.
OF's forth-bytecode intended to act as cross-platform on-card boot-time init and bare-bones device drivers and so on is replaced by in-rom snippets of "PE32+" 32/64-bit IA code, etc., etc.
It's well-defined support for reading boot-time image files from FAT filesystems, and net-booting, should make the boot process a lot less painful for Microsoft OSes, and a bit less painful for Linux - actually, I presume the Linux-Itanium project's already got this sorted.
It's certainly well-suited for integration with Microsoft OSes (certain aspects, like the Vendor Device Path look tailor-made for their end-to-end "DRM OS" recently mentioned on
All that said, I think one could, in theory, have a BIOS that was largely x86 EFI and Open Firmware compliant at the same time, if a designer really put his mind to it - one could probably write an EFI-compliant implementation in a mixture of forth and asm in the first place, and have it call legacy x86 PC ("PCI ROM type 0"), Open Firmware ("PCI ROM type 1") or EFI ("Proposed PCI ROM type 3") boot code segments on the PCI cards as it saw fit! The "Firmware Boot Manager" that EFI eventually drops into could be a full forth console, for all intel care, by my reading of the spec, and producing the EFI/ACPI device tree from the Open Firmware tree or vice-versa would just be a "simple" transform, I suppose.
I very, very much doubt anyone will bother doing this, though, unless Apple paid them a very large bung to encourage the proliferation of OpenFirmware-compliant devices...
So the fix is in already, as usual. Obviously, they've wheel-reinvented, presumably because OF is (was (afaik it's lapsed, like Scheme)) an IEEE standard they didn't control.
I quite like OpenFirmware, but have yet to see a x86 PC motherboard which uses it - PPC ones do, of course. The specification standard includes support for x86 computers, but the mobo manufacturers have deals with the BIOS producers (if they're not already the same company), and the BIOS producers have deals with MS, which means they've had financial incentives for years for keeping the BIOS in the dark ages of DOS.
Most current BIOSes are extremely biased toward DOS and DOS-derivatives like windows 95 - they're pretty ill suited to even Windows 2000, I'm sure microsoft now would prefer them to be replaced too (but with something that still ties you to MS, of course - no doubt MS will be prodding at x86 BIOS manufacturers to get this).
At the same time, perhaps what's needed is a open standard for the provision of a wodge of on-mobo flash-ram - the main reason people want to replace the BIOS with linux, so that the OS loads in a blink of an eye, perhaps without even requiring a HD. It's just silly that the BIOS spends a good while screwing around in Real Mode when Linux (or newer versions of Windows!) just go back and do all the setup again...
I thik it's be REALLY nice to have an OpenFirmware-type BIOS on x86, but with a few megs of flash on the motherboard that one could load the OS kernel and perhaps an initrd from, instead of having to mess about with the harddrive.
Question - has there been any progress made on bringing the respective component models of KDE and GNOME any closer together? It'd be nice to be able to embed a Bonobo component in a KParts document, perhaps itself embedded in a StarOffice or even Mozilla framework. How fundamentally different are KParts/DCOP, Bonobo/CORBA, StarOffice/UNO, Mozilla/XPCOM, Java/JavaBeans, Microsoft OLE/COM, (probably Xt belongs in this list too...), will there ever be any hope of unifying them a bit better ???
Apart from anything else - you already can embed video into word doc files. One thing MS worked out way, way back, was a generalised "Object Linking and Embedding" (OLE) Framework, akin to KParts in KDE or Bonobo in GNOME, which are much less mature versions of the same concept.
.doc file isn't editable on a computer without Autocad installed, and it's even worse for other things non-windows systems, since they may have very different applications. Thus, even though Star Office these days has the basic MS Word and Excel support down pretty well, it will take a bit of time before it's a general replacement. "Opening" the office document format isn't really all that much of a help in terms of additional information - the important thing is to stop MS taking legal action against those who use it, and to constrain MS themselves to stick to the documented document format ( :-) ) and not make changes to produce gratituous incompatibilities - many of the changes from word version to word version are not gratituous, but are actually a symptom of microsoft improving (or just bloating) the core of the program.
You can embed essentially any data the system is equipped to handle in a word file, even sound samples and video clips. It's reasonably clever, though other systems did it before MS (as usual). It's a bit like a GUI analog of the way unix command line tools can be used together, and is more powerful than some CLI bigots like to admit. One thing I don't like about the windows model is that it doesn't make it as easy as it could be to work with the GUI components FROM the CLI (unless you regard VBScript + Windows Scripting Host as the true CLI of the box, rather than the anaemic MSDOS shell - perhaps not such a bad assumption). KDE makes it really easy via the "dcop" command line tool, and, in theory, GNOME Bonobo is scriptable via CORBA-aware command line tools. OS/2 and the Amiga via (A)Rexx, and Apple via Applescript, were other examples of systems that got this sort of thing sorted.
Part of the problem with "opening" the format is that, up until Word 2000, it's really a dump of RTF mixed with whatever OLE/COM structures are in memory at the time, and after Word 2000, it's still partly a dump of OLE/COM, mixed with snippets of XML - a lot of Microsoft, and third-party, Windows software works this way, actually. It's a quick, easy and reliable way of implementing load/save functionality - Java, too, has it's serialization API to do the same sort of thing.
This is one of the reasons Star Office has such similar functionality to MS Office - if you want data format compatibility, you need functional compatibility, so you program is constrained to WORK similarly to MS stuff - and, for the user-acceptable minimum compatibility, you need to duplicate excel, MS picture editor, MS formula editor, etc, as well. Although such components all appear to be one monolithic block called "MS Office", at the Windows operating system level, they're a jungle of interactng pieces.
As it is, you still get people surprised when the Autocad drawing they've embedded in a MS
I may or may not be a freak (NB. I'm european, so that might automatically qualify me as a freak in the american outlook), and I'm probably only a liberal in the non-newspeak/non-political-party usage of the word - a supporter of liberty - i.e. freedom.
Even if I were a psycho fascist, a gender-ambiguous pronoun would be useful to me - what if I'm planning to have someone killed, and don't know what sex they are yet ? Hey, what if I'm a psycho fascist planning to kill someone precisely because they're not definable male or female? A gender-ambiguous pronoun is useful to almost everyone, even if they're decidedly not liberal.
Hmmm... I think this guy's making a good point, so I'll burn some karma points....
Just because MS weren't the original "bad-guys" (that'd probably be IBM in the 50s/60s), doesn't mean they're not bad guys.
Think about it - just because one murderer killed someone, doesn't make it O.K. for other people to do so.
(disregarding most of above post, although he's right about the lost art of trolling.)
"tey" sounds quite cool, actually. However, just as we have come to need a gender-ambiguous pronoun, how about a singular/plural ambiguous one? "they" again ? once again, that solution devalues the original use of "they". Suggestions?
Yes, Java is the new COBOL. No, seriously - it's being used everywhere COBOL used to be in businesses. MS wants a piece of that market, and, no doubt, will get some, with C#.
What are your views on societal transparency, as put forward by David Brin in his book - "The Transparent Society - Will Technology force us to choose between Privacy and Freedom".? (chapter one available online)
In this book, Brin argues that, given the existence and proliferation of surveillance technology, one of the few ways to avoid a "Big Brother" scenario is to make the surveillance networks real-time public-access, and "democratic"/all-encompassing, so that "The watched may watch the watchers". Brin then expands upon the possibly viable, perhaps even pleasant, social structure that might then evolve, rather than the usual dystopian vision of a police state.
(Of course, Popper covered the same ground, but Brin's more accessible, and deals particularly with the technological enabling factors of open societies)
Brin's observation that "In any situation involving a conflict between privacy and accountability, people demand privacy for themselves and accountability for everyone else", is particularly applicable, in my view, to the online-privacy debates. One core insight is that it is the asymmetric flow of information that often gives one group power over another.
Well, not an acronym, but "Solar Chimney" already sounds pretty cool - they've actually been around since the 80s, though the oil companies used to do a good job of silencing people who talk about them in the mainstream press - I remember reading about plans for a pilot plant in Spain in 1984.
Well, there you go, then. Apple may not have invented it, but they managed to _tell_ people that you could use your computer for digital video.
e.g. You and I know that you can store and manipulate photographs on computer - but lots of people don't think to do that until they see a "My Pictures" folder thoughtfully provided for them. In a similar fashion, the Amiga was fully capable of Quicktime-like feats of multimedia in 1991 (I know, I had several), but it wasn't SOLD as such all that much (thanks largely to managerial and marketing incompetence in CBM, most of America and a fair bit of Europe seemed to think of the Amiga as solely a games machine).
That's a mistake that developers make a lot - they, being smart, can see that one can quite happily use a text editor to make out a shopping list, or even keep a load of lists in a general purpose database, but joe-average-IQ on the street may not even think to do so with the status-symbol computer he just paid a small fortune for, unless there's a "My Shopping List" button for him to click, even if it only opens up a window with a "My Shopping List" titlebar containing a limited text editor component tied to a shoddy little database. There are people in the Windows world who can, and have, paid quite a bit for such products, which one could knock together in 5 minutes in tcl/tk in the linux world.
Microsoft and Apple understand this very well - general purpose tools are often unsuitable for people because people often aren't imaginative enough to use them. As a Very Clever Person, I'm always vaguely disillusioned by the "inside the box" thinking of most people I meet,
but one must recognise that People Are Stupid.