Work is being done on using carbon nanorods to store hydrogen (amongst others by the Renewable Energies Research Lab in Golden, CO). These would be cheap and safely disposable and probably represent the future of hydrogen fuel tech.
As a desktop OS for l33t g4m3r kiddies maybe:) However, I think you'll find a lot of NT4 workstation installs in business and academia (my area). You don't need directx to run excel or draw graphs. Upgrading from NT4 to XP is a big unnecessary cost for organisations and a big compatability problem in the interim; incompatability of roving profiles etc.
GIFs are limited to 8-bit colour depth, no alpha layer etc. etc. PNG is a standardised, open format with support for lossless encoding of full colour graphics with transparencies.
Saying that GIF becoming patent unencumbered is going to reduce use of PNG is like implying that when the original patents ran out on horses & carriages people gave up their cars and reverted. Ain't gonna happen:)
I've always found the interpreted nature of LABVIEW to be extremely useful when debugging your instrumental setup. Basically it allows you to easily add breakpoints, do stepped execution and use printf style debugging without recompiles or source changes. Very useful when one of your monochromators (Z80 based) has decided to spontaneously reset it's GPIB address to that currently occupied by your other monochromator:)
If graphical programming sucks for you (and it sucks for me) NI also provide their instrument interface code as a C API.
Your hdd is filling up? Buy another one:) In my opinion spring cleaning is forced by hard drive failure, just make sure you've backed up any original data (savegames, work, probably 600 mb worth:)).
And as and added bonus these laser fusion experiments produce conditions similar to that, as you say, in a hydrogen bomb. Hence the results are effectively a military nuclear test just wrapped up in civilian `clean power-source' clothing. Neat, eh?
Shock 2 was good, but the graphics were, for the time, rather dodgy which detracted from the experience. Saying that, I do remember pulling myself away from it about 10pm, wandering to the local coop to buy some food, hearing a noise behind me (a cyclist) and whirling around reaching for my `shotgun'.
However, SS1 was the true scare fest. The fragments of journals of death crewmembers really built up the atmosphere - I was death scared turning the corner at the wall marked `Here' even though I really knew the worst thing I'd be seeing would be a low res 2d pixelly cyborg:)
I've played that game 3 or 4 times through. SS2 lost many of the best bits - puzzles, cyberspace etc. etc.
The command line is a clunky way of doing things compared to an intuitive GUI and simply a throwback to when computers didn't do graphics.
This statement alone makes me doubt the rest of what this guy has to say. GUIs are good for simple tasks you don't do very often. The command line and scripting languages have the power to automate and achieve complex tasks.
I got rather caught out by this - my new laptop came without serial ports and the first piece of hardware I needed to use was a circa 1985 spectraphotometer which only had an RS232 interface. So now I have to go and hunt some dodgy USB->serial thingy.
CDT work with novel polymer displays which, particularly in the blue, have stability problems.
This display is made from small organic molecules - a more mature field and is unlikely to suffer degradation effects any worse than say, a plasma display.
I think the main advantage is cost. OLEDs tend to be far more efficient than their polymer brethren. However, OLEDs must be made with expensive and difficult vacuum deposition techniques whereas industrially useful EL polymers are solution processable - they will dissolve in common organic solvents, eg. p-xylene, chloroform etc. and hence can be ink-jet printed, spin cast etc.
So how long does it take to boil the mirror into vapor?
I think the vapour would prove a problem for the laser as well. Presumably we want to focus our laser nice and tight on the target to get a high power per cm^2. Now, if we have a layer of vapour, this is going to be differentially heated by the laser beam and act as a diverging thermal lens. This breaks our nice focus and reduces the effective power of our beam.
I'm always surprised that yet another Mozilla version does not fix big usability bugs.
These include the broken line wrapping that happens occasionally, the bizarrely greyed-out `launch file' option after downloading some types of files and finally, the irritating way in which if you download a file which turns out to 404, mozilla happily creates the file on your disc containing the 404 html and doesn't tell you!
The most significant point as I see it is that the new EULA no longer means that Bioware/Info immediately own all rights to your work and can tell you to stop distributing it.
I don't particularly have a problem with Bioware selling anything I make - I'm unlikely to do so, providing I hold onto the IP rights.
>There has been a serious attempt at providing >sensible defaults for a lot of stuff, and hide >away rare and/or strange options into the gconf >system.
I'm all for sensible defaults and I appreciate the fact that the average non-technical user doesn't want to be swamped with seemingly meaningless configuration options.
However, I think the _majority_ of people using Gnome 2 are not said computer-illetarates.
Firstly, I find it annoying to have to click `Advanced' or similar to get to the options I need - surely I should have the ability to put all config options in the first page if I like.
Worse, gconf-editor is a horribly unsafe editor for configuration options. Type in the wrong font name and watch your desktop become unretreivable instantly! It's almost the equivalent of Windows registry hackery.
Gnome should stop disadvantaging the people who actually use it in favour of a prospective audience which it probably won't reach.
Me? I'm sticking with raw Sawfish; no GNOME or KDE here.
As others have said, yes, RPM dependancy hell is a problem. But the solution is not to emulate the inherant crapness of Windows packaging, DLL hell etc.
I find the comment `and if you want to save your open source os' particularly amusing. Linux doesn't seem in particular need of saving to me.
RPM in principle is moderately nice. Binaries get put into the PATH, it's easy to put in scripts, doesn't require X etc. etc.
What we should do is address the problem with RPM which is that of dependances.
Here we can take inspiration from the Windows world. When you create an Installshield or WISE package installer it bundles any necessary libraries with the executable (in theory). Hence for your end user it is a case of click and install.
Now, why not do the same thing with RPM.
Have rpmbuild as an option create a uber-RPM including the RPMs for the package in question and all of the unusual libraries required. Now when you post your software on the web you can post both a 500K RPM with just the programme RPM, or a 3 MB RPM with programme + a few libraries.
Now, the `depth' of libraries to include is somewhat debatable, I would propose including anything not in most distros or in gnome/KDE base.
Hence your Windows luser like the above poster can d/l the 3 MB one and then drool as the programme installs no problem, and your 133t sysadmin asr reading BOFH can d/l the 500 K one and install that.
Me, I'd probably download the 3MB one too. Bandwidth is cheap.
This lawsuit is malicious and seemingly legally tenuous. It's a classic example of a large corporation bullying a small independant group by scaring with them with a big lawsuit.
It also seems rather misaimed - the bnetd people didn't add the War3 support that Blizzard seems concerned about, this is another group who are not being sued.
I don't think Blizzard will win the case; it is clear that bnetd was created through legal reverse engineering and not, as Blizzard are suggesting, by EULA defying decompilation etc.
However regardless of the outcome Blizzard will have won in that many people will think twice about working on such OS programmes - who wants the stress of a lawsuit?
Blizzard should have done the sensible thing, encrypted their protocol with a private key buryed in the War3 etc. binary where cracking it would be a clear DMCA violation. But they screwed up by making a reverse engineerable protocol and are now suing people to cover up their mistake.
> 1) Greatly reduce dependency hell since all these distributions will be guaranteed to have a predefined set of libraries.
I think it will perhaps reduce dependency hell for commercial products.
`Unfortunately' most OS projects reasonably want to make use of the latest and greatest features of libraries and hence always require libgnome-mm-ximian-1.2.1-66ac5.rpm as a dependency.
What I'd like to see is a grouped rpm format. A single package which contains a rpm of the binary package and all the relevant libraries (with the exclusion of libc or libX11 or big ones like that). Okay, the d/l would be bigger but it would make installation hopefully more simple and save hours hunting on rpmfind.net.
It seems to me that Bioware is ignoring a time proven economic model here.
Would Parker pens be so popular if everything you wrote with them became the property of Parker or if Parker could revoke your rights to what you created at any time?
Are Microsoft bemoaning the poor sales of MS VC++ or are they making a lot of money on a compiler which doesn't place restrictions on compiled code?
In what way will it hurt Bioware's profits it's there's an active fan community producing, or even selling modules? To use said modules, you need the game and such submarkets keep the market for the original product alive after it's shelflife.
If I were Bioware, which I am obviously not:), I would not only give people free reign on their modules but grant them a royalty free license to use the textures and models that came with the toolkit, for the sole purpose of writing modules.
"Infogrames or BIOWARE may at any time and in its sole discretion revoke your right to make your Modules publicly available."
I, as much as anyone else, hate rpm dependency hell.
However, I don't think we'd have such a vibrant open source scene without shared libraries like zlib and libjpeg.
If you are releasing a stable version of your code try to depend on as much as possible, the version of whatever libraries you need which came with the latest RedHat.
If people did this and RedHat had an extension to rpm...
`libpng not found, insert redhat cd 1 to install'
I think dependency problems would be much reduced.
Other than that, you want to live on the bleedin' edge, you're gonna have to do some work (or use Debian:)).
Or we go XBox-like and statically link everything:)
Slashdot Mirror
Hmm, are you sure you are not looking at the superior-Japanese-versions-for-comparison rather than the dodgy-Yank-versions-for-cheap-laughs? :)
Work is being done on using carbon nanorods to store hydrogen (amongst others by the Renewable Energies Research Lab in Golden, CO). These would be cheap and safely disposable and probably represent the future of hydrogen fuel tech.
As a desktop OS for l33t g4m3r kiddies maybe :) However, I think you'll find a lot of NT4 workstation installs in business and academia (my area). You don't need directx to run excel or draw graphs. Upgrading from NT4 to XP is a big unnecessary cost for organisations and a big compatability problem in the interim; incompatability of roving profiles etc.
GIFs are limited to 8-bit colour depth, no alpha layer etc. etc. PNG is a standardised, open format with support for lossless encoding of full colour graphics with transparencies.
:)
Saying that GIF becoming patent unencumbered is going to reduce use of PNG is like implying that when the original patents ran out on horses & carriages people gave up their cars and reverted. Ain't gonna happen
I've always found the interpreted nature of LABVIEW to be extremely useful when debugging your instrumental setup. Basically it allows you to easily add breakpoints, do stepped execution and use printf style debugging without recompiles or source changes. Very useful when one of your monochromators (Z80 based) has decided to spontaneously reset it's GPIB address to that currently occupied by your other monochromator :)
If graphical programming sucks for you (and it sucks for me) NI also provide their instrument interface code as a C API.
Your hdd is filling up? Buy another one :) In my opinion spring cleaning is forced by hard drive failure, just make sure you've backed up any original data (savegames, work, probably 600 mb worth :)).
And as and added bonus these laser fusion experiments produce conditions similar to that, as you say, in a hydrogen bomb. Hence the results are effectively a military nuclear test just wrapped up in civilian `clean power-source' clothing. Neat, eh?
Personally, without sticky focus like on X, I find it impossible to work with overlapping windows on Windows. Click to focus and raise is so 80s.
Shock 2 was good, but the graphics were, for the time, rather dodgy which detracted from the experience. Saying that, I do remember pulling myself away from it about 10pm, wandering to the local coop to buy some food, hearing a noise behind me (a cyclist) and whirling around reaching for my `shotgun'.
:)
However, SS1 was the true scare fest. The fragments of journals of death crewmembers really built up the atmosphere - I was death scared turning the corner at the wall marked `Here' even though I really knew the worst thing I'd be seeing would be a low res 2d pixelly cyborg
I've played that game 3 or 4 times through. SS2 lost many of the best bits - puzzles, cyberspace etc. etc.
The command line is a clunky way of doing things compared to an intuitive GUI and simply a throwback to when computers didn't do graphics.
This statement alone makes me doubt the rest of what this guy has to say. GUIs are good for simple tasks you don't do very often. The command line and scripting languages have the power to automate and achieve complex tasks.
I got rather caught out by this - my new laptop came without serial ports and the first piece of hardware I needed to use was a circa 1985 spectraphotometer which only had an RS232 interface. So now I have to go and hunt some dodgy USB->serial thingy.
Journeying from city to city looking for a job doesn't count.
Isn't that NP hard?
CDT work with novel polymer displays which, particularly in the blue, have stability problems.
This display is made from small organic molecules - a more mature field and is unlikely to suffer degradation effects any worse than say, a plasma display.
I think the main advantage is cost. OLEDs tend to be far more efficient than their polymer brethren. However, OLEDs must be made with expensive and difficult vacuum deposition techniques whereas industrially useful EL polymers are solution processable - they will dissolve in common organic solvents, eg. p-xylene, chloroform etc. and hence can be ink-jet printed, spin cast etc.
disposal is cleaner, not containing toxic chemical compounds
:)
Actually, methanol is considered toxic. However, carrying around compressed hydrogen for an H2 fuel cell is probably not much better
So how long does it take to boil the mirror into vapor?
I think the vapour would prove a problem for the laser as well. Presumably we want to focus our laser nice and tight on the target to get a high power per cm^2. Now, if we have a layer of vapour, this is going to be differentially heated by the laser beam and act as a diverging thermal lens. This breaks our nice focus and reduces the effective power of our beam.
I'm always surprised that yet another Mozilla version does not fix big usability bugs.
These include the broken line wrapping that happens occasionally, the bizarrely greyed-out `launch file' option after downloading some types of files and finally, the irritating way in which if you download a file which turns out to 404, mozilla happily creates the file on your disc containing the 404 html and doesn't tell you!
Yeah.
The most significant point as I see it is that the new EULA no longer means that Bioware/Info immediately own all rights to your work and can tell you to stop distributing it.
I don't particularly have a problem with Bioware selling anything I make - I'm unlikely to do so, providing I hold onto the IP rights.
>There has been a serious attempt at providing
>sensible defaults for a lot of stuff, and hide
>away rare and/or strange options into the gconf
>system.
I'm all for sensible defaults and I appreciate the fact that the average non-technical user doesn't want to be swamped with seemingly meaningless configuration options.
However, I think the _majority_ of people using Gnome 2 are not said computer-illetarates.
Firstly, I find it annoying to have to click `Advanced' or similar to get to the options I need - surely I should have the ability to put all config options in the first page if I like.
Worse, gconf-editor is a horribly unsafe editor for configuration options. Type in the wrong font name and watch your desktop become unretreivable instantly! It's almost the equivalent of Windows registry hackery.
Gnome should stop disadvantaging the people who actually use it in favour of a prospective audience which it probably won't reach.
Me? I'm sticking with raw Sawfish; no GNOME or KDE here.
Yawn.
As others have said, yes, RPM dependancy hell is a problem. But the solution is not to emulate the inherant crapness of Windows packaging, DLL hell etc.
I find the comment `and if you want to save your open source os' particularly amusing. Linux doesn't seem in particular need of saving to me.
RPM in principle is moderately nice. Binaries get put into the PATH, it's easy to put in scripts, doesn't require X etc. etc.
What we should do is address the problem with RPM which is that of dependances.
Here we can take inspiration from the Windows world. When you create an Installshield or WISE package installer it bundles any necessary libraries with the executable (in theory). Hence for your end user it is a case of click and install.
Now, why not do the same thing with RPM.
Have rpmbuild as an option create a uber-RPM including the RPMs for the package in question and all of the unusual libraries required. Now when you post your software on the web you can post both a 500K RPM with just the programme RPM, or a 3 MB RPM with programme + a few libraries.
Now, the `depth' of libraries to include is somewhat debatable, I would propose including anything not in most distros or in gnome/KDE base.
Hence your Windows luser like the above poster can d/l the 3 MB one and then drool as the programme installs no problem, and your 133t sysadmin asr reading BOFH can d/l the 500 K one and install that.
Me, I'd probably download the 3MB one too. Bandwidth is cheap.
This lawsuit is malicious and seemingly legally tenuous. It's a classic example of a large corporation bullying a small independant group by scaring with them with a big lawsuit.
It also seems rather misaimed - the bnetd people didn't add the War3 support that Blizzard seems concerned about, this is another group who are not being sued.
I don't think Blizzard will win the case; it is clear that bnetd was created through legal reverse engineering and not, as Blizzard are suggesting, by EULA defying decompilation etc.
However regardless of the outcome Blizzard will have won in that many people will think twice about working on such OS programmes - who wants the stress of a lawsuit?
Blizzard should have done the sensible thing, encrypted their protocol with a private key buryed in the War3 etc. binary where cracking it would be a clear DMCA violation. But they screwed up by making a reverse engineerable protocol and are now suing people to cover up their mistake.
> 1) Greatly reduce dependency hell since all these distributions will be guaranteed to have a predefined set of libraries.
I think it will perhaps reduce dependency hell for commercial products.
`Unfortunately' most OS projects reasonably want to make use of the latest and greatest features of libraries and hence always require libgnome-mm-ximian-1.2.1-66ac5.rpm as a dependency.
What I'd like to see is a grouped rpm format. A single package which contains a rpm of the binary package and all the relevant libraries (with the exclusion of libc or libX11 or big ones like that). Okay, the d/l would be bigger but it would make installation hopefully more simple and save hours hunting on rpmfind.net.
It seems to me that Bioware is ignoring a time proven economic model here.
:), I would not only give people free reign on their modules but grant them a royalty free license to use the textures and models that came with the toolkit, for the sole purpose of writing modules.
Would Parker pens be so popular if everything you wrote with them became the property of Parker or if Parker could revoke your rights to what you created at any time?
Are Microsoft bemoaning the poor sales of MS VC++ or are they making a lot of money on a compiler which doesn't place restrictions on compiled code?
In what way will it hurt Bioware's profits it's there's an active fan community producing, or even selling modules? To use said modules, you need the game and such submarkets keep the market for the original product alive after it's shelflife.
If I were Bioware, which I am obviously not
"Infogrames or BIOWARE may at any time and in its sole discretion revoke your right to make your Modules publicly available."
This clause is particularly disturbing.
Well, Bioware, you've lost another sale.
I misread that as a `little bit of perl' which made the Python comment so much more relevant...
I, as much as anyone else, hate rpm dependency hell.
:)).
:)
However, I don't think we'd have such a vibrant open source scene without shared libraries like zlib and libjpeg.
If you are releasing a stable version of your code try to depend on as much as possible, the version of whatever libraries you need which came with the latest RedHat.
If people did this and RedHat had an extension to rpm...
`libpng not found, insert redhat cd 1 to install'
I think dependency problems would be much reduced.
Other than that, you want to live on the bleedin' edge, you're gonna have to do some work (or use Debian
Or we go XBox-like and statically link everything