Why EeePC still does not fully work with Ubuntu? There is, after all, FOSS drivers for everything.
Why PeraCom USB ethernet eventually failed to work (for me)? Because it was crap and kernel developers did not (and could not) test it. And they didn't give a damn. It was FOSS, in the kernel tree.
I have had difficult time trying to install only minimal drivers for devices so that no crapware gets in. Sometimes it is very, *very* difficult, even with the devices that came with the computer.
And the crapware always, without a single exception (in my experience) has been harmful to the machine (stability, speed, memory consumption, compatibility, associated programs,...).
Linux is extremely good in this regard. Unfortunately it still lags on device support.
What if I want it rock solid and working in e.g. EeePC?
I *cannot* install one cutting edge driver into the system... or rather I can install it. And reinstall it. And reinstall it on every minor-minor kernel update.
The user can run, as explained in an e-mail, "save britney.mpg and do 'bash britney.mpg'". No matter about noxec, no matter whether firefox or thunderbird puts +x on the file, no matter what (and as we all know the virus would spread).
This was what I was complaining about originally (noexec gives very little help against viruses).
The noexec is advantageous only on hot-pluggable drives if at all (disabling executables on USB drive can be a nuisance).
Being able to run a web browser and know - for sure - that it's not been compromised by a password sniffer or the like, well, that's a useful thing and that's what TXT lets you do (when complete).
No it won't. If the said browser behaves erroneously on a particularly crafted web page the web page creator might be able (depending on the error) to take full control of the machine, e.g. by injecting remotely controllable ("telnet") Javascript applet.
For voting the TC cannot *prove* anything - again a simple overflow (either buffer or integer or...) bug can make the bot look exactly like human to the TC. TC can "prove" provided there are no bugs. Which is lame.
Practically every update of the kernel (there might have been one or two updates which did not break anything, some might not break everything, etc.). I have been only using Ubuntu lately (last two or three years), before that I used Fedora.
I hope you do not waste your time with my problems... perhaps finding out how dkms works would make more sense (solves the underlying big problem rather than some individual, small, problems).
The reactor cannot be 100% autonomous, it must be guarded against thieves (& idiots) and terrorists. Solar panel factories much less so and solar panels themselves need usually no guarding whatsoever.
Then there is the problem of logistics: the power plant needs the radioactive material - it will not appear out-of-nowhere. Transporting big amounts of radioactive material cannot be both cheap and safe (remember the idiots like greenpeace and terrorists). I do not believe it can be made 100% safe. Transporting solar panels OTOH is trivial.
After the use the plant must be decommissioned: solar panels are basically sand (silicon) and anyway easy to recycle even if the company that made them has gone tits-up. Nuclear? A lot of questions without good answers.
So comparing "nasty chemicals" in one place to very nasty radioactive materials everywhere is very, very naive.
TV cards: Artec T14BR + one for which I do not remember the model (a friend has it). There are more, the latest in linux-tv are not in the main kernel tree. Every kernel change during 2007-2008. WebCams: any gspca or spca based until very recently, still at least the one in EeePC 701. Again, the latest source is not in the kernel tree. Every kernel change during 2008. Wifi: At least the one in EeePC 701 and EeePC 900. Every kernel change during 2008. No matter whether you use ndiswrapper, madwifi or atk5 drivers - AFAIK (I do not have 100% "coverage" of all of those, but...). Ethernet: Came with some motherboard, maybe RaLink 2500 or 2x00 (another friend has so cannot check). In Linux kernel main since 2007 so the problem has gone away. At least one kernel change in early 2007. One USB 1.0 based Ethernet controller, maybe it was called "PeraComm" (throw it away as it was quite crap anyway). After update it failed and I never got it working. It *is* (or at least was) in the kernel tree, but apparently gets no testing[1]. Change of Ubuntu from 6.X to 7.X (exact Ubuntu versions long since gone from my head - thankfully). MTP008 based temperature sensors worked in 2.4.X but never in 2.6.X.
Those all were FOSS.
For proprietary there are nVidia (Ubuntu fixed this, Fedora was PITA), Xilinx parallel cable, Epson USB scanner and something which I do not remember now. All these required recompile (of the wrapper). Except because the big USB change three-four years ago the Epson was unusable for about a year.
[1] How could it as the kernel developers do not have it? (and most likely do not give a shit)
Those who do not know the history are bound to repeat it's mistakes.
(not my words)
[...] repel alien visitations.
And there went my coffee ... directly to the screen.
Thanks!
No. You forgot DRM (i.e. blueray players).
Where can I buy one?
Well ... the updates are security updates.
AAAARRGGHH!!!!!
Why EeePC still does not fully work with Ubuntu? There is, after all, FOSS drivers for everything.
Why PeraCom USB ethernet eventually failed to work (for me)? Because it was crap and kernel developers did not (and could not) test it. And they didn't give a damn. It was FOSS, in the kernel tree.
You are lucky.
I have had difficult time trying to install only minimal drivers for devices so that no crapware gets in. Sometimes it is very, *very* difficult, even with the devices that came with the computer.
And the crapware always, without a single exception (in my experience) has been harmful to the machine (stability, speed, memory consumption, compatibility, associated programs, ...).
Linux is extremely good in this regard. Unfortunately it still lags on device support.
What if I want it rock solid and working in e.g. EeePC?
I *cannot* install one cutting edge driver into the system ... or rather I can install it. And reinstall it. And reinstall it on every minor-minor kernel update.
Problem is that the kernel is not "rock solid".
But sometimes not using FOSS (or open standard file formats) is just plain stupid.
Evidence: WinRAR. What if the company goes tits-up? Can you open your archives in five years (in 64 bit environment)? How about 30 years?
I've bad news for you.
The idiocy is not limited to USA.
The user can run, as explained in an e-mail, "save britney.mpg and do 'bash britney.mpg'". No matter about noxec, no matter whether firefox or thunderbird puts +x on the file, no matter what (and as we all know the virus would spread).
This was what I was complaining about originally (noexec gives very little help against viruses).
The noexec is advantageous only on hot-pluggable drives if at all (disabling executables on USB drive can be a nuisance).
So you are implying /bin/bash is not executable?! Please!
You see, it does not matter whether foo.sh has execute bit on or not.
How does that help with "bash foo.sh"?
Besides, if everybody else is laying off too the "good" workers are less likely to work for competitor when you need them again.
They didn't patent anything ...
True.
But so can the URL content. By you, in a server of your choice.
QR code stores the data in the code itself, limiting what you can do with it.
The "data" can be an URL, vCard or phone number (or e-mail address). I'd say it is less limited than the Microsoft approach.
Hint: government is not there to make profit.
Besides every vehicle sent to space have contained some microbes. It is just too difficult to 100% sterilize space probes, etc.
Being able to run a web browser and know - for sure - that it's not been compromised by a password sniffer or the like, well, that's a useful thing and that's what TXT lets you do (when complete).
No it won't. If the said browser behaves erroneously on a particularly crafted web page the web page creator might be able (depending on the error) to take full control of the machine, e.g. by injecting remotely controllable ("telnet") Javascript applet.
For voting the TC cannot *prove* anything - again a simple overflow (either buffer or integer or ...) bug can make the bot look exactly like human to the TC. TC can "prove" provided there are no bugs. Which is lame.
Practically every update of the kernel (there might have been one or two updates which did not break anything, some might not break everything, etc.). I have been only using Ubuntu lately (last two or three years), before that I used Fedora.
I hope you do not waste your time with my problems ... perhaps finding out how dkms works would make more sense (solves the underlying big problem rather than some individual, small, problems).
Actually "chmod 775 * -R" does not work correctly. It should *not* recurse, and it won't recurse if there is a file named "--".
The reactor cannot be 100% autonomous, it must be guarded against thieves (& idiots) and terrorists. Solar panel factories much less so and solar panels themselves need usually no guarding whatsoever.
Then there is the problem of logistics: the power plant needs the radioactive material - it will not appear out-of-nowhere. Transporting big amounts of radioactive material cannot be both cheap and safe (remember the idiots like greenpeace and terrorists). I do not believe it can be made 100% safe. Transporting solar panels OTOH is trivial.
After the use the plant must be decommissioned: solar panels are basically sand (silicon) and anyway easy to recycle even if the company that made them has gone tits-up. Nuclear? A lot of questions without good answers.
So comparing "nasty chemicals" in one place to very nasty radioactive materials everywhere is very, very naive.
I think Madoff should be awarded Nobel - he has shown something no theorist could have done.
P.S. Only partly joking.
I use Ubuntu, mostly 8.04 (it is "LTS"). YMMV.
TV cards: Artec T14BR + one for which I do not remember the model (a friend has it). There are more, the latest in linux-tv are not in the main kernel tree. Every kernel change during 2007-2008. ...).
WebCams: any gspca or spca based until very recently, still at least the one in EeePC 701. Again, the latest source is not in the kernel tree. Every kernel change during 2008.
Wifi: At least the one in EeePC 701 and EeePC 900. Every kernel change during 2008. No matter whether you use ndiswrapper, madwifi or atk5 drivers - AFAIK (I do not have 100% "coverage" of all of those, but
Ethernet: Came with some motherboard, maybe RaLink 2500 or 2x00 (another friend has so cannot check). In Linux kernel main since 2007 so the problem has gone away. At least one kernel change in early 2007.
One USB 1.0 based Ethernet controller, maybe it was called "PeraComm" (throw it away as it was quite crap anyway). After update it failed and I never got it working. It *is* (or at least was) in the kernel tree, but apparently gets no testing[1]. Change of Ubuntu from 6.X to 7.X (exact Ubuntu versions long since gone from my head - thankfully).
MTP008 based temperature sensors worked in 2.4.X but never in 2.6.X.
Those all were FOSS.
For proprietary there are nVidia (Ubuntu fixed this, Fedora was PITA), Xilinx parallel cable, Epson USB scanner and something which I do not remember now. All these required recompile (of the wrapper). Except because the big USB change three-four years ago the Epson was unusable for about a year.
[1] How could it as the kernel developers do not have it? (and most likely do not give a shit)