Check out ReplayGain - essentially it's just a set of metadata tags that indicate how different each track's or album's volume is from some standard baseline that can be used by any player that knows to look for these tags. These days, that should be most players - certainly XMMS, Rhythmbox and Muine support them and I assume that WinAMP, etc. also have support.
The Win32 threading and synchronisation models are ridiculously powerful compared to *nix, which is precisely what makes it so hard to port a lot of Win32-based software to other platforms. The fact that you can't do a simple operation like "wait for a mutex to be released or a socket to become readable" deserves to be a joke about legacy operating systems, not a persistent reality. At least BSD's kqueue comes close.
If that is true, then it's a shame that the performance of the Win32 sockets are so meagre compared to the Linux implementation. Take a look at this article on Developerworks. Maybe you can spot the changes required to close the performance gap between Windows and Linux (Linux running about 2 and a half times faster on the same machine).
And I think I'll take you to task for your blind assertion that "you can't do a simple operation like "wait for a mutex to be released or a socket to become readable" on a Unix platform. If you call pthread_mutex_lock in 'fast' mode it simply waits for the mutex to be released and will pick up as soon as the mutex becomes available. And there are plenty of other options around. It's also totally trivial to write a spin-check to check the TCP status of a socket.
Although Linux has yet to achieve wide popularity in the computer game world ("Will Linux Be Computer Games' Dark Horse OS?" Computer, Dec. 2001, pp. 161-162), it is making rapid progress toward becoming the dominant operating system in the other major entertainment arena: motion pictures. Name a motion picture from the past year or two that featured stunning animation or dazzling special effects, and chances are the film's producers used Linux-based computers to splash those graphics on the big screen.
"In short, the big news in Hollywood about Linux is it is no longer big news. Linux has won not only renderfarm servers, but the artist desktops of the top studios. It's hard to find a large studio that does not rely upon Linux as its primary animation and special effects OS, and many smaller film studios have adopted Linux, too...
"You hear a lot about Linux not being ready to work on desktops," said HP's Jeff Wood, director of product marketing for personal workstations. "Well, here we have the perfect example of how Linux is more than ready for the desktop -- hundreds of animators successfully used Linux to create a film right from their desktops."
NVidia Gelato (available FIRST for Linux - Windows XP coming soon)
Maya
Tremor
Shake
Houdini
Renderman
Cinepaint
You want companies? You've got companies:
Pixar (although Steve Jobs is moving them to Macs)
ILM
Weta Digital
Dreamworks
Linux is the pre-eminent renderfarm for Hollywood and is the dominant workstation for artists. But don't trust me - there are plenty of links out there on the web.
I don't see why they should be pushed to do anything. NVidia is a company, and thus is interested in making money. There's no money in Linux gaming technology because doing things for free (er..Open Source Development) is not a good business model.
But NVIDIA has plenty of incentive to provide good drivers for Linux machines - a significant chunk of the movie industry uses Linux workstations with NVIDIA cards for heavy duty 3d work. That is a market rich with capital potential. ATi hasn't managed to stabilize its Linux drivers to the same level and is lagging behind in Linux installations as a result. Having Doom3 demonstrated on linux desktops with NVIDIA cards might actually be a good demonstration of the latest technology.
id software's games are the only reason I buy new computers. Sure, I'll update my video card, or get a bigger hard drive, but as far a whole new system goes, it's just when id's new games come out.
I believe it. I've been holding off for Doom III to get close to release before I replace my machine so that I will end up with something capable of running ol' Doom3 well, rather than the scrag end of technology currently sitting under my desk at home. Athlon 650MHz? That's tech from the previous century!
On the other hand, it also gives me an excuse to stock up on the other games I haven't bought recently because my machine isn't up to it. UT2k4 here I come!
Cheers,
Toby Haynes
Appearing twice and making panoramas more cheaply
on
70 Megapixel Webcam
·
· Score: 2, Interesting
If it takes that long to shoot an entire cylinder, what prevents stuff from appearing twice in the picture, if it's quick enough? I mean, you could stand in front of the camera until it's got enough of you in the picture, and then run to the opposite spot so it scans you again, or some weird maneuver like that.
Nothing stops stuff appearing twice. It's that simple - the camera starts rotating and adds each slice to the current picture. You can then do all sorts of weird pictures in crowds or any scenario where there is a lot of movement.
I do wonder whether the CCD is 70 Mpixels or just the final image (and I haven't read the specs). I suspect the latter, as all you need is a CCD with, say, 4000 sensors mounted in an vertical array and the moving slit/lens combo allows you to read out the array every 7.5ms or so giving you 16000 horizontal pixels for the two minute scan. That's closer to the way existing film-based 360' panorama cameras work - just expose a long strip of film progressively as the camera rotates.
Still extremely cool.
For those of you who want to muck around with panoramic photos and you don't own a 360' camera like this, you should take a look at the various panorama tools available. I particularly like Hugin although I also use autopano-sift
to do some of the setup.
But if that's true, then why does word still load faster if I'm using the Crossover Office plug-in under linux? That removes all of the pre-loaded.dll arguments, now doesn't it?
I'm not pretending that OpenOffice.org isn't slow at getting started. In fact I wrote precisely that in the last paragraph of my parent post. On my A31p Thinkpad, OpenOffice.org Writer takes 8 seconds to pop up the flash screen and a further 8 seconds to complete loading on the first attempt. Once cached, a reload takes 1 second to pop up the flash screen and 2 more seconds to pop up the main screen. Loading an entire Word processing application from disk (not cached memory) in sub-second time isn't possible on todays machines without some tricks, whether they be file caching, library pre-loading or popping up the window to give feedback to the user even though you can't actually start using that window for several more seconds.
Note also that my parent post said a Default MS Word install. Not a customized install. Most people breeze through the install clicking next and leaving the defaults alone so Startup wizard is almost certainly on for most MS Word users.
I use FC2 on my desktop at work and I'm often irritated by the long startup times for many apps. Although the machine there isn't anything special (P4 2.8Ghz, 384MB Intel onboard video, 40GB HD) it's a bit much to wait around 15-20 seconds for OpenOffice to load (yes, I do increase the memory settings), or 8 seconds for Ethereal (gui). Once things are cached it's not too bad, but still nowhere close to say MS Word's sub-second load time on the same hardware.
And why do you think that MS Word pops up instantly? Think about it - it's a large program split over multiple files, all of which have to be accessed before the program can be run.
Now consider how long it takes to open a New window in OpenOffice.org once it is loaded.
Finished thinking? Good.
At this point, you are hopefully at the right conclusion - MS Word is already mostly loaded when you clicked on it to run. Almost all MS apps preload large sections of the core functionality in a standard install to improve responsiveness once the system is up and running. Alas this approach is also taken by a load of other apps on Windows with the net result that even though the desktop in Windows XP pops up faster on boot than previous iterations of the Windows OS, it can often be a couple of minutes before the hard drive stops popping and thrashing and the system becomes quiescent (and usable).
Real start up times for apps are difficult to gauge even when they aren't preloaded. OpenOffice.org is a slow starter although it is leaps-and-bounds better in version 1.1 than it used to be when it was first released and I hope that the improvements in start time continue . That said, on days when I'm writing a lot of documentation, it gets loaded in the morning once and gets used all day without complaint. If I accidently shut it down, most of the files used are still in the linux file cache and restarting it is a matter of a couple of seconds of turn over.
How long will this last. The BBC supplying to the world with only the Brits paying for it. I would guess they would give it to the Brits at no cost but charge everyone else.
The Beeb is making a fair amount of income from other sources. Take a look at TLC in the US - all of their top-ranked shows are under license from the BBC, from Clean Sweep to Trading Places. Then there are DVD and other media sales. PBS channels purchase shows like "Life Of Mammals" and comedies. The Beeb gets advertising revenue from the channels with commericials. The BBC is far from a licensing-fee-only company.
The whole point of XNA is provide a solid common library, which focuses on common game development tasks. This allows different platforms to very easily interoperate, but does not make it significantly easier to port games to other platforms. For instance, making a set of games that share the same game world and are all Live aware becomes quite simple, but porting a Xbox version of that same game to PC does not suddenly become a simple task. [snip]
The whole pointing in having a reference design is to increase interoperability, reduce development time, and reduce development cost. If another company makes a device using a reference design, it won't take your suggested 3 months to port a game to run on this new device -- it will take zero months, zero weeks, zero days, zero hours... no time at all since it will run on that device immediately.
Writing cross platform code doesn't quite work like that, even with a library available for all the platforms you are targetting.
Even if MS did provide a royalty-free, IETF or ISO-standardised spec and provided base libraries across all the platforms you are interested (and wake me up if that ever happens!) you are still facing time spent moving your current project to a new platform. Cross platform is more than just a buzzword - you really need to think ahead with your data structures, your communication mechanisms between threads/processes and your approach to designing the whole project early in the design so you don't get screwed over by changes in pointer sizes as you switch from 32 bit to 64 bit platforms or changes in endian-ness as you port from x86 to PowerPC. You can easily get caught out by marginally different floating point behaviour as you change architectures or even libraries - at least one game available on Linux and Windows doesn't have networking between Linux and Windows because the networking code uses floating point.
The problem a lot of developers for Windows platforms have is that they do not have to think about multi-platform portability because essentially every Windows platform they are likely to run on looks like x86. At least open source developers who post their sources on Sourceforge are likely, sooner or later, to have a PowerPC owner try and compile the sources and send the developer a problem report, so if they haven't considered portability right at the start, they stand some chance of being exposed to another platform earlier in development before a lot of code is set in stone. If you are really serious about cross platform work, it should be your first consideration in the first design you do and it should inform all of your subsequent work.
I have no idea if this is what the OP was driving at but it's not that hard to do fast divides using tables. Reciprocal lookup and multiply, then shift by the range of your reciprocal tables. So if you need a certain level of detail, say 3 decimal places, build tables of 1024/x or larger and shift the result back 10 bits after multiplication. Or at least that's how I used to do it on ARM cores when I was writing ARM assembler for fun(!).
You can also have fun with series expansions and other tricks for turning complex time consuming operations into faster, good-enough variations. It all depends on what matters to you - speed or accuracy.
Baystar are not selling their shares right now - they just doubled their stock by buying the 20,000 shares that the Royal Bank of Canada just cashed out of.
Yes but Baystar is not buying the currently-$5-and-dropping publicly traded shares. Baystar is buying 20,000 Series A shares worth $1000 each. Now the interesting part is that if SCO is forced to redeem these special stocks, Baystar gets considerably more than the $1000 per share because of the penalty clause - I think it's a 20% premium, so make that $1200 per share. So Baystar is unlikely to be out of cash if SCO is forced to re-imburse it. In fact Baystar will be up $8 million dollars on their holding of 40,000 Series A shares.
I have no problem with development, but the Open Source community should follow Debian's model and not release something (read Sarge) unless they're really sure its all done, and not release a version for every time feature add or small patch - have the fixes and patches as seperate entities and not as builds.
Maybe I'm misunderstanding your intent here but I'd say the release-early-release-often is a huge strength of open source development.
By showing all the warts, all the problems and solutions as they are worked on, those of us who are chasing the latest nightly CVS release get to help out by bug triaging, raising problem reports and commenting on the very latest change pretty much as it happens. This stops stupid decisions, breakages and irritations early before they are ingrained.
However, for the average user, that is too much. But just because development is pushing on at a rapid rate doesn't mean that the user has to play catch up. This is where the packagers of applications play their part - Mandrake/Debian/RedHat/etc - by providing a tested stable base. If you want the ultimate in stability, you would probably look at Debian Sarge or RHEL. You can pick a more intermediate solution which is closer to the latest releases with Mandrake numbered releases, closer still to the edge with Mandrake community/Fedore core 1 or almost at the bleeding edge with Cooker or Redhat Fedora 2 test 3.
So really, stability of releases is available now. The only scary thing here is that you have a Choice.
To all who visit the dilbert website regularly, has anyone seen that floating ad that blocks the last panel of the strip? I have seen it about 5 times and I read the site daily.
No - but that's because all the comics I'm interested are harvested for me every morning by the dailystrips scripts run on a cron job on my machine and nicely organized and indexed ready for my reading later. In theory, anything at all published on the web is retrievable by some method, processable and automatically tidied up before you view it.
If advertising ever gets bad enough that the web pages aren't really usable or readable without some extra processing, there will be a market for advanced filtering of whatever HTML/XHTML/XML is being used to extract the useful stuff. If that is integrated into a browser, then you might even not notice the muck. Or you could just go back to links/lynx/w3m or whatever.
In my experience it is not as simple as that. Most people have resistance for change. When they have got used to one operating system it is not easy to teach them to do things in a different way. And Linux is still behind Windows in terms of usability, which I think should be the first priority for future Linux development.
Actually, I'd disagree on both points. Most people wouldn't notice if you swapped Windows XP and XPde on their machines until they realized that their desktop had been running for a couple of months without a virus attack bringing their system to its knees. A developer would notice almost immediately but I suspect that if you kept the menus similar enough, most people would just pick up and go.
On useability, I'd say that GNOME was streets ahead of Windows for simplicity and usability (I don't use KDE so I can't compare there). Consistent look and feel across all HIGified GNOME apps, intelligent prompt buttons in prompt windows (and some serious gdesklet eyecandy:-) ) make it an easy system for a user to grasp. I find Windows XP to be a mess of animated icons and swooping flashing windows ruining my concentration in its default form, and I feel palpable relief when I get back to a Linux box with its calmer, faster and more comfortable setup.
Usability is partly a function of what you are used to. But switching isn't nearly as tough as a lot of people seem to think (or fear).
I'd probably start by recommending EmacsSpeak, simply because the combination of a complex editor environment with all sorts of smart speech hookups is a hugely important and useful tool for the blind. In some ways, X integration isn't a big thing for the blind - as long as your core environment can access everything you need (email, newsgroups, web pages, coding, etc.) you have no implicit need for X.
There are plenty of others. For Speech synthesis, you are probably looking at Festival. For Voice recognition, you are probably best off looking at IBM Viavoice for linux. GNOME has gone a very long way with the Accessibility toolkit and will continue to push down the accessibility path - for example, take a look at Dasher for an interesting app to aid writing for impaired users. There is a lot more on GNOME Accessibility to read.
Nah. Anyone can fork, any time, practically anything if you have the source code; sometimes it will be legal too. That's not interesting. What's interesting is whether the fork survives. Why would anyone else contribute to your branch when there's a main branch that *you've* left?
You're missing the point (or I'm not making myself clear enough, which is always possible).
Forking is only a problem IF you can't take the code in the new fork and put it back into the original project. I can give you two really good examples of projects which have been forked and the fork can't be merged back.
Emacs vs XEmacs split a long time ago. Code from XEmacs where the authors can't be contacted can't be integrated into Emacs. Ergo, a lot of the XEmacs development branch code is off-limits to the GNU Emacs tree. Now we have two similar but slightly incompatible versions arising from the same original tree which are stuck as a permanent fork.
Wine vs WineX. Transgaming forked the original Wine tree (which was under a BSD license), added some stuff and sold it, claiming that they would add code back to Wine at some point in the future (which they have to some extent). The Wine developers realised that they were losing out and decided to relicense the Wine tree to LGPL. Now Transgaming can't take the new Wine code into Transgaming.
Relicensing can result in a fork becoming a permanent, seperate entity. Compare that with the Linux kernel, which forks so fast you hardly know how many variants there are at any one time. Not that it matters - the GPL licensing keeps all those forks available all the time for any of the forks to consider. So while the kernel forks, none of the forks hurt the long-term picture - in fact they help it by providing experimental playgrounds for new ideas. BSD-style licensing would leave any or all of those forks vulnerable to a change of licensing that makes that fork off-limits to the other coding groups.
I was lost after the first clause ("FreeBSD allows forking pretty easially, Linux doesn't" - huh?), but was thinking maybe I missed something vital so I kept my mouth shut.
There is a certain truth to this. I can take a FreeBSD release, alter it and relicense it so that it can't be merged back into FreeBSD, allowing a permanent fork to occur. The GPL doesn't allow you to relicense the Linux codebase with the same freedom, so even when Linux kernel development forks, the forks can always be merged back into the 'main' tree at some future point.
Of course, I have no idea if that great-grandparent post actually meant that:-) It all seemed a bit close to being OT.
> who | wc -l 488 > uptime 2:27pm up 54 days, 21:23, 488 users, load average: 0.09, 0.18, 0.23
And what are those users doing? Not existing?
At 9.23pm (i.e. at NIGHT) I hope they are doing something other than burning CPU cycles:-)
Cheers,
Toby Haynes
Where's that 'Hopefully' mod when you need it...
on
Futurama: Can it be True!?
·
· Score: 2, Interesting
Movie Tome has an entry for a Firefly movie called "Serenity" that will start filming later this year and be ready by 2005. Hopefully it'll be successful and spawn another set of episodes or at the very least more movies.
You've got to hope that someone holding the money sees the light. A friend lent me the DVD box set of the Firefly episodes (as I'd missed them all first time around) and I'm hooked. I'm also totally pissed off that when I get to the end of Disc 4 there isn't any more to go round, so I'm praying that the movie is good enough to get another series going.
I assume there are GUI-based versions of these installers somewhere? If not, then Linux installs are indeed newbie-unfriendly (which is often confused with "hard to use").
For RPM
Mandrake
gurpmi
rpmdrake
MandrakeUpdate
RedHat
Up2Date applet
General
GnoRPM
Red Carpet
Synaptic
I'm sure I've missed several too. So yes - there are lots of graphical RPM installers. Personally, I like Red Carpet (and it's new friend Open Carpet) and the Mandrake urpmi tools.
Are you kidding me? You're going to give me anytime, anywhere access to over 400,000 songs for $10/month, and you complain?
Sorry. I already have access to umpteen SHOUTcast radio stations playing pretty much what I want to listen to. Having 400,000 songs available per month is pretty much the status quo already with Internet Radio - so why should I
a) pay a forced monthly fee and
b) have to put up with some DRM scheme which isn't going to work on any of my linux boxes if MS does its usual platform lockout.
Oh yes, I'm excited by the new DRM stuff. I'm excited to see just how fast it goes out of business.
I use fedora, and most often I get the *.src.rpm versions, then tweak the SPEC files as required, build my own binary rpms, and use those. Best of both worlds, IMO.
And the tweaking need not be that tricky or time consuming either. Decent defaults for building RPMS can be placed in your ~/.rpmrc file (or/etc/rpmrc, etc.). Once you have set your optimising settings, architectural preferences and packager name and cryptographic signature (if you want to submit them to other people), that's done for all future packages.
I used to run a mix of RPM packages and tarballs (./configure --prefix=/usr/local && make && su -c "make install") so I could tell what was under RPM control and what was not, but it became annoying when I wanted to build a Source RPM with dependencies on a package I had built from tarballs. These days I usually try and wrap any install up in an RPM - it's not difficult once you get hold of a skeleton spec file for your distro and it saves much hair pulling later on. Also the dependency requirements of RPMs actually save time in the long run because you know when removing a package will hose your system (or part of it) .
I think what the RIAA is really scared of is the fact that P2P distribution might allow an artist to gain fame and make money without going through the "major label system" and that'd be the death of that system. So, it's not that P2P threatens CD sales as much as it threatens RIAA-member CD sales by replacing them with something else.
Bingo. Control is what this is all about. Currently the RIAA is the center of the recording industry in the US. P2P allows artists to get publicity, distribution and "airplay" without needing the RIAA's enormous clout. Ergo, P2P and related technologies spell the beginning of a more diffuse market with less direct control available at the center of the marketplace.
I always wonder, what's wrong for IBM to release Lotus for Linux NATIVELY? If they really want to kick Microsoft ass - release Lotus for Linux for a competitive price and enjoy how it will help to sell Linux support contracts (in addition to Lotus licenses!) in several more F500s.
I've asked the same question. I still don't have an answer. The Domino server is on Linux. I view it as a straightforward argument to go to a Linux client to help customers pick the best platform for their business, rather than being tied to Windows on the desktop. But I'm not in the Lotus division and I don't know what is planned for the moment. The iNotes client DOES run on Linux and provides at least the basic functionality for most desktop tasks.
Speculation alert. Fact free zone follows...
I also suspect that the full Windows Notes client is heavily tied into the Windows API and can't be easily separated. I therefore suspect that it is more likely that a Notes on Wine package is a more likely market possibility than a full Notes GTK/Qt/wxwindows/Motif (just kidding;-) ) client package.
Cheers,
Toby Haynes
The Win32 threading and synchronisation models are ridiculously powerful compared to *nix, which is precisely what makes it so hard to port a lot of Win32-based software to other platforms. The fact that you can't do a simple operation like "wait for a mutex to be released or a socket to become readable" deserves to be a joke about legacy operating systems, not a persistent reality. At least BSD's kqueue comes close.
If that is true, then it's a shame that the performance of the Win32 sockets are so meagre compared to the Linux implementation. Take a look at this article on Developerworks. Maybe you can spot the changes required to close the performance gap between Windows and Linux (Linux running about 2 and a half times faster on the same machine).
And I think I'll take you to task for your blind assertion that "you can't do a simple operation like "wait for a mutex to be released or a socket to become readable" on a Unix platform. If you call pthread_mutex_lock in 'fast' mode it simply waits for the mutex to be released and will pick up as soon as the mutex becomes available. And there are plenty of other options around. It's also totally trivial to write a spin-check to check the TCP status of a socket.
Cheers,
Toby Haynes
- Linux in Hollywood: A Star Is Born
- Computer and Graphics World
- Sinbad Hears Linux's Siren Song
- TechNewsWorld: Linux in Hollywood
You want apps? You got've apps:- NVidia Gelato (available FIRST for Linux - Windows XP coming soon)
- Maya
- Tremor
- Shake
- Houdini
- Renderman
- Cinepaint
You want companies? You've got companies:Linux is the pre-eminent renderfarm for Hollywood and is the dominant workstation for artists. But don't trust me - there are plenty of links out there on the web.
Cheers,
Toby Haynes
But NVIDIA has plenty of incentive to provide good drivers for Linux machines - a significant chunk of the movie industry uses Linux workstations with NVIDIA cards for heavy duty 3d work. That is a market rich with capital potential. ATi hasn't managed to stabilize its Linux drivers to the same level and is lagging behind in Linux installations as a result. Having Doom3 demonstrated on linux desktops with NVIDIA cards might actually be a good demonstration of the latest technology.
Cheers,
Toby Haynes
I believe it. I've been holding off for Doom III to get close to release before I replace my machine so that I will end up with something capable of running ol' Doom3 well, rather than the scrag end of technology currently sitting under my desk at home. Athlon 650MHz? That's tech from the previous century!
On the other hand, it also gives me an excuse to stock up on the other games I haven't bought recently because my machine isn't up to it. UT2k4 here I come!
Cheers,
Toby Haynes
If it takes that long to shoot an entire cylinder, what prevents stuff from appearing twice in the picture, if it's quick enough? I mean, you could stand in front of the camera until it's got enough of you in the picture, and then run to the opposite spot so it scans you again, or some weird maneuver like that.
Nothing stops stuff appearing twice. It's that simple - the camera starts rotating and adds each slice to the current picture. You can then do all sorts of weird pictures in crowds or any scenario where there is a lot of movement.
I do wonder whether the CCD is 70 Mpixels or just the final image (and I haven't read the specs). I suspect the latter, as all you need is a CCD with, say, 4000 sensors mounted in an vertical array and the moving slit/lens combo allows you to read out the array every 7.5ms or so giving you 16000 horizontal pixels for the two minute scan. That's closer to the way existing film-based 360' panorama cameras work - just expose a long strip of film progressively as the camera rotates.
Still extremely cool.
For those of you who want to muck around with panoramic photos and you don't own a 360' camera like this, you should take a look at the various panorama tools available. I particularly like Hugin although I also use autopano-sift to do some of the setup.
Cheers,
Toby Haynes
I'm not pretending that OpenOffice.org isn't slow at getting started. In fact I wrote precisely that in the last paragraph of my parent post. On my A31p Thinkpad, OpenOffice.org Writer takes 8 seconds to pop up the flash screen and a further 8 seconds to complete loading on the first attempt. Once cached, a reload takes 1 second to pop up the flash screen and 2 more seconds to pop up the main screen. Loading an entire Word processing application from disk (not cached memory) in sub-second time isn't possible on todays machines without some tricks, whether they be file caching, library pre-loading or popping up the window to give feedback to the user even though you can't actually start using that window for several more seconds.
Note also that my parent post said a Default MS Word install. Not a customized install. Most people breeze through the install clicking next and leaving the defaults alone so Startup wizard is almost certainly on for most MS Word users.
Cheers,
Toby Haynes
And why do you think that MS Word pops up instantly? Think about it - it's a large program split over multiple files, all of which have to be accessed before the program can be run.
Now consider how long it takes to open a New window in OpenOffice.org once it is loaded.
Finished thinking? Good.
At this point, you are hopefully at the right conclusion - MS Word is already mostly loaded when you clicked on it to run. Almost all MS apps preload large sections of the core functionality in a standard install to improve responsiveness once the system is up and running. Alas this approach is also taken by a load of other apps on Windows with the net result that even though the desktop in Windows XP pops up faster on boot than previous iterations of the Windows OS, it can often be a couple of minutes before the hard drive stops popping and thrashing and the system becomes quiescent (and usable).
Real start up times for apps are difficult to gauge even when they aren't preloaded. OpenOffice.org is a slow starter although it is leaps-and-bounds better in version 1.1 than it used to be when it was first released and I hope that the improvements in start time continue . That said, on days when I'm writing a lot of documentation, it gets loaded in the morning once and gets used all day without complaint. If I accidently shut it down, most of the files used are still in the linux file cache and restarting it is a matter of a couple of seconds of turn over.
Cheers,
Toby Haynes
How long will this last. The BBC supplying to the world with only the Brits paying for it. I would guess they would give it to the Brits at no cost but charge everyone else.
The Beeb is making a fair amount of income from other sources. Take a look at TLC in the US - all of their top-ranked shows are under license from the BBC, from Clean Sweep to Trading Places. Then there are DVD and other media sales. PBS channels purchase shows like "Life Of Mammals" and comedies. The Beeb gets advertising revenue from the channels with commericials. The BBC is far from a licensing-fee-only company.
Cheers,
Toby Haynes
The whole pointing in having a reference design is to increase interoperability, reduce development time, and reduce development cost. If another company makes a device using a reference design, it won't take your suggested 3 months to port a game to run on this new device -- it will take zero months, zero weeks, zero days, zero hours... no time at all since it will run on that device immediately.
Writing cross platform code doesn't quite work like that, even with a library available for all the platforms you are targetting.
Even if MS did provide a royalty-free, IETF or ISO-standardised spec and provided base libraries across all the platforms you are interested (and wake me up if that ever happens!) you are still facing time spent moving your current project to a new platform. Cross platform is more than just a buzzword - you really need to think ahead with your data structures, your communication mechanisms between threads/processes and your approach to designing the whole project early in the design so you don't get screwed over by changes in pointer sizes as you switch from 32 bit to 64 bit platforms or changes in endian-ness as you port from x86 to PowerPC. You can easily get caught out by marginally different floating point behaviour as you change architectures or even libraries - at least one game available on Linux and Windows doesn't have networking between Linux and Windows because the networking code uses floating point.
The problem a lot of developers for Windows platforms have is that they do not have to think about multi-platform portability because essentially every Windows platform they are likely to run on looks like x86. At least open source developers who post their sources on Sourceforge are likely, sooner or later, to have a PowerPC owner try and compile the sources and send the developer a problem report, so if they haven't considered portability right at the start, they stand some chance of being exposed to another platform earlier in development before a lot of code is set in stone. If you are really serious about cross platform work, it should be your first consideration in the first design you do and it should inform all of your subsequent work.
Cheers,
Toby Haynes
You can also have fun with series expansions and other tricks for turning complex time consuming operations into faster, good-enough variations. It all depends on what matters to you - speed or accuracy.
Cheers,
Toby Haynes
Yes but Baystar is not buying the currently-$5-and-dropping publicly traded shares. Baystar is buying 20,000 Series A shares worth $1000 each. Now the interesting part is that if SCO is forced to redeem these special stocks, Baystar gets considerably more than the $1000 per share because of the penalty clause - I think it's a 20% premium, so make that $1200 per share. So Baystar is unlikely to be out of cash if SCO is forced to re-imburse it. In fact Baystar will be up $8 million dollars on their holding of 40,000 Series A shares.
Cheers,
Toby Haynes
Maybe I'm misunderstanding your intent here but I'd say the release-early-release-often is a huge strength of open source development.
By showing all the warts, all the problems and solutions as they are worked on, those of us who are chasing the latest nightly CVS release get to help out by bug triaging, raising problem reports and commenting on the very latest change pretty much as it happens. This stops stupid decisions, breakages and irritations early before they are ingrained.
However, for the average user, that is too much. But just because development is pushing on at a rapid rate doesn't mean that the user has to play catch up. This is where the packagers of applications play their part - Mandrake/Debian/RedHat/etc - by providing a tested stable base. If you want the ultimate in stability, you would probably look at Debian Sarge or RHEL. You can pick a more intermediate solution which is closer to the latest releases with Mandrake numbered releases, closer still to the edge with Mandrake community /Fedore core 1 or almost at the bleeding edge with Cooker or Redhat Fedora 2 test 3.
So really, stability of releases is available now. The only scary thing here is that you have a Choice.
Cheers,
Toby Haynes
To all who visit the dilbert website regularly, has anyone seen that floating ad that blocks the last panel of the strip? I have seen it about 5 times and I read the site daily.
No - but that's because all the comics I'm interested are harvested for me every morning by the dailystrips scripts run on a cron job on my machine and nicely organized and indexed ready for my reading later. In theory, anything at all published on the web is retrievable by some method, processable and automatically tidied up before you view it.
If advertising ever gets bad enough that the web pages aren't really usable or readable without some extra processing, there will be a market for advanced filtering of whatever HTML/XHTML/XML is being used to extract the useful stuff. If that is integrated into a browser, then you might even not notice the muck. Or you could just go back to links/lynx/w3m or whatever.
Cheers,
Toby Haynes
In my experience it is not as simple as that. Most people have resistance for change. When they have got used to one operating system it is not easy to teach them to do things in a different way. And Linux is still behind Windows in terms of usability, which I think should be the first priority for future Linux development.
Actually, I'd disagree on both points. Most people wouldn't notice if you swapped Windows XP and XPde on their machines until they realized that their desktop had been running for a couple of months without a virus attack bringing their system to its knees. A developer would notice almost immediately but I suspect that if you kept the menus similar enough, most people would just pick up and go.
On useability, I'd say that GNOME was streets ahead of Windows for simplicity and usability (I don't use KDE so I can't compare there). Consistent look and feel across all HIGified GNOME apps, intelligent prompt buttons in prompt windows (and some serious gdesklet eyecandy :-) ) make it an easy system for a user to grasp. I find Windows XP to be a mess of animated icons and swooping flashing windows ruining my concentration in its default form, and I feel palpable relief when I get back to a Linux box with its calmer, faster and more comfortable setup.
Usability is partly a function of what you are used to. But switching isn't nearly as tough as a lot of people seem to think (or fear).
Cheers,
Toby Haynes
There are plenty of others. For Speech synthesis, you are probably looking at Festival. For Voice recognition, you are probably best off looking at IBM Viavoice for linux. GNOME has gone a very long way with the Accessibility toolkit and will continue to push down the accessibility path - for example, take a look at Dasher for an interesting app to aid writing for impaired users. There is a lot more on GNOME Accessibility to read.
Cheers,
Toby Haynes
You're missing the point (or I'm not making myself clear enough, which is always possible).
Forking is only a problem IF you can't take the code in the new fork and put it back into the original project. I can give you two really good examples of projects which have been forked and the fork can't be merged back.
Emacs vs XEmacs split a long time ago. Code from XEmacs where the authors can't be contacted can't be integrated into Emacs. Ergo, a lot of the XEmacs development branch code is off-limits to the GNU Emacs tree. Now we have two similar but slightly incompatible versions arising from the same original tree which are stuck as a permanent fork.
Wine vs WineX. Transgaming forked the original Wine tree (which was under a BSD license), added some stuff and sold it, claiming that they would add code back to Wine at some point in the future (which they have to some extent). The Wine developers realised that they were losing out and decided to relicense the Wine tree to LGPL. Now Transgaming can't take the new Wine code into Transgaming.
Relicensing can result in a fork becoming a permanent, seperate entity. Compare that with the Linux kernel, which forks so fast you hardly know how many variants there are at any one time. Not that it matters - the GPL licensing keeps all those forks available all the time for any of the forks to consider. So while the kernel forks, none of the forks hurt the long-term picture - in fact they help it by providing experimental playgrounds for new ideas. BSD-style licensing would leave any or all of those forks vulnerable to a change of licensing that makes that fork off-limits to the other coding groups.
Cheers,
Toby Haynes
I was lost after the first clause ("FreeBSD allows forking pretty easially, Linux doesn't" - huh?), but was thinking maybe I missed something vital so I kept my mouth shut.
There is a certain truth to this. I can take a FreeBSD release, alter it and relicense it so that it can't be merged back into FreeBSD, allowing a permanent fork to occur. The GPL doesn't allow you to relicense the Linux codebase with the same freedom, so even when Linux kernel development forks, the forks can always be merged back into the 'main' tree at some future point.
Of course, I have no idea if that great-grandparent post actually meant that :-) It all seemed a bit close to being OT.
Cheers,
Toby Haynes
And what are those users doing? Not existing?
At 9.23pm (i.e. at NIGHT) I hope they are doing something other than burning CPU cycles :-)
Cheers,
Toby Haynes
Movie Tome has an entry for a Firefly movie called "Serenity" that will start filming later this year and be ready by 2005. Hopefully it'll be successful and spawn another set of episodes or at the very least more movies.
You've got to hope that someone holding the money sees the light. A friend lent me the DVD box set of the Firefly episodes (as I'd missed them all first time around) and I'm hooked. I'm also totally pissed off that when I get to the end of Disc 4 there isn't any more to go round, so I'm praying that the movie is good enough to get another series going.
Cheers,
Toby Haynes
I assume there are GUI-based versions of these installers somewhere? If not, then Linux installs are indeed newbie-unfriendly (which is often confused with "hard to use").
I'm sure I've missed several too. So yes - there are lots of graphical RPM installers. Personally, I like Red Carpet (and it's new friend Open Carpet) and the Mandrake urpmi tools.
Cheers,
Toby Haynes
Sorry. I already have access to umpteen SHOUTcast radio stations playing pretty much what I want to listen to. Having 400,000 songs available per month is pretty much the status quo already with Internet Radio - so why should I
Oh yes, I'm excited by the new DRM stuff. I'm excited to see just how fast it goes out of business.
Have a nice weekend,
Toby Haynes
I use fedora, and most often I get the *.src.rpm versions, then tweak the SPEC files as required, build my own binary rpms, and use those. Best of both worlds, IMO.
And the tweaking need not be that tricky or time consuming either. Decent defaults for building RPMS can be placed in your ~/.rpmrc file (or /etc/rpmrc, etc.). Once you have set your optimising settings, architectural preferences and packager name and cryptographic signature (if you want to submit them to other people), that's done for all future packages.
I used to run a mix of RPM packages and tarballs (./configure --prefix=/usr/local && make && su -c "make install") so I could tell what was under RPM control and what was not, but it became annoying when I wanted to build a Source RPM with dependencies on a package I had built from tarballs. These days I usually try and wrap any install up in an RPM - it's not difficult once you get hold of a skeleton spec file for your distro and it saves much hair pulling later on. Also the dependency requirements of RPMs actually save time in the long run because you know when removing a package will hose your system (or part of it) .
Cheers,
Toby Haynes
Bingo. Control is what this is all about. Currently the RIAA is the center of the recording industry in the US. P2P allows artists to get publicity, distribution and "airplay" without needing the RIAA's enormous clout. Ergo, P2P and related technologies spell the beginning of a more diffuse market with less direct control available at the center of the marketplace.
Cheers,
Toby Haynes
I always wonder, what's wrong for IBM to release Lotus for Linux NATIVELY? If they really want to kick Microsoft ass - release Lotus for Linux for a competitive price and enjoy how it will help to sell Linux support contracts (in addition to Lotus licenses!) in several more F500s.
I've asked the same question. I still don't have an answer. The Domino server is on Linux. I view it as a straightforward argument to go to a Linux client to help customers pick the best platform for their business, rather than being tied to Windows on the desktop. But I'm not in the Lotus division and I don't know what is planned for the moment. The iNotes client DOES run on Linux and provides at least the basic functionality for most desktop tasks.
Speculation alert. Fact free zone follows...
I also suspect that the full Windows Notes client is heavily tied into the Windows API and can't be easily separated. I therefore suspect that it is more likely that a Notes on Wine package is a more likely market possibility than a full Notes GTK/Qt/wxwindows/Motif (just kidding ;-) ) client package.
/Speculation alert ends.
Cheers,
Toby Haynes