The real reason these things went out of fashion
on
Build Your Own Lava Lamp
·
· Score: 4, Insightful
...is because they were found to be responsible for numerous house fires. I suspect the modern ones are far safer than those made in the 1970's, but I'd expect a home-made one to be potentially quite dangerous.
I'm in NZ, with a NZ isp email address, and I was getting a lot of annoying emails. I was wondering why in the last few days I've hardly got any at all. Makes sense.
Also I haven't received SoBig.F in over 2 days either... odd...
I would have thought the highly litigious atmosphere in the USA would dictate that you've already broken several health and safety laws just opening the box and are now open to all sorts of nasty lawsuits.
However, like numerous others before me, I have to ask - "are you insane?"
Step away from the box, call an electrician before the place burns down, and get it fixed quickly and properly. If you try and do it yourself you could easily end up destroying costly equipment and endangering other peoples' lives.
So is that actually usb 1.0 or 1.1 renamed as usb 2.0 (usb full speed) or usb high speed incorrectly labelled as usb 2.0?
I realise this sort of thing has been debated to death, but the Rio Karma is meant to be a new product, so why haven't they adopted the new USB nomenclature (which, in my opinion, is far less confusing than the old system now that it exists. However, in turn, its existence has made the old system more confusing. Can't win 'em all)?
I guess we just need some way of speaking in symbols:
"The protocol formerly known as USB 2.0 provides fast transfers while the included docking station also adds drop-in charging..."
When I was at the Ottawa Linux Symposium, everyone pronounced Torvald's first name as 'Leeenous' and that would lead me to believe Linux is pronounced 'Leeeenoux'. However everyone said it slightly differently. So who cares? I pronounce Windows as 'fsck off you useless piece of bitwise excrement' and everyone knows what I mean.
If you had read my comment carefully, you would have realised I wasn't talking about Linux specifically. I agree that all those programs you listed, and many more, are all part of the same idea/ideal.
I wouldn't say it was a cure-all but it's a step in the right direction, even if it forces the commercial players to improve their own software. It's actually not primarily about the software produced, but a change in the way software is created.
Most (not all) software is not designed, it's grown. A lot of non-software engineers don't understand this. GNU/Linux, OSS, etc all recognised this basic change in software engineering principles and seek to capitalise on this new paradigm.
Think of Linux et al as the seeds of something better, rather than a complete solution to the World's problems.
Haven't you tried any other modern distributions? Debian comes to mind with apt-get. In fact, I've had more luck upgrading Debian than I have had with Gentoo lately. Specifically, be careful if you unmask a package like transcode - it makes emerge -u world have a fit...
Actually, compact flash cards usually contain an embedded controller that manages the internal flash for you, including wear leveling (spreading the writes over the entire flash). These CF devices usually look like an IDE disk drive from the outside, complete with CHS/LBA addressing.
Flash filesystems such as JFFS are designed for RAW flash, and NOT for compact flash. You have little, if any, control over how the internal controller manages the flash inside the CF card, so you might as well run FAT or ext2 on it.
For example, you cannot say with any certainty (just by looking/prodding it) whether two adjacent sectors in the IDE space are actually adjacent in the flash space - they might be at completely different 'ends' of the flash. Only the controller knows the mapping.
And assuming you do work it out, it will be different on the next variant or manufacturers CF card.
You would be better off, in my opinion, booting the kernel and mounting a read-only filesystem from compact flash. If you need to write persistent data, you can copy the root filesystem to a ramdisk and periodically write the data back to the flash. Here we calculated that a write every 15 minutes would allow the CF we are using in our microwave radios to last 30 years. The tradeoff is, you can lose up to 15 minutes of data (usually logs) if the power cuts out.
In terms of performance ("faster"), it really depends quite heavily on several factors, including your hardware and the game itself. Wine(X) is a compatibility layer rather than an emulator, so corresponding Win32 API calls in the game are handled by the wine subsystems. I imagine generally this would be a little slower than the native win32 environment, since these routines are further 'backed' by the native environment (X11 etc). It's like adding an extra function call (at least) to each one the game makes. The faster your CPU is, the less impact these additional layers of execution are going to have.
Programming the hardware rendering pipeline is done via a DirectX-compatible layer (I guess not for OpenGL games?). If you have a high end video card (with drivers) and your Linux kernel is friendly with your north bridge, then rendering speeds are probably around about the same as in Windows.
So, final performance is really going to depend on where the bottleneck is. If the game is limited by your video acceleration hardware, then it's probably going to run about the same in Linux as in Windows, given your hardware has similar kernel and driver support in both. If the major bottleneck is with the CPU (e.g. a complex physics engine or large amounts of computation) then, based on my previous comments, it makes sense to expect the game to perform worse in the Linux environment.
I've played such things as UT, UT2003 in Linux 'natively' and I found the performance comparable to the same game running in Windows. Under WineX I've played around with RollerCoasterTycoon, Jagged Alliance 2, Fallout 2, Jedi Knight 2, and a few others. I found all of these games ran slower in Linux than in Windows. However, not a *lot* slower, just noticably slower. They were still technically playable.
Which brings me to an interesting point. By far, the most problems I've had with WineX haven't been due to graphics, sound, performance or even copy protection. The biggest problems I've had *by far* have been to do with my mouse. In RCT, the right mouse button refuses to work properly; in JA2, a single click ends up a double click (which is a lot more annoying than it might sound - especially with checkboxes!). Getting my Microsoft joystick working hasn't been fruitful (I don't even know for sure that it's possible). It's a bit of a disappointment to successfully install your favourite game with WineX, fire it up to see the wonderful and familiar graphics, hear the emotion-stirring music, only to discover you can't click on anything or the keyboard doesn't work.
WineX is an interesting project and one I hope continues to improve. However, it only takes me a minute or two to boot into Windows and fire up something for my 'fix'. At the end of the day, I'm not too bothered if I'm gaming in Windows or Linux, as long as I get to have some fun.
Good point - that would make for a LOT of sheep. Well, I'm only going by what I heard on WW2BA$10e6, which must be true, because it's on TV.
(The actual question was something like this: 'which country has recently exceeded Australia in terms of the number of sheep per capita? Answers were China, Russia, New Zealand and USA. Now I think about it, it's ridiculous to think that China would ever have more sheep per capita than Australia. My faith in gameshows has been shattered...)
Actually, we don't have as many sheep as we used to - from memory it's dropped from somewhere around 60 million down to only about 40 million. Australia and China have more sheep per capita now (according to Who Wants To Be A Millionaire, which is almost as good as google, but it's only on twice a week).
With our population just passing 4 million (people) that's only 10 sheep per person. We've all had to cut back on lamb roasts...
Because different devices have different communications requirements, cost restrictions and intended purposes.
Maybe one day we'll have a ubiquitous communications interface that *everything* uses (we are getting closer to that all the time with USB, firewire, etc), but only when the cost becomes so low it doesn't make sense to use something slower/simpler/easier-to-write-software-for.
It wasn't so much the laptop falling asleep - just having the APM code active in the kernel was doing something screwy to the interrupt handling from the NiDaq card. It would fail acquisition after 15 seconds or so (although fairly randomly).
David Schleef pointed this fix out to me after I asked him very politely about what the $#@$ was going on...
To whoever modded me 'troll' - read the story - you'll notice the first sentence is the original author's exact words. I was just pointing out that it didn't seem to make any sense to me.
I've used comedi with a National Instruments NiDAQ 16 channel acquisition card on a P3 laptop running debian - it worked very well.
However, can I offer the following advice, which may save some people from smashing their head into a bloody pulp against a wall...
* Turn off APM!!! *
You can do this by passing apm=off to the Linux kernel with your bootloader (I think - can't actually check that at the moment) if you don't want to actually remove it from the kernel (APM is useful on a laptop normally).
If you don't do this, you might find your acquisition mysteriously stalling after random intervals. It's to do with APM interrupt handling. Not sure if it's restricted to PCMCIA cards.
You've wasted a *lot* of time and effort trying to implement some simple stuff with free (and better) alternatives? Surely that beats wasting a lot of time and effort trying to implement the same things with commercial (and worse) alternatives?
I'll give you the benefit of the doubt and assume you made a slight 'grammaro'.
Slashdot Mirror
...is because they were found to be responsible for numerous house fires. I suspect the modern ones are far safer than those made in the 1970's, but I'd expect a home-made one to be potentially quite dangerous.
/. is the right place for it! :)
So I guess
The Linux Kernel Janitor Project might be a good place to start.
http://sourceforge.net/projects/kernel-janitor
Gotta start somewhere though - an opensource driver is a good place to start building your superior functionality on.
I'm in NZ, with a NZ isp email address, and I was getting a lot of annoying emails. I was wondering why in the last few days I've hardly got any at all. Makes sense.
Also I haven't received SoBig.F in over 2 days either... odd...
lol - that's classic :) Well done.
Massey University is in New Zealand, not Australia! Where did you learn geography? In the USA?
I would have thought the highly litigious atmosphere in the USA would dictate that you've already broken several health and safety laws just opening the box and are now open to all sorts of nasty lawsuits.
However, like numerous others before me, I have to ask - "are you insane?"
Step away from the box, call an electrician before the place burns down, and get it fixed quickly and properly. If you try and do it yourself you could easily end up destroying costly equipment and endangering other peoples' lives.
So is that actually usb 1.0 or 1.1 renamed as usb 2.0 (usb full speed) or usb high speed incorrectly labelled as usb 2.0?
I realise this sort of thing has been debated to death, but the Rio Karma is meant to be a new product, so why haven't they adopted the new USB nomenclature (which, in my opinion, is far less confusing than the old system now that it exists. However, in turn, its existence has made the old system more confusing. Can't win 'em all)?
I guess we just need some way of speaking in symbols:
"The protocol formerly known as USB 2.0 provides fast transfers while the included docking station also adds drop-in charging..."
When I was at the Ottawa Linux Symposium, everyone pronounced Torvald's first name as 'Leeenous' and that would lead me to believe Linux is pronounced 'Leeeenoux'. However everyone said it slightly differently. So who cares? I pronounce Windows as 'fsck off you useless piece of bitwise excrement' and everyone knows what I mean.
If you had read my comment carefully, you would have realised I wasn't talking about Linux specifically. I agree that all those programs you listed, and many more, are all part of the same idea/ideal.
I wouldn't say it was a cure-all but it's a step in the right direction, even if it forces the commercial players to improve their own software. It's actually not primarily about the software produced, but a change in the way software is created.
Most (not all) software is not designed, it's grown. A lot of non-software engineers don't understand this. GNU/Linux, OSS, etc all recognised this basic change in software engineering principles and seek to capitalise on this new paradigm.
Think of Linux et al as the seeds of something better, rather than a complete solution to the World's problems.
That's my opinion anyway.
Haven't you tried any other modern distributions? Debian comes to mind with apt-get. In fact, I've had more luck upgrading Debian than I have had with Gentoo lately. Specifically, be careful if you unmask a package like transcode - it makes emerge -u world have a fit...
Actually, compact flash cards usually contain an embedded controller that manages the internal flash for you, including wear leveling (spreading the writes over the entire flash). These CF devices usually look like an IDE disk drive from the outside, complete with CHS/LBA addressing.
Flash filesystems such as JFFS are designed for RAW flash, and NOT for compact flash. You have little, if any, control over how the internal controller manages the flash inside the CF card, so you might as well run FAT or ext2 on it.
For example, you cannot say with any certainty (just by looking/prodding it) whether two adjacent sectors in the IDE space are actually adjacent in the flash space - they might be at completely different 'ends' of the flash. Only the controller knows the mapping.
And assuming you do work it out, it will be different on the next variant or manufacturers CF card.
You would be better off, in my opinion, booting the kernel and mounting a read-only filesystem from compact flash. If you need to write persistent data, you can copy the root filesystem to a ramdisk and periodically write the data back to the flash. Here we calculated that a write every 15 minutes would allow the CF we are using in our microwave radios to last 30 years. The tradeoff is, you can lose up to 15 minutes of data (usually logs) if the power cuts out.
It's a precaution rather than a requirement.
In terms of performance ("faster"), it really depends quite heavily on several factors, including your hardware and the game itself. Wine(X) is a compatibility layer rather than an emulator, so corresponding Win32 API calls in the game are handled by the wine subsystems. I imagine generally this would be a little slower than the native win32 environment, since these routines are further 'backed' by the native environment (X11 etc). It's like adding an extra function call (at least) to each one the game makes. The faster your CPU is, the less impact these additional layers of execution are going to have.
Programming the hardware rendering pipeline is done via a DirectX-compatible layer (I guess not for OpenGL games?). If you have a high end video card (with drivers) and your Linux kernel is friendly with your north bridge, then rendering speeds are probably around about the same as in Windows.
So, final performance is really going to depend on where the bottleneck is. If the game is limited by your video acceleration hardware, then it's probably going to run about the same in Linux as in Windows, given your hardware has similar kernel and driver support in both. If the major bottleneck is with the CPU (e.g. a complex physics engine or large amounts of computation) then, based on my previous comments, it makes sense to expect the game to perform worse in the Linux environment.
I've played such things as UT, UT2003 in Linux 'natively' and I found the performance comparable to the same game running in Windows. Under WineX I've played around with RollerCoasterTycoon, Jagged Alliance 2, Fallout 2, Jedi Knight 2, and a few others. I found all of these games ran slower in Linux than in Windows. However, not a *lot* slower, just noticably slower. They were still technically playable.
Which brings me to an interesting point. By far, the most problems I've had with WineX haven't been due to graphics, sound, performance or even copy protection. The biggest problems I've had *by far* have been to do with my mouse. In RCT, the right mouse button refuses to work properly; in JA2, a single click ends up a double click (which is a lot more annoying than it might sound - especially with checkboxes!). Getting my Microsoft joystick working hasn't been fruitful (I don't even know for sure that it's possible). It's a bit of a disappointment to successfully install your favourite game with WineX, fire it up to see the wonderful and familiar graphics, hear the emotion-stirring music, only to discover you can't click on anything or the keyboard doesn't work.
WineX is an interesting project and one I hope continues to improve. However, it only takes me a minute or two to boot into Windows and fire up something for my 'fix'. At the end of the day, I'm not too bothered if I'm gaming in Windows or Linux, as long as I get to have some fun.
Good point - that would make for a LOT of sheep. Well, I'm only going by what I heard on WW2BA$10e6, which must be true, because it's on TV.
(The actual question was something like this: 'which country has recently exceeded Australia in terms of the number of sheep per capita? Answers were China, Russia, New Zealand and USA. Now I think about it, it's ridiculous to think that China would ever have more sheep per capita than Australia. My faith in gameshows has been shattered...)
I'm not sure it would help actually...
Actually, we don't have as many sheep as we used to - from memory it's dropped from somewhere around 60 million down to only about 40 million. Australia and China have more sheep per capita now (according to Who Wants To Be A Millionaire, which is almost as good as google, but it's only on twice a week).
With our population just passing 4 million (people) that's only 10 sheep per person. We've all had to cut back on lamb roasts...
You forgot BZIP2...
Because different devices have different communications requirements, cost restrictions and intended purposes.
Maybe one day we'll have a ubiquitous communications interface that *everything* uses (we are getting closer to that all the time with USB, firewire, etc), but only when the cost becomes so low it doesn't make sense to use something slower/simpler/easier-to-write-software-for.
Oh yeah and Comedi supports a wide range of PCMCIA data acquisition cards that DO fit in a laptop.
It wasn't so much the laptop falling asleep - just having the APM code active in the kernel was doing something screwy to the interrupt handling from the NiDaq card. It would fail acquisition after 15 seconds or so (although fairly randomly).
David Schleef pointed this fix out to me after I asked him very politely about what the $#@$ was going on...
To whoever modded me 'troll' - read the story - you'll notice the first sentence is the original author's exact words. I was just pointing out that it didn't seem to make any sense to me.
I've used comedi with a National Instruments NiDAQ 16 channel acquisition card on a P3 laptop running debian - it worked very well.
However, can I offer the following advice, which may save some people from smashing their head into a bloody pulp against a wall...
* Turn off APM!!! *
You can do this by passing apm=off to the Linux kernel with your bootloader (I think - can't actually check that at the moment) if you don't want to actually remove it from the kernel (APM is useful on a laptop normally).
If you don't do this, you might find your acquisition mysteriously stalling after random intervals. It's to do with APM interrupt handling. Not sure if it's restricted to PCMCIA cards.
You've wasted a *lot* of time and effort trying to implement some simple stuff with free (and better) alternatives? Surely that beats wasting a lot of time and effort trying to implement the same things with commercial (and worse) alternatives?
I'll give you the benefit of the doubt and assume you made a slight 'grammaro'.