Telnet? Real men would use SSH instead of telnet, but they wouldn't really be real men, because real men disassemble Ubuntu on a friend's computer, read it, then type the commands in all over again on their own from memory.
Actually nearly all GPS units will not give readings above 60,000 feet.
Actually, IIRC the legislation is 60,000 feet and 500 m/s, but some lazy manufacturers take that to mean 60,000 feet or 500 m/s.
We had an application where we were going to be flying rockets at well over both those cutoffs, so we just got a whizzkid to write our own GPS decoder!
Your damned right it's expensive. Most tracking packages which _aren't_ this advanced run close to $1000 for rockets; I suspect it's possible that you could send up a cellphone with the google tracking software to get the tracking data. Don't know what the cheapest phone is that can do that. Even so, a 3lb brick with a 2m long latex streamer coming in at terminal velocity has a chance of really ruining someones day.
The tracking package on our balloons has a replacement cost of about £100 and time -- and we get realtime position data! It's all the other stuff which is expensive... the cameras, the recovery system, the balloon-launched sounding rocket...;)
Hmmm. In that case, they could just make the missiles out of cardboard and felt (like the Clangers) and nobody would be any the wiser.
Yes, that's been done. Rumour has it that a significant proportion of Russia's "active" missile silos don't actually contain anything that would ever fly.
The developers are just lazy - they don't want the hard work of managing a development tree and managing major release cycles - fine. They expect the vendors to stabilise the ABI - again, fine. But those two decisions mean that Linux will never really grow outside of the server market.
You clearly don't have a clue what you're talking about, sorry.
By the way, the Linux kernel is GPL'd. If you think that what's really needed is a Linux-like kernel with a stable in-kernel binary API for closed-source drivers, feel free to fork it -- if you're right, there's surely a lot of money to be made! You could call it Binux, because (a) Builder starts with B, (b) you will provide binary compatibility, and (c) all it will be good for is binning after you realize you've painted yourself into a corner after 6 months.
That is all nice, but the byproduct of that process is that it is a bitch to write drivers for the kernel. Since the kernel development process is seen as a role model for how to develop open source projects, others follow suit. Result? There is no consistent application stack to build against--thus supporting the amorphous pool of code that comprises your average linux distro is a very, very expensive process.
The only way out is to open source your code. Some companies are cool with that, but many are not. Clearly the WoW guys are not. If you want the WoW guys back, you'd make it easy to sell profitable applications that run on linux. However, that would require a shift in the culture and values of the entire linux ecosystem and I'm fairly positive that such a shift would never, ever, happen.
You're being slightly disingenuous here.
The kernel's userspace ABI has been fixed for several years. I can happily run applications that were compiled back in 2005 on my state-of-the-art bleeding-edge Linux kernel. Any change in the userspace ABI is a major regression. As I said, the module system is an implementation detail. I have absolutely no sympathy whatsoever for people who choose to insist on trying to maintain out-of-tree closed-source drivers in the face of the fact that it is the Wrong Thing from both a technical and legal point of view.
Keeping a constant userspace API, on the other hand, is analogous to making sure that your dynamic library's ABI doesn't change between releases of your library. Now, some library authors are very good at that, but as I've mentioned in other posts, that is very difficult to do, and requires careful planning and a lot of hard work. The way around the problem of libraries changing (as I've also mentioned elsewhere) is that if you must release your software only as binaries, you should statically link your application against the exact revisions of libraries that it requires. That approach works just fine for iD Software (c.f. Quake IV) and Introversion (c.f. Defcon): I argue that Blizzard are just making whiny pathetic excuses.
Finally, if you go down the route of, "You must maintain ABI and API compatibility!" where do you draw the line? How long should a library author be expected to maintain it for? A stable release series? A year? A decade? Forever?
Even Windows DLL authors don't manage this -- many Windows applications come bundled with the exact versions of the DLLs they require to run.
Some concrete examples of commonly-used Linux userspace libraries that have problems with this would be useful. I can't think of any established libraries with that sort of problem, off the top of my head...
There are SOOO MANY linux libraries that don't hold to this, and it pisses me the fuck off. Having to have 3 different versions of the same library installed in order to keep my applications running is a PITA and while a number of them just need symlinks, plenty of others run into broken or non-existant symbols because somebody decided 'Let's get rid of this deprecated symbol before the next MAJOR RELEASE, since people shouldn't be using it anyhow (regardless of how many ARE using it.'
As I've pointed out before, that's your fault for using shitty closed-source applications whose distributors couldn't be arsed to statically link the required libraries. That is the correct way to avoid precisely this problem, and if games developers can get it right (c.f. iD Software) I don't see why other people shouldn't get it right too.
Note that many Windows apps come with their own private versions of the DLLs they use, too.
A counter-problem is that being paranoid about breaking ABI/API can actually cause problems. The latest GLib and GTK+ libraries, for instance, have vast amounts of cruft in that has been deprecated for years (literally, in some cases), but it can't be removed because people like you (and me, as I have to support people using archaic versions of GTK) would scream. So they have to drag all this baggage, and then their library gets a reputation for being big and bloaty. It's actually a very difficult problem, and I think you ought to have a bit more sympathy for library developers -- when it comes to ABI/API compatibility, they're damned if they do, damned if the don't.
There are SOOO MANY linux libraries that don't hold to this, and it pisses me the fuck off. Having to have 3 different versions of the same library installed in order to keep my applications running is a PITA and while a number of them just need symlinks, plenty of others run into broken or non-existant symbols because somebody decided 'Let's get rid of this deprecated symbol before the next MAJOR RELEASE, since people shouldn't be using it anyhow (regardless of how many ARE using it.'
Libraries break their ABI periodically on Linux because no one really thinks about binary developers. Think about this: a deb package for Ubuntu from a release six months ago will probably not work on the next release.
Just a data point: KDE is planning to have ABI stability for the entire 4.x series -- i.e. a program compiled against KDE 4.0 should work with kdelibs 4.1, 4.2, etc. In fact, that was a stated point of the 4.0 release: to say, "This is the start of the stable KDE 4 ABI.
A project I work on, gEDA, has a shared library called libgeda that is only used by the apps in the gEDA suite. Nevertheless, we are very careful to maintain binary compatibility during a release series -- for instance, all the 1.4.x versions of libgeda are ABI-compatible. This is mostly out of deference to 3rd party app developers (I'm not sure there are any). Yes, we break our ABI -- and API -- regularly, but "regularly" is about once a year and at the start of a new stable branch.
You have to understand, though, that most developers of Linux libraries couldn't care less about closed-source -- because the vast majority of users of their libraries will use Linux distribution packages, and the distributions recompile everything anyway every release cycle, why go to the trouble to avoid some minor inconvenience to people who aren't going to contribute back to the community anyway?
But the by product of the kernel developers actions does two things:
Establishes a tone and attitude that one should randomize your API to fight off proprietary software.
2) Actually works... see also this article.
Bullshit to the first one. The logic is as follows:
We want to make the best kernel possible, and continuously improve it.
Improvement cannot happen without change, so we have to make changes.
Hey, look, by modularising the kernel we can make it easier to support lots of hardware.
Oh dear, some changes we want to make require modifications to the internal, entirely-hidden-from-userspace-code API. Oh well, a quick recompile of all the modules will fix that -- and userspace will never know the difference!
What? You can't recompile your modules? Well, if you're stupid enough to let people sell you on exploiting an implementation detail of the kernel it's your own stupid fault, isn't it? Oh, by the way, that's probably illegal, too. Jus' sayin'.
Why don't you pick up a random Linux game that was made 5 or six years ago and see if it runs on a random Linux box. Just go grab some Doom or Quake demo and put it on some random box with a different distro than the one the demo was tested against.
If you can even get the thing to install and launch, sound definitely won't work.
The original official Quake III and IV Linux binary releases still run fine on my bleeding-edge Linux box (yes, it uses PulseAudio). The same goes for Uplink, Defcon and Darwinia. Your point was what, exactly? That most studios that release game binaries for Linux are too incompetent to statically link them?
Either you're a troll, or you need to practice what you preach.
Contrast this against the stories about *nix systems where some fool runs rm -rf as admin and it only stops deleting things when it deletes the delete command itself... that is being allowed to do whatever you want.
Actually, this is a myth. Because the file isn't actually deleted until all open file pointers to it are closed, and running a program keeps a file pointer open... rm -rf/* will happily keep running *after* deleting the rm executable.
Joe Sixpack: I've heard of this new OS called Linux. Should I get it instead of Windows?
Linux guy: No, Linux is just a kernel, you can't do anything with it.
Linux guy with a clue: "Well, it's not as simple as that... believe it or not, you probably already have a computer that runs Linux, you just don't know it! You see,..."
8) a desktop based on "what do you want to do?", rather than "guess which one of the cutely named, but obscure application with far too many overly-complicated and poorly explained options, might just do half of what you want"
When click on the system menu here I get a list of applications called, 'Web Browser', 'Text Editor', 'E-mail Client', etc. This on a Fedora 10 KDE 4 desktop. I think that if I wanted to do something like take a screenshot, I might click on 'Graphics' and then 'Screenshot Capture Program'. Compare this to Windows, where if you want to carry out a task you usually have to remember which company wrote the piece of software that you intend to use.
You're either a troll or an idiot who hasn't touched a Linux workstation in years.
By the way, what would you guess each of these does from the name: Outlook, QuickTime, Skype, Safari, Excel, or Cubase?
1) Unified API for interacting with the umpteen number of desktop environments like GNOME, KDE, Englightenment, ad nauseam.
I'm not sure what you're actually asking here. Could you expand a bit?
2) Decent voice chat clients (no please do not tell me Skype Beta works in your *picked for linux* hardware)
The Skype client works just fine on my bog-standard-off-the-shelf hardware. But I agree that a free software client would be nice. Have you tried Ekiga?
3) Unified package management system.
You're making a classic mistake. Linux is an operating system kernel. Debian, Fedora, Ubuntu and SuSE are operating system distributions. Windows is an operating system distribution and an operating system kernel. You should compare Windows to Ubuntu, or compare Windows to Fedora, or compare Windows to Debian, not compare Windows to Linux. What this means is that the idea of a 'unified package management system' doesn't mean very much. Do you mean that you should be able to sit at any Linux machine and use exactly the same command set and package names to manipulate the software load? Do you mean that you should be able to take package of binaries from a vendor and install it on any Linux machine? The latter is perfectly possible, as long as the vendor statically links all of the required libraries. They can even wrap it in a nice executable install script for you. See for instance the Quake 4 installer. And if the distribution you're installing it on top of complies with the Linux Standard Base, you might even get desktop icons and file associations. But it sounds like you're pouting, stomping your foot and insisting that every distribution use <insert your favourite package management system here>. And, as far as I can tell, that will never happen: each distribution has chosen a system which suits them, and to move to a different one would require there to be a significant technical advantage to doing so. In my opinion, none of the major distributions have any glaring deficiencies in their package/repository systems today, and I don't expect them to change any time in the next 12 months at least.
4) Decent IDE for Python that does not suck balls (Anjuta, Pydev do not cut it).
Once again, complaints with no substance. What aspects of Anjuta and Pydev make them 'suck balls'? I get on very well editing my Python code in Emacs, and it works well for me.
5) Google Chrome
Why would anyone want this anyway?
6) Default system fonts that do not make you puke.
My system fonts don't make me nauseous. I doubt yours do, either. Maybe if you stated what your grievance is with the fonts, someone could explain how to fix the problem or explain why the problem can't be fixed in more detail.
Anyway, I think that's enough trollfeed for now. Feel free to return to your bridge.
Pfft. Matlab is the fastest way to connect to his testing equipment.
One of MATLAB's few redeeming features is the Instrument Control Toolbox, especially since it works well with most of the top-end Agilent/Tektronix kit. It's nice to be able to automate acquisition and analysis of instrument data from a single environment.
Sadly, I haven't yet found a tool which makes as nice EPS output as MATLAB for the purposes of embedding in my reports. Typically nowadays I do all my work in Octave, then SSH into the lab so that I can run MATLAB and generate EPS from the data...
I do actually need to learn to use R. My fiancee had to learn it for her computational statistics course last year -- that's the only reason I know about it.
This is great stuff. I'm planning on starting a PhD course in remote sensing applications with SAR in July, and I'm sure this will be fantastically useful! I was worrying about struggling with proprietary licensing (argh Matlab argh argh)... maybe this will let me avoid it.
Let me just note that anyone who honestly thinks that representing the RIAA's victims is a way to make money either (a) can't add, or (b) doesn't know how to use a calculator.
You're clearly a complete idiot. Without mathematics, chemistry and physics become meaningless qualitative handwaving. Without mathematics, it is impossible to interpret the results of an experiment, or even to demonstrate that your experiment is measuring the think that you think it's measuring.
If you think that science is in anyway separable from mathematics, I can only come to the conclusion that you know nothing of science.
Slashdot Mirror
Telnet? Real men would use SSH instead of telnet, but they wouldn't really be real men, because real men disassemble Ubuntu on a friend's computer, read it, then type the commands in all over again on their own from memory.
...in hexadecimal.
Actually nearly all GPS units will not give readings above 60,000 feet.
Actually, IIRC the legislation is 60,000 feet and 500 m/s, but some lazy manufacturers take that to mean 60,000 feet or 500 m/s.
We had an application where we were going to be flying rockets at well over both those cutoffs, so we just got a whizzkid to write our own GPS decoder!
Your damned right it's expensive. Most tracking packages which _aren't_ this advanced run close to $1000 for rockets; I suspect it's possible that you could send up a cellphone with the google tracking software to get the tracking data. Don't know what the cheapest phone is that can do that. Even so, a 3lb brick with a 2m long latex streamer coming in at terminal velocity has a chance of really ruining someones day.
The tracking package on our balloons has a replacement cost of about £100 and time -- and we get realtime position data! It's all the other stuff which is expensive... the cameras, the recovery system, the balloon-launched sounding rocket... ;)
...and we've been doing it since 2006...
*yawn*
Our technology has advanced a long way since then, too!
Hmmm. In that case, they could just make the missiles out of cardboard and felt (like the Clangers) and nobody would be any the wiser.
Yes, that's been done. Rumour has it that a significant proportion of Russia's "active" missile silos don't actually contain anything that would ever fly.
Amarok 2.x uses MySQL-embedded as the internal database. There was a big debate about it over on PlanetKDE a few months ago.
The developers are just lazy - they don't want the hard work of managing a development tree and managing major release cycles - fine. They expect the vendors to stabilise the ABI - again, fine. But those two decisions mean that Linux will never really grow outside of the server market.
You clearly don't have a clue what you're talking about, sorry.
By the way, the Linux kernel is GPL'd. If you think that what's really needed is a Linux-like kernel with a stable in-kernel binary API for closed-source drivers, feel free to fork it -- if you're right, there's surely a lot of money to be made! You could call it Binux, because (a) Builder starts with B, (b) you will provide binary compatibility, and (c) all it will be good for is binning after you realize you've painted yourself into a corner after 6 months.
That is all nice, but the byproduct of that process is that it is a bitch to write drivers for the kernel. Since the kernel development process is seen as a role model for how to develop open source projects, others follow suit. Result? There is no consistent application stack to build against--thus supporting the amorphous pool of code that comprises your average linux distro is a very, very expensive process.
The only way out is to open source your code. Some companies are cool with that, but many are not. Clearly the WoW guys are not. If you want the WoW guys back, you'd make it easy to sell profitable applications that run on linux. However, that would require a shift in the culture and values of the entire linux ecosystem and I'm fairly positive that such a shift would never, ever, happen.
You're being slightly disingenuous here.
The kernel's userspace ABI has been fixed for several years. I can happily run applications that were compiled back in 2005 on my state-of-the-art bleeding-edge Linux kernel. Any change in the userspace ABI is a major regression. As I said, the module system is an implementation detail. I have absolutely no sympathy whatsoever for people who choose to insist on trying to maintain out-of-tree closed-source drivers in the face of the fact that it is the Wrong Thing from both a technical and legal point of view.
Keeping a constant userspace API, on the other hand, is analogous to making sure that your dynamic library's ABI doesn't change between releases of your library. Now, some library authors are very good at that, but as I've mentioned in other posts, that is very difficult to do, and requires careful planning and a lot of hard work. The way around the problem of libraries changing (as I've also mentioned elsewhere) is that if you must release your software only as binaries, you should statically link your application against the exact revisions of libraries that it requires. That approach works just fine for iD Software (c.f. Quake IV) and Introversion (c.f. Defcon): I argue that Blizzard are just making whiny pathetic excuses.
Finally, if you go down the route of, "You must maintain ABI and API compatibility!" where do you draw the line? How long should a library author be expected to maintain it for? A stable release series? A year? A decade? Forever?
Even Windows DLL authors don't manage this -- many Windows applications come bundled with the exact versions of the DLLs they require to run.
Some concrete examples of commonly-used Linux userspace libraries that have problems with this would be useful. I can't think of any established libraries with that sort of problem, off the top of my head...
There are SOOO MANY linux libraries that don't hold to this, and it pisses me the fuck off. Having to have 3 different versions of the same library installed in order to keep my applications running is a PITA and while a number of them just need symlinks, plenty of others run into broken or non-existant symbols because somebody decided 'Let's get rid of this deprecated symbol before the next MAJOR RELEASE, since people shouldn't be using it anyhow (regardless of how many ARE using it.'
As I've pointed out before, that's your fault for using shitty closed-source applications whose distributors couldn't be arsed to statically link the required libraries. That is the correct way to avoid precisely this problem, and if games developers can get it right (c.f. iD Software) I don't see why other people shouldn't get it right too.
Note that many Windows apps come with their own private versions of the DLLs they use, too.
A counter-problem is that being paranoid about breaking ABI/API can actually cause problems. The latest GLib and GTK+ libraries, for instance, have vast amounts of cruft in that has been deprecated for years (literally, in some cases), but it can't be removed because people like you (and me, as I have to support people using archaic versions of GTK) would scream. So they have to drag all this baggage, and then their library gets a reputation for being big and bloaty. It's actually a very difficult problem, and I think you ought to have a bit more sympathy for library developers -- when it comes to ABI/API compatibility, they're damned if they do, damned if the don't.
There are SOOO MANY linux libraries that don't hold to this, and it pisses me the fuck off. Having to have 3 different versions of the same library installed in order to keep my applications running is a PITA and while a number of them just need symlinks, plenty of others run into broken or non-existant symbols because somebody decided 'Let's get rid of this deprecated symbol before the next MAJOR RELEASE, since people shouldn't be using it anyhow (regardless of how many ARE using it.'
As I've pointed out before, that's your fault for
Libraries break their ABI periodically on Linux because no one really thinks about binary developers. Think about this: a deb package for Ubuntu from a release six months ago will probably not work on the next release.
Just a data point: KDE is planning to have ABI stability for the entire 4.x series -- i.e. a program compiled against KDE 4.0 should work with kdelibs 4.1, 4.2, etc. In fact, that was a stated point of the 4.0 release: to say, "This is the start of the stable KDE 4 ABI.
A project I work on, gEDA, has a shared library called libgeda that is only used by the apps in the gEDA suite. Nevertheless, we are very careful to maintain binary compatibility during a release series -- for instance, all the 1.4.x versions of libgeda are ABI-compatible. This is mostly out of deference to 3rd party app developers (I'm not sure there are any). Yes, we break our ABI -- and API -- regularly, but "regularly" is about once a year and at the start of a new stable branch.
You have to understand, though, that most developers of Linux libraries couldn't care less about closed-source -- because the vast majority of users of their libraries will use Linux distribution packages, and the distributions recompile everything anyway every release cycle, why go to the trouble to avoid some minor inconvenience to people who aren't going to contribute back to the community anyway?
But the by product of the kernel developers actions does two things:
Bullshit to the first one. The logic is as follows:
Why don't you pick up a random Linux game that was made 5 or six years ago and see if it runs on a random Linux box. Just go grab some Doom or Quake demo and put it on some random box with a different distro than the one the demo was tested against. If you can even get the thing to install and launch, sound definitely won't work.
The original official Quake III and IV Linux binary releases still run fine on my bleeding-edge Linux box (yes, it uses PulseAudio). The same goes for Uplink, Defcon and Darwinia. Your point was what, exactly? That most studios that release game binaries for Linux are too incompetent to statically link them?
Either you're a troll, or you need to practice what you preach.
Contrast this against the stories about *nix systems where some fool runs rm -rf as admin and it only stops deleting things when it deletes the delete command itself... that is being allowed to do whatever you want.
Actually, this is a myth. Because the file isn't actually deleted until all open file pointers to it are closed, and running a program keeps a file pointer open... rm -rf /* will happily keep running *after* deleting the rm executable.
Joe Sixpack: I've heard of this new OS called Linux. Should I get it instead of Windows?
Linux guy: No, Linux is just a kernel, you can't do anything with it.
Linux guy with a clue: "Well, it's not as simple as that... believe it or not, you probably already have a computer that runs Linux, you just don't know it! You see, ..."
8) a desktop based on "what do you want to do?", rather than "guess which one of the cutely named, but obscure application with far too many overly-complicated and poorly explained options, might just do half of what you want"
When click on the system menu here I get a list of applications called, 'Web Browser', 'Text Editor', 'E-mail Client', etc. This on a Fedora 10 KDE 4 desktop. I think that if I wanted to do something like take a screenshot, I might click on 'Graphics' and then 'Screenshot Capture Program'. Compare this to Windows, where if you want to carry out a task you usually have to remember which company wrote the piece of software that you intend to use.
You're either a troll or an idiot who hasn't touched a Linux workstation in years.
By the way, what would you guess each of these does from the name: Outlook, QuickTime, Skype, Safari, Excel, or Cubase?
1) Unified API for interacting with the umpteen number of desktop environments like GNOME, KDE, Englightenment, ad nauseam.
I'm not sure what you're actually asking here. Could you expand a bit?
2) Decent voice chat clients (no please do not tell me Skype Beta works in your *picked for linux* hardware)
The Skype client works just fine on my bog-standard-off-the-shelf hardware. But I agree that a free software client would be nice. Have you tried Ekiga?
3) Unified package management system.
You're making a classic mistake. Linux is an operating system kernel. Debian, Fedora, Ubuntu and SuSE are operating system distributions. Windows is an operating system distribution and an operating system kernel. You should compare Windows to Ubuntu, or compare Windows to Fedora, or compare Windows to Debian, not compare Windows to Linux. What this means is that the idea of a 'unified package management system' doesn't mean very much. Do you mean that you should be able to sit at any Linux machine and use exactly the same command set and package names to manipulate the software load? Do you mean that you should be able to take package of binaries from a vendor and install it on any Linux machine? The latter is perfectly possible, as long as the vendor statically links all of the required libraries. They can even wrap it in a nice executable install script for you. See for instance the Quake 4 installer. And if the distribution you're installing it on top of complies with the Linux Standard Base, you might even get desktop icons and file associations. But it sounds like you're pouting, stomping your foot and insisting that every distribution use <insert your favourite package management system here>. And, as far as I can tell, that will never happen: each distribution has chosen a system which suits them, and to move to a different one would require there to be a significant technical advantage to doing so. In my opinion, none of the major distributions have any glaring deficiencies in their package/repository systems today, and I don't expect them to change any time in the next 12 months at least.
4) Decent IDE for Python that does not suck balls (Anjuta, Pydev do not cut it).
Once again, complaints with no substance. What aspects of Anjuta and Pydev make them 'suck balls'? I get on very well editing my Python code in Emacs, and it works well for me.
5) Google Chrome
Why would anyone want this anyway?
6) Default system fonts that do not make you puke.
My system fonts don't make me nauseous. I doubt yours do, either. Maybe if you stated what your grievance is with the fonts, someone could explain how to fix the problem or explain why the problem can't be fixed in more detail.
Anyway, I think that's enough trollfeed for now. Feel free to return to your bridge.
Pfft. Matlab is the fastest way to connect to his testing equipment.
One of MATLAB's few redeeming features is the Instrument Control Toolbox, especially since it works well with most of the top-end Agilent/Tektronix kit. It's nice to be able to automate acquisition and analysis of instrument data from a single environment.
You seem to have an axe to grind, sir. I beg leave to ask by whom you are employed?
Sadly, I haven't yet found a tool which makes as nice EPS output as MATLAB for the purposes of embedding in my reports. Typically nowadays I do all my work in Octave, then SSH into the lab so that I can run MATLAB and generate EPS from the data...
I do actually need to learn to use R. My fiancee had to learn it for her computational statistics course last year -- that's the only reason I know about it.
Suicide with a gun is extremely effective and clean (compared to with a knife).
And your point was... what, exactly?
R?
This is great stuff. I'm planning on starting a PhD course in remote sensing applications with SAR in July, and I'm sure this will be fantastically useful! I was worrying about struggling with proprietary licensing (argh Matlab argh argh)... maybe this will let me avoid it.
Let me just note that anyone who honestly thinks that representing the RIAA's victims is a way to make money either (a) can't add, or (b) doesn't know how to use a calculator.
...or, most likely, both.
Keep numerical questions for the maths exams.
You're clearly a complete idiot. Without mathematics, chemistry and physics become meaningless qualitative handwaving. Without mathematics, it is impossible to interpret the results of an experiment, or even to demonstrate that your experiment is measuring the think that you think it's measuring.
If you think that science is in anyway separable from mathematics, I can only come to the conclusion that you know nothing of science.