It's definitely kdelibs or qt and friends. I can print from KDE apps to files no problem. Spooling that file to the printer like you say takes just as long to print. Anyhoo, not all Linux printing is slow. OpenOffice, Mozilla and scads of other proggies print fast. Any KDE generated Postscript is just dog slow and has been since at least the 2.x days.
I'm just guessing here but I'm think QT will use many detailed PS instructions to render something rather than scaling the output then sending simple bitmaps. The busier what I'm printing looks the worse the problem. Konqueror's default startup page is a good one. If your computer is a little on the slow side you can even watch Ghostview struggle a little with KDE Postscript.
I have indeed looked at PS in text editors. There's even some people who write programs in PS and use their printers as computers. See www.tinaja.org for examples of such insanity. His Case Against Patents is good reading too. It not the Slashdot case against patents but reasons for small inventors not to bother with them. Mucho interesting reading.
These boards won't contain a SWIM chip, Apple power manager chip, Apple firmware and some other fiddly bits to boot. A OS X install cd might not even start to boot and if it did it would probably lock up without so much as a Sad Mac.
Now, you could install Linux on of these and then Mac-On-Linux. That WILL let you run OSX but with non-accellerated video and no automagic use of attached periphreals.
Not just any PPC board can directly boot Mac OS. Apple has some fiddly copyrighted bits in the firmware that take care of that. Mac OS needs some particular hardware in the machine to boot. Apple doesn't have some sanctified right to prevent the production of PPC boards especially if the boards in question are intended to run a non-Apple OS.
Now it is true that you could run Mac-On-Linux on one of these boards but that is hardly a threat to Apple. MOL has to rely on the underlying OS for it's hardware facilities so it won't automagically work with many things like cd burners the way a native boot of MacOS will. Not many people are going to buy these boards and even fewer of those will run MOL. No threat to Apple whatsoever.
It takes more than a motherboard with a PPC chip to build an Apple clone. Since these don't have an Apple chipset and Apple firmware they won't boot Mac OS. They aren't Mac clones.
My Epson 600 (permanently clogged printhead grumble grumble) series inkjet has laid unused since I got a LJ 4M Plus. Sure it's black and white only but it's fast and Just Works. I have another one on my porch for spare parts. I'll use this printer for years to come. These printers are dead easy to work on too. Give me bin full of LJ IV parts and I can build printers out of them. It's tough as nails, has good print quality (600dpi), the cartridges last and last, prints reasonably fast, works well with Linux and is easy to service. I can live without color. If I ever do need color, I'll just pick up another inkjet and print to it maybe four times a year. Even a cheapo inkjet may last a long time with the LJ 4 doing the heavy lifting....assuming it doesn't clog up that is.
My only complaint is that KDE's print system can generate Postscript that takes this thing AGES to render. Basically, the green processing light blinks for 7 or 8 minutes then a page comes out of the engine at normal speed. This thing has 38 MB on the formatter board too! Sure, it looks pixel perfect when done but sheesh! Even newer HP lasers take a noticable amount of time printing from say Konqueror. We have an Oki 7200 in the office that prints KDE stuff fast. I guess that thing must have a fast CPU in it's Postscript interpreter. I suspect the problem is in QT. Maybe QT needs to expose some quality/speed tradeoff functionality to the end user. Moral of the story, don't print from KDE apps unless your printer can eat complicated Postscript for breakfast.
As long as the helium released is made of stable isotopes, it will have little to no effect. The Earth has insufficient gravity to retain either hydrogen or helium in significant quantities. The helium will basically waft away into space. If helium could be retained in the atmosphere Earth would be a gas giant.
I've serviced older ones for both work and relatives. Unless they've reformed themselves lately, all of those things I've mentioned applied. I had no reason to believe they've changed their behaivor. It may be that milage varies depending on who you order them from but I wouldn't trust them much further than I could throw one. I might use one for a throwaway machine (once I've completely replaced the default software load.) I would never deploy their ilk organization wide.
An eMachine that looks good on paper can be had for $550 or so. By looks good on paper I mean that will have impressive sounding specs like 40GB HDD, 1.8 Ghz processor and so forth. It will also feature a wimpy power supply. The build quality of the motherboard and included periphreals will be low as possible. The motherboard will probably use some weird chipset to boot. Beyond questionable hardware there will be software hassles. The default desktop will assault you with banner ads and it will have a shotgun spray of shovelware icons all over it. It will include "restore cds" instead of a true XP Home install CD. Which means re-gutting all of that crap should you ever have to use it.
Spending more money ups the quality of the hardware but even Dells and Gateways have the "shotgun spatter" default desktops and restore partitions. In all, it sounds like my idea of "annoyed lots".
I wouldn't say that Apple CPU's suck but Intel and AMD parts that will handily outperform them at most tasks fairly cheaply is a persistant reality. Yes, Apples have other merits that compensate for this. No argument.....I'm posting this from a Pismo Powerbook. It may be that Apple can correct that with upcoming parts but it isn't here today.
XFS offers acls and has been out for a few years now. The upcoming Reiser4 will support them and if I'm not mistaken the 2.5 series kernels will contain a common framework for acls so that one can switch between acl supporting filesystems with minimal breakage.
Multimedia editing is a desktop app that can make good use of 64 bits. It isn't uncommon to to have uncompressed DV captures 17GB in size. Add effects and a few edits and the address space of a 32-bit machine can start to hurt in a hurry. The end result will have to be compressed as well. Yes there are ways to cope with it but it re-introduces the segment offset nightmares of old school x86 programming. Also memory sizes on end user desktops are increasing. Anything more than 2GB on an x86 box starts getting painful. Yes, I know they can `technically' handle 4GB but kludgery starts setting in at 2GB.
"Mom" is starting to use this "PC Thingy" to make home movies. I see "Mom" needing 64 bits before long.
Gyro mouses work fairly well and with some work could be accurate enough for gaming. A feasible gun game that uses an LCD seems possible to me. It just wouldn't be a light gun. Just stick a gyro in a gun body and calibrate it now and again.
dmaxwell@Cinderella:~$ apt-cache search enlightenment e16keyedit - a keybinding editor for the enlightenment window manager e16menuedit - enlightenment menu editor enlightenment - The Enlightenment Window Manager enlightenment-data - Enlightenment Window Manager Run Time Data Files enlightenment-theme-bluesteel - Hunchback's BlueSteel theme for E enlightenment-theme-brushedmetal - Audio files for the BrushedMEtal-Tigert E Theme enlightenment-theme-ganymede - cK's Ganymede theme for E enlightenment-theme-shinymetal - Raster's ShinyMetal Theme for E epplets - The Epplets for the Enlightenment Window Manager eterm - Enlightened Terminal Emulator lg-issue17 - Issue 17 of the Linux Gazette. libedb1 - enlightenment's database access library libedb1-dev - Enlightenment's db convenience wrapper library. libevas0 - enlightenment advanced canvas library libstringlist0 - StringList - library for handling misc Enlightenment functions
Oh!, not THAT Enlightenment.... You mean like wisdom and deep knowledge and stuff. You're new here aren't you?
This third restriction often is called a "viral" clause, because it causes the GPL to "infect" any future software that incorporates GPL code, whether or not the developer intended that result.
Is MS saying the GPL code just miracles itself into projects where it isn't wanted? If a developer didn't intend his project to be GPLed then why would he let his code anywhere near it? Oh, so the author didn't read the license on that nifty piece of code that saved some time. Whose fault is that? Anyway, merely using GPLed code as part of a codebase doesn't make it GPLed. The GPL has to be at least implicitly accepted by the author(s).
If GPLed code were inserted into a project where it wasn't wanted or properly considered, the result is a codebase that is illegal to distribute. If the result is distributed then there is copyright violation. This violation has several remedies:
1. The entire codebase becomes GPLed. GPL bashers assume that is the ONLY thing that can happen. It isn't. The project may also link other code with incompatible licenses. The GPL cannot revoke the terms of those licenses. Also, the disputants or the court may come up with a different remedy.
2. Distribution of the offending product ceases until the GPL code is removed. Other penalties may apply. Yes, Virginia, financial penalties are a possibly. Trolltech would probably want some green if GPL QT were used in a proprietary product.
3. A different license is negotiated for the GPLed code. The copyright holder of GPLed software can impose whatever license he wants. The FSF probably wouldn't do this for any of their code but not all GPLed code is owned by the FSF. This distinction is also typically lost on GPL bashers.
Oh well, I doubt Microsoft fails to understand any of this. They distribute Interix themselves....and comply fully with the GPL in that case. It didn't turn magically turn Windows all GPL either. They're just being deliberately obtuse.
To the extent that a productivity app is an authoring tool then no Office isn't viral. However, electronic documents also function as a communications tool. Even if one completely dislikes MS and is therefore not inclined to give them money, he'll have to pony up for at least one copy of Office. As soon as one needs to communicate with an MS shop, it becomes necessary to buy a copy of Office. It also becomes extremely tempting to use it for other things because the Office you bought for communications purposes also duplicates the functionality of other authoring tools.
Office is viral because it is needed to communicate with everyone else who uses Office. Everyone who buys a copy of Office to engage in communication propagates it further.
It's more effort not to share. Another poster mentioned that he ended up with an increasingly hard to maintain internal fork of a graphics library because his changes couldn't be shared back. It will take a while but practicality will drive this home. Much of the benefit of OSS is having a lot of your work done for you by others. That little bit you have to do for yourself becomes an increasing burden to maintain as the the projects' code you are using evolves.
Let's worry about one hurdle at a time. It used to be hard to get corporate users to take OSS seriously. They're starting to take it seriously but that is miles away from a deep understanding. Give the realities time to sink in. Haranging such users to share will do nothing but damage but time and circumstance will accomplish sharing anyway. Don't sweat it.
Food service organizations must regularly monitor and log the temperature of their refrigerators. If one is off for any reason, the Health Department gets verrrrry testy. A net enabled device to check the temp does not substitute for showing up in person with a thermometer. However, this would allow them to spot trouble brewing before the health inspectors find it.
We would have to keep the second because so many other units have time in seconds as a term. Building up from seconds by powers of ten isn't all that unnatural. A centasecond is 40 seconds longer than a minute. That isn't too bad, it's about half way between a minute and two minutes. It still works for "give me a minute" type situations. Going beyond that, it gets really hard to fit it to the day. Sure, the astronomical phenomena the usual calendar is based on are slowly changing but they'll still fit pretty well on timescales in the thousands of years. So yeah, it would be stupid to change that on Earth.
If however we leave the Earth in significant numbers and I'm not holding my breath, then it won't make sense at all to tie time to a planet you haven't been to you're entire life. Earth based time wouldn't seem very sensical to even a Solar System spanning civilization. If Mars, planetoids, and gas giant moons are inhabited then decimal time starts looking pretty good. The orbital and rotation periods of any one body will be arbitrary to any other.
Decimal time would then serve the same purpose Railroad Time used to serve. The inhabitants of a particular body can use whatever local standard they wish and the Decimal standard for intrasystem use.
Of course, it will be hundreds of years at least before we have to worry about any of this. If we have to wait on NASA better make it thousands.
Maybe infernal combustion engines aren't the way to do this. I wonder if using it for direct heat or running a steam turbine wouldn't be better. Of course, the turbine approach only works for a large scale operation. Then too, there are the economy of scale problem. A diesel that's been primarily engineered to burn diesel isn't going to be all that good for burning anything else. A "modified diesel" is probably a good example. A diesel that's been engineered (materially and otherwise) to burn biogas would probably work better. The problem here is that there has to be enough incentive to make a lot of them. Building one or two such engines wouldn't pay off what it cost to design them.
Anyhow, I don't think burning biogas is a bad idea. It will have to be properly engineered and applied to worth a squat though.
Sun would like Linux to go away so they can retake the low end and mid level markets, where Linux dominates.
If Linux went away, the low and mid level markets would be inherited by the BSDs and Microsoft. I don't think Sun could fill the niche vacuum this would create very well at all. Sure Sun solutions scale and are reliable but they are expensive and they make most of their money on the high end.
If Linux went away, that would just give more oxygen to MS and embolden them to step up their attacks on the rest of the server industry. I think Sun just might start wishing it had Linux back if that happened.
Tax software is a money maker because it has to be updated each year to account for changes in the tax code. GNUcash could be equipped with general functions useful for tax preparation but that will be about as useful as the DOOM engine without a wadfile. Somebody will have to provide a supported debugged module that is correct for the tax year in a timely fashion. Open Source/Free will not work for this. OS/Free applications grow like stalagtites and acquire features and maturity over time. These tax modules have to be complete and relatively debugged each and every year.
I think it would be a good idea for GNUcash to facilitate tax modules with a sane framework. But if someone steps up to the plate with a "GNUcash tax module" its going to be a pay service. If the GNUcash people do it right, that module can function as a configfile and not as software. That way, they needn't get they're knickers in a bunch since a reasonable module WILL have a restrictive license. I suppose it would be even more practical if GNUcash could talk to an online server that uses GNUcash data to figure the taxes. The data could be returned to GNUcash which can use OS/Free functionality to actually print the return. No matter how you do it, your taxes won't be entirely figured by something you download from SourceForge.
The general publics attitude is irrelavant in the case of person who just wants a bare box minus the cost of Windows. Anything unwanted you have to pay for is a scourge. The fact that you or the general public like it doesn't matter. The general public isn't using a Linux or BSD user's personal machine.
For the medium term, bare boxes are a perfectly acceptable vendor alternative. They're still obligated to exchange defective hardware but most Linux users can support themselves. The "we can't support it." argument doesn't matter either. The vendor doesn't need to know what I'm running. Just fork over the box and I'll worry about the OS.
Milage varies. I have little trouble getting things working in Linux. Now that I've learned it well, it is Windows that is a hassle for me. It is difficult to buy even bare machines so I build my own. Otherwise I have to pay significant money for something I'm not going to use. Therefore it is a tax to me. Yes it is, I have to expend labor not to pay it....which is preferable since I won't pay for something that I'm going to use for a drink coaster as soon as I get it out of the box.
Since you're going to use Windows, it is a purchase price. It is a big difference and the term tax is merited no matter how much you personally like and want Windows.
Smoothness when dragging stuff around probably has more to do with the 2D hardware on your graphics adaptor and the drivers for it. Even though this new kernel apparantly will make things feel snappier I still wouldn't be surprised if GUI jumpiness still happens. 3D acceleration seems to be the hot priority right now. Hence Quartz Extreme in OS X, since the video card is being optimized for 3D make everything look like it's 3D.
Slashdot Mirror
It's definitely kdelibs or qt and friends. I can print from KDE apps to files no problem. Spooling that file to the printer like you say takes just as long to print. Anyhoo, not all Linux printing is slow. OpenOffice, Mozilla and scads of other proggies print fast. Any KDE generated Postscript is just dog slow and has been since at least the 2.x days.
I'm just guessing here but I'm think QT will use many detailed PS instructions to render something rather than scaling the output then sending simple bitmaps. The busier what I'm printing looks the worse the problem. Konqueror's default startup page is a good one. If your computer is a little on the slow side you can even watch Ghostview struggle a little with KDE Postscript.
I have indeed looked at PS in text editors. There's even some people who write programs in PS and use their printers as computers. See www.tinaja.org for examples of such insanity. His Case Against Patents is good reading too. It not the Slashdot case against patents but reasons for small inventors not to bother with them. Mucho interesting reading.
These boards won't contain a SWIM chip, Apple power manager chip, Apple firmware and some other fiddly bits to boot. A OS X install cd might not even start to boot and if it did it would probably lock up without so much as a Sad Mac.
Now, you could install Linux on of these and then Mac-On-Linux. That WILL let you run OSX but with non-accellerated video and no automagic use of attached periphreals.
Not just any PPC board can directly boot Mac OS. Apple has some fiddly copyrighted bits in the firmware that take care of that. Mac OS needs some particular hardware in the machine to boot. Apple doesn't have some sanctified right to prevent the production of PPC boards especially if the boards in question are intended to run a non-Apple OS.
Now it is true that you could run Mac-On-Linux on one of these boards but that is hardly a threat to Apple. MOL has to rely on the underlying OS for it's hardware facilities so it won't automagically work with many things like cd burners the way a native boot of MacOS will. Not many people are going to buy these boards and even fewer of those will run MOL. No threat to Apple whatsoever.
It takes more than a motherboard with a PPC chip to build an Apple clone. Since these don't have an Apple chipset and Apple firmware they won't boot Mac OS. They aren't Mac clones.
My Epson 600 (permanently clogged printhead grumble grumble) series inkjet has laid unused since I got a LJ 4M Plus. Sure it's black and white only but it's fast and Just Works. I have another one on my porch for spare parts. I'll use this printer for years to come. These printers are dead easy to work on too. Give me bin full of LJ IV parts and I can build printers out of them. It's tough as nails, has good print quality (600dpi), the cartridges last and last, prints reasonably fast, works well with Linux and is easy to service. I can live without color. If I ever do need color, I'll just pick up another inkjet and print to it maybe four times a year. Even a cheapo inkjet may last a long time with the LJ 4 doing the heavy lifting....assuming it doesn't clog up that is.
My only complaint is that KDE's print system can generate Postscript that takes this thing AGES to render. Basically, the green processing light blinks for 7 or 8 minutes then a page comes out of the engine at normal speed. This thing has 38 MB on the formatter board too! Sure, it looks pixel perfect when done but sheesh! Even newer HP lasers take a noticable amount of time printing from say Konqueror. We have an Oki 7200 in the office that prints KDE stuff fast. I guess that thing must have a fast CPU in it's Postscript interpreter. I suspect the problem is in QT. Maybe QT needs to expose some quality/speed tradeoff functionality to the end user. Moral of the story, don't print from KDE apps unless your printer can eat complicated Postscript for breakfast.
As long as the helium released is made of stable isotopes, it will have little to no effect. The Earth has insufficient gravity to retain either hydrogen or helium in significant quantities. The helium will basically waft away into space. If helium could be retained in the atmosphere Earth would be a gas giant.
I've serviced older ones for both work and relatives. Unless they've reformed themselves lately, all of those things I've mentioned applied. I had no reason to believe they've changed their behaivor. It may be that milage varies depending on who you order them from but I wouldn't trust them much further than I could throw one. I might use one for a throwaway machine (once I've completely replaced the default software load.) I would never deploy their ilk organization wide.
An eMachine that looks good on paper can be had for $550 or so. By looks good on paper I mean that will have impressive sounding specs like 40GB HDD, 1.8 Ghz processor and so forth. It will also feature a wimpy power supply. The build quality of the motherboard and included periphreals will be low as possible. The motherboard will probably use some weird chipset to boot. Beyond questionable hardware there will be software hassles. The default desktop will assault you with banner ads and it will have a shotgun spray of shovelware icons all over it. It will include "restore cds" instead of a true XP Home install CD. Which means re-gutting all of that crap should you ever have to use it.
Spending more money ups the quality of the hardware but even Dells and Gateways have the "shotgun spatter" default desktops and restore partitions. In all, it sounds like my idea of "annoyed lots".
I wouldn't say that Apple CPU's suck but Intel and AMD parts that will handily outperform them at most tasks fairly cheaply is a persistant reality. Yes, Apples have other merits that compensate for this. No argument.....I'm posting this from a Pismo Powerbook. It may be that Apple can correct that with upcoming parts but it isn't here today.
XFS offers acls and has been out for a few years now. The upcoming Reiser4 will support them and if I'm not mistaken the 2.5 series kernels will contain a common framework for acls so that one can switch between acl supporting filesystems with minimal breakage.
They used to say that you could always pick the Osbourne users out of a crowd. They were the ones with one shoulder 5 inches lower than the other.
Multimedia editing is a desktop app that can make good use of 64 bits. It isn't uncommon to to have uncompressed DV captures 17GB in size. Add effects and a few edits and the address space of a 32-bit machine can start to hurt in a hurry. The end result will have to be compressed as well. Yes there are ways to cope with it but it re-introduces the segment offset nightmares of old school x86 programming. Also memory sizes on end user desktops are increasing. Anything more than 2GB on an x86 box starts getting painful. Yes, I know they can `technically' handle 4GB but kludgery starts setting in at 2GB.
"Mom" is starting to use this "PC Thingy" to make home movies. I see "Mom" needing 64 bits before long.
Gyro mouses work fairly well and with some work could be accurate enough for gaming. A feasible gun game that uses an LCD seems possible to me. It just wouldn't be a light gun. Just stick a gyro in a gun body and calibrate it now and again.
It's in LOTs of distros.....
dmaxwell@Cinderella:~$ apt-cache search enlightenment
e16keyedit - a keybinding editor for the enlightenment window manager
e16menuedit - enlightenment menu editor
enlightenment - The Enlightenment Window Manager
enlightenment-data - Enlightenment Window Manager Run Time Data Files
enlightenment-theme-bluesteel - Hunchback's BlueSteel theme for E
enlightenment-theme-brushedmetal - Audio files for the BrushedMEtal-Tigert E Theme
enlightenment-theme-ganymede - cK's Ganymede theme for E
enlightenment-theme-shinymetal - Raster's ShinyMetal Theme for E
epplets - The Epplets for the Enlightenment Window Manager
eterm - Enlightened Terminal Emulator
lg-issue17 - Issue 17 of the Linux Gazette.
libedb1 - enlightenment's database access library
libedb1-dev - Enlightenment's db convenience wrapper library.
libevas0 - enlightenment advanced canvas library
libstringlist0 - StringList - library for handling misc Enlightenment functions
Oh!, not THAT Enlightenment.... You mean like wisdom and deep knowledge and stuff. You're new here aren't you?
This third restriction often is called a "viral" clause, because it causes the GPL to "infect" any future software that incorporates GPL code, whether or not the developer intended that result.
Is MS saying the GPL code just miracles itself into projects where it isn't wanted? If a developer didn't intend his project to be GPLed then why would he let his code anywhere near it? Oh, so the author didn't read the license on that nifty piece of code that saved some time. Whose fault is that? Anyway, merely using GPLed code as part of a codebase doesn't make it GPLed. The GPL has to be at least implicitly accepted by the author(s).
If GPLed code were inserted into a project where it wasn't wanted or properly considered, the result is a codebase that is illegal to distribute. If the result is distributed then there is copyright violation. This violation has several remedies:
1. The entire codebase becomes GPLed. GPL bashers assume that is the ONLY thing that can happen. It isn't. The project may also link other code with incompatible licenses. The GPL cannot revoke the terms of those licenses. Also, the disputants or the court may come up with a different remedy.
2. Distribution of the offending product ceases until the GPL code is removed. Other penalties may apply. Yes, Virginia, financial penalties are a possibly. Trolltech would probably want some green if GPL QT were used in a proprietary product.
3. A different license is negotiated for the GPLed code. The copyright holder of GPLed software can impose whatever license he wants. The FSF probably wouldn't do this for any of their code but not all GPLed code is owned by the FSF. This distinction is also typically lost on GPL bashers.
Oh well, I doubt Microsoft fails to understand any of this. They distribute Interix themselves....and comply fully with the GPL in that case. It didn't turn magically turn Windows all GPL either. They're just being deliberately obtuse.
To the extent that a productivity app is an authoring tool then no Office isn't viral. However, electronic documents also function as a communications tool. Even if one completely dislikes MS and is therefore not inclined to give them money, he'll have to pony up for at least one copy of Office. As soon as one needs to communicate with an MS shop, it becomes necessary to buy a copy of Office. It also becomes extremely tempting to use it for other things because the Office you bought for communications purposes also duplicates the functionality of other authoring tools.
Office is viral because it is needed to communicate with everyone else who uses Office. Everyone who buys a copy of Office to engage in communication propagates it further.
It's more effort not to share. Another poster mentioned that he ended up with an increasingly hard to maintain internal fork of a graphics library because his changes couldn't be shared back. It will take a while but practicality will drive this home. Much of the benefit of OSS is having a lot of your work done for you by others. That little bit you have to do for yourself becomes an increasing burden to maintain as the the projects' code you are using evolves.
Let's worry about one hurdle at a time. It used to be hard to get corporate users to take OSS seriously. They're starting to take it seriously but that is miles away from a deep understanding. Give the realities time to sink in. Haranging such users to share will do nothing but damage but time and circumstance will accomplish sharing anyway. Don't sweat it.
Food service organizations must regularly monitor and log the temperature of their refrigerators. If one is off for any reason, the Health Department gets verrrrry testy. A net enabled device to check the temp does not substitute for showing up in person with a thermometer. However, this would allow them to spot trouble brewing before the health inspectors find it.
Does that mean Windows ME is a Vega or maybe even a Pinto?
We would have to keep the second because so many other units have time in seconds as a term. Building up from seconds by powers of ten isn't all that unnatural. A centasecond is 40 seconds longer than a minute. That isn't too bad, it's about half way between a minute and two minutes. It still works for "give me a minute" type situations. Going beyond that, it gets really hard to fit it to the day. Sure, the astronomical phenomena the usual calendar is based on are slowly changing but they'll still fit pretty well on timescales in the thousands of years. So yeah, it would be stupid to change that on Earth.
If however we leave the Earth in significant numbers and I'm not holding my breath, then it won't make sense at all to tie time to a planet you haven't been to you're entire life. Earth based time wouldn't seem very sensical to even a Solar System spanning civilization. If Mars, planetoids, and gas giant moons are inhabited then decimal time starts looking pretty good. The orbital and rotation periods of any one body will be arbitrary to any other.
Decimal time would then serve the same purpose Railroad Time used to serve. The inhabitants of a particular body can use whatever local standard they wish and the Decimal standard for intrasystem use.
Of course, it will be hundreds of years at least before we have to worry about any of this. If we have to wait on NASA better make it thousands.
Maybe infernal combustion engines aren't the way to do this. I wonder if using it for direct heat or running a steam turbine wouldn't be better. Of course, the turbine approach only works for a large scale operation. Then too, there are the economy of scale problem. A diesel that's been primarily engineered to burn diesel isn't going to be all that good for burning anything else. A "modified diesel" is probably a good example. A diesel that's been engineered (materially and otherwise) to burn biogas would probably work better. The problem here is that there has to be enough incentive to make a lot of them. Building one or two such engines wouldn't pay off what it cost to design them.
Anyhow, I don't think burning biogas is a bad idea. It will have to be properly engineered and applied to worth a squat though.
Let the Mad Mad: Beyond Thunderdome jokes begin!
Sun would like Linux to go away so they can retake the low end and mid level markets, where Linux dominates.
If Linux went away, the low and mid level markets would be inherited by the BSDs and Microsoft. I don't think Sun could fill the niche vacuum this would create very well at all. Sure Sun solutions scale and are reliable but they are expensive and they make most of their money on the high end.
If Linux went away, that would just give more oxygen to MS and embolden them to step up their attacks on the rest of the server industry. I think Sun just might start wishing it had Linux back if that happened.
Tax software is a money maker because it has to be updated each year to account for changes in the tax code. GNUcash could be equipped with general functions useful for tax preparation but that will be about as useful as the DOOM engine without a wadfile. Somebody will have to provide a supported debugged module that is correct for the tax year in a timely fashion. Open Source/Free will not work for this. OS/Free applications grow like stalagtites and acquire features and maturity over time. These tax modules have to be complete and relatively debugged each and every year.
I think it would be a good idea for GNUcash to facilitate tax modules with a sane framework. But if someone steps up to the plate with a "GNUcash tax module" its going to be a pay service. If the GNUcash people do it right, that module can function as a configfile and not as software. That way, they needn't get they're knickers in a bunch since a reasonable module WILL have a restrictive license. I suppose it would be even more practical if GNUcash could talk to an online server that uses GNUcash data to figure the taxes. The data could be returned to GNUcash which can use OS/Free functionality to actually print the return. No matter how you do it, your taxes won't be entirely figured by something you download from SourceForge.
The general publics attitude is irrelavant in the case of person who just wants a bare box minus the cost of Windows. Anything unwanted you have to pay for is a scourge. The fact that you or the general public like it doesn't matter. The general public isn't using a Linux or BSD user's personal machine.
For the medium term, bare boxes are a perfectly acceptable vendor alternative. They're still obligated to exchange defective hardware but most Linux users can support themselves. The "we can't support it." argument doesn't matter either. The vendor doesn't need to know what I'm running. Just fork over the box and I'll worry about the OS.
Milage varies. I have little trouble getting things working in Linux. Now that I've learned it well, it is Windows that is a hassle for me. It is difficult to buy even bare machines so I build my own. Otherwise I have to pay significant money for something I'm not going to use. Therefore it is a tax to me. Yes it is, I have to expend labor not to pay it....which is preferable since I won't pay for something that I'm going to use for a drink coaster as soon as I get it out of the box.
Since you're going to use Windows, it is a purchase price. It is a big difference and the term tax is merited no matter how much you personally like and want Windows.
Smoothness when dragging stuff around probably has more to do with the 2D hardware on your graphics adaptor and the drivers for it. Even though this new kernel apparantly will make things feel snappier I still wouldn't be surprised if GUI jumpiness still happens. 3D acceleration seems to be the hot priority right now. Hence Quartz Extreme in OS X, since the video card is being optimized for 3D make everything look like it's 3D.