OS/2... 1988-2002. This is shorter than Linux how?
Well, did OS/2 have any users before OS/2 2.1? Did linux have any users before Yggdrasil? Or more realistically, did OS/2 have any users before Warp 3, or linux before Slackware?
In any case, I think it's fair to say that actual users for both operating systems came at about the same time, even if OS/2 had been in development longer. That's at least what I remember, but I was an undergrad student back then, and didn't know too much about what went on in the real world, so I may be mistaken.
But OS/2 died much sooner. Sure, you can dispute that, and say that IBM never abandoned OS/2, but that didn't mean it attracted any new users. After the introduction of Windows 98 and NT, I think you could count the number of new OS/2 users on one hand. Meanwhile, linux shows no sign of stopping it's growth.
Does that answer your question?
Ohh, I love it...
on
Pentaquarks
·
· Score: 4, Funny
They have an explanation for the general public, the general scientist, and the physicist. Obviously, they care about accurate science reporting.
Since most spammers advertise and sell a product, spammer can't be anonymous. At some point you will be able to send money in one direction, and goods in another. This is not particulary hard to track.
Furthermore, spamming might be more or less legal in different jurisdictions, but you can usually get away with it. Willfully spreading viruses is not something you can get away with. Only very stupid spammers would ever try that technique (as explained in the previous paragraph, it wouldn't be particulary hard to trace the virus back to it's originator)
No why on earth would he need to defrag his diskdrive before installing linux? There are two ways of doing this, either repartition the disk drive, or you install it on a FAT partition with the VFAT file system (not really recommended but it works). None of them requires defragmentation though...
Dude. I'd hardly call $500 a month "financially crippling" somebody for life. Actually, its seems rather fair.
Well, the "crippling" part depends on your expected income. For someone at minimum wage, already struggling with monthly payments, loans, etc, that is a lot. For someone with a fat salary in some large corporation, it is almost negligible. And for people in between, it is something you will certainly feel, but will be able to live with. After five years in prison, chances are that you will end up making minimal wage.
As for the "fair" part. Well, if what has been said about the case is true, he did in deed commit a crime, and he serves five years for that. That's fair. Having to pay for potential losses for the rest of his life, in addition to his jail sentence, is not fair.
Oh yeah, I forgot about your question about overloading.
Overloading only makes sense in statically typed languages. When you have dynamic typing, the compiler can't statically determine the types of the arguments, this needs to be done at runtime (at least in the worst case, see below). The "+" function in lisp is just that, a function (although the compiler will typically inline parts of it). And you can override it (well, many implementations would disallow that for reasons of speed, but you can always use a new name, such as "add", "sum", "plus", "my+", or something similar. Since lisp uses the same syntax, whether the symbol looks like an operator, this isn't as bad as it sounds, writing (plus a b) or (add a b) is not much worse than simply writing (+ a b).
The reasoning behind not letting you override the built-in "+" is simple. "+" needs to be at least partially inlined to get good speed. Furthermore, good lisp compilers (such as cmucl, sbcl, Franz Lisp, etc) all have insanely advanced compilers that can do type-inference to analyze your code and try to find guarantees for e.g. numbers used as arguments to "+" always being fixed-size integers, thus removing any kind of run-time testing, and allowing the same speed as statically typed languages. Common Lisp has a number of primitives for adding type declarations to expressions to help the compiler in this process.
If you must insist on using the name "+", you would typically save your old "+" function under a new name, and use it to define a new function called "+" that does the appropriate thing for all kinds of arguments, including your newly defined data-type. Needless to say, this is not particulary efficient, but it's the most obvious way to do it in a dynamically typed language. If you use namespaces, you can ensure that your new enhanced "+" function will only be used in those modules that need it.
If common lisp was designed today, it would probably have a much more integrated object system, making built-in functions such as "+" being methods (some scheme implementations do this). Then, instead of overriding the fast built-in "+" to call a slow user-defined function, you would simply define new methods for "+" and your new datatype.
This means that fast things remain fast, even when you extend the meaning of "+" to new datatypes. Under the hood, this will be implemented as a fast "+" for builtin types, such as fixed-size integers, and anything else, such as complex numbers, interval arithmetic, strings, etc, going through the object system.
Adding new "slow" methods would not disturb the fast stuff, but since method lookup would typically go through a hash-table (vtables are only useful for "static" classes where you can't add new methods at runtime), it could potentially slow down other "slow" methods, but not by much, hash-tables are pretty fast regardless of size.
Unfortunately, according to the common lisp standard, "+" is a function and not a method. And typically, most implementations will fight hard to let you override it (I am not entirely sure what the standard says about it). Your best bet is to simply use a different name then "+", together with the CLOS object system. This is also more in line with the classic lisp philosophy, which often provides a "fast" function for simpler arguments, and a "slow" for more generic arguments, with different names. But ideally, we want a new funky fully object-oriented lisp.
I am not sure what python, ruby, javascript, or other more modern object-oriented scripting languages do here, but I would guess most of them allow you to do what you want (at least I'm pretty sure javascript will do the trick).
That part is easy to do in LISP, I meant that as a jibe against Java lacking operator oveloading
Well, lisp is not java:-)
Are exceptions part of LISP now though?
What do you mean?
Scheme was first created in 1975. Given that scheme had continuations from the start, I think it is quite likely that people in the lisp community had at least dabbled with exception-handling mechanisms earlier. Continuations is of course the ultimate generalization of that.
I would be very surprised to hear that either MacLisp or Interlisp (neither of which I am old enough to ever have used) did not support any kind of exception-handling mechanism. But it's possible that Lisp 1.5 missed it.
By the way, Common Lisp was standardized in 1984, and certainly supports stack unwinding and exceptions, although not general continuations, such as scheme.
So I guess LISP wins the "you can do it in LISP!" arguement, but at least not the "That's been in LISP since 1832" arguement;)
I would be very surprised to find out that people haven't done transparent interval arithmetic in lisp since the dawn of time. Remember that a large part of early development of lisp was done simply to have a better environment for building computational algebra systems such as Macsyma, Reduce, and probably others. AI also was an important part of it of course. In any case, interval arithmetic seems to be an obvious idea that I am sure many people would dabble with, given early computings emphasis on math.
Rolling back the current calculation won't give you much, the problem isn't underflow on the current operation
That is exactly why you need rollback. I never intended this to be interpreted as rollback of the current opcode, it was intended to mean rollback as far as you really needed. But I agree that I didn't write it clearly. And I should have thought more about it before writing. With side-effects, such rollbacks would soon become very tricky to implement correctly. But if you want to increase precision automatically, there is no other way to do it.
But you might not know where the problem is, or worse that there is a problem at all. Sometimes things look reasonable even when the math is all wrong.
Exactly. Accept no substitute, sometimes actual use of the brain can simplify computational problems immensely.
But now when I think about it you could create a compiler flag that converted all your doubles to doubles with max error.
Well, I don't see why we need to #define everything. But a good interval arithmetic library would be nice. Now that boost have one for C++ (haven't tried it myself), maybe people will even start using it.
precision int's are easy to implement, but this would be cleverer, and prolly impossible to do nicely in those languages.
This makes no sense. If you think you can do #define double interval_double in C/C++, I see no reason why it should be harder to do in lisp. In fact, as everything else, it should be much easier in lisp, and it has most likely also been done by lispers since at least the 1950's.
Personally I'm just waiting for the day when some cracker uploads a script like
You are not using any software written by others I presume. It's not like you can start inspecting every script inside every.deb or.rpm package before installing it. Besides, there could be evil code in the executable as well. Better examine them too. But wait, there can be unsafe build-scripts there, we need to examine them too. But wait, do we trust our compiler, make, shell, etc... We'd better check them in the same way before doing anything further, let's get the source for them too. What about the kernel then? It seems to be able to do any black magic behind our backs. Better read up on that too. And to be safe, the first version of our compiler needs to be bootstrapped from binary code I enter myself on the computer console. But wait, how can I trust that there isn't nasty stuff in whatever I use to enter and examine the binary code. And how do I know the computer itself to be safe. Maybe the bios, microcode, etc, are programmed to do nasty things. To be really safe, I need a computer designed by myself too... And that means constructed from basic gates. I don't trust those complicated microprocessor vendors to be clean. No, the only way to be safe is to start with basic gates. (I think we can stop here, building your own gates or transistors is probably not going to help increase security much anyway).
I hope you get my point. There is nothing more dangerous about running scripts from the net without revising them, then it is about running linux, without revising it. We need to have a level of trust, otherwise everyone needs to reinvent the wheel all the time. That being said, you shouldn't trust everyone. And it doesn't mean we should mistrust everything we see either. At some point, we need to decide to start trusting others. Therefore it is quite reasonable of most users to not bother checking scripts in ximian updaters before running them. Just as most users choose to trust their linux vendor by not checking all the code there before installing it on their computer.
Well, more or less. Windows has made it very easy to do insecure things. Most other operating try to focus more on security.
Consider the steps needed to do this on your average unix system: Save the attachment to your home-directory. Creating a new directory to unzip it's contents. Unzip the attachment. Set execute-permission on the executable file. Run it.
Now consider the steps needed to do this on your average windows system: Click the attachment to open it, and a new window opens up with the contents of the zip-file. Double-click the executable, and the virus runs.
It can be hard to see who exactly to blame here. Making opening attachments easy is good. Making handling of zip-files transparent is also good. Making it easy (and common) to run random executables, now that is microsofts fault. Even if winzip is not part of windows, this is exactly the user interface philosophy that windows encourages.
We have become so accustomed to clicking on random executables to do various tasks in windows, that every part of the windows user interface is geared towards making that simple. This is the main contribution of user interface design microsoft has given us. And yes, it is a bug, and it is their fault.
To me, it seems that the correct solution to all the problems is to not run any executables when you (double-)click them. Yes, that really means that if you double-click msword.exe in the proper folder on your local hard disk, it should not run!
If you want to run a program (such as word), it should be installed the proper way, with shortcuts in the proper folder on the start-menu. Or it should open as a result of clicking on a file with an associated extension (although I would prefer mime-type). Unsafe things should not be easy by default!
The windows gui has accustomed us to the opposite, but it really makes no sense. The only time we seem to need it is because of various installer programs needed for all kinds of software. This is also a bug, and should be avoided. Installers should use a common standardized package format, such as rpm, deb, or, in windows:.msi.
There should be no reason for us to pass executables around, and windows should make it really hard and cumbersome to do so. We should have user-interfaces that makes it easy to do safe things, and cumbersome to do unsafe things.
Safe and unsafe things should not be done in the same way. When I click to open a (safe).jpg attachment, it is reasonable for it to come up in a non-cumbersome way. If I click to open an (unsafe).pif file, the reasonable thing for the user interface to do is to protect me from my foolishness by doing nothing. It shouldn't ask for confirmation. It shouldn't scan it for viruses. It shouldn't do anything. Untill the.pif-file has been installed in a way that makes the GUI recognize it properly, it should be left alone.
"TLS (formerly SSL) stands for Transport Layer Security. Once this layer is established, it encrypts the communication between two hosts. If we use SMTP AUTH and the mechanisms PLAIN or LOGIN usernames and passwords are sent plaintext over the internet. This means that anyone could sniff the communication and read the passwords. If you don't want this - we bet you don't - you can use TLS to help."
Sure, this is all fine and dandy. But how does it help protect against users willfully double-clicking any executable you send them packed into a zip-file in the mail?
So, make it transparent to the user, so that the user don't need to know the difference between having stored it on the a web server and having sent it as an attachment. That should be really simple.
Then, what's the purpose?
Just sending the fucking attachment is much better for those users (the majority) that isn't permanently connected to the Internet.
if I were an idiot and opened an attachment like this on my linux system, the worst it could do is damage my home directory, the rest of the system would still be immune along with everybody elses files.
Well, I've got news for you buddy. That is all this virus needs to be damaging.
It doesn't do any damage beyond reproducing itself over the email. It doesn't need root privileges. All it needs to do is access your address book, and send itself further.
What's more. This virus doesn't really rely on insecurities in Outlook. It is sent as a zip file for christ's sake! It is safe! The only way it can spread is for a luser to open the zip-file, and double-click on the fucking virus to execute it.
So this has absolutely nothing to do with linux versus windows. Or outlook versus other mailers. All it boils down to is clueless users. And the only way to get rid of the problem is by educating the users.
I'm sure I've read about a language where there's basically one integer type, which normally maps to a typical 32- or 64-bit value on current machines, but is subject to over/underflow tests and switches to an arbitrary precision mode dynamically.
Yes, this is pretty typical in most lisp or scheme implementations (it should have been in Python too, but for some reason isn't). Testing for overflow on e.g. x86 can be done by simply testing the overflow flag. Some 20 years ago, that might have been conceived of as fast.
But in order to be able to switch to larger representation, there needs to be an if-test somewhere. And that means there is a branch instruction behind every addition. Not fast. Especially on todays pipelined processors. In other words, the documentation/propaganda you've seen is lying.
However, what you loose in speed might not be that important, because, if you are lucky, you can arrange for that test to be needed anyways. This is because, when you have dynamic typing, an if-test would be needed anyways, and if you can arrange for your integers to be in some other range than pointers, then you can specualatively add (or whatever arithmetic operation you want) two fixed size integers before having tested that they really are fixed size integers, and then do something slow only if the result isn't what you should expect.
Not sure how well the same approach would work for floating point, but if you can do it reasonably efficiently for integral types, I guess why not?
Sure, you can do something similar. But it isn't necessarily faster or better because of that.
First, we can't check for just underflow or overflow or NaN's, if what we really are interested in is precision. So if we want to test precision, we need interval arithmetic (or something similar). This is already slowing down stuff by at least a factor of two.
Second, we need no just maintain this calculated precision value. We also need to monitor it all the time. This adds a lot of if-tests, slowing down the calculation even more.
Finally, if precision is too bad, we need to be able to rollback the current calculation. Because, if we do a calculation, and find that precision is lost beyond what is acceptable, then we need to redo the whole calculation, not just the last step. I have no idea what this will cost, but it will most likely be very expensive, and certainly complex.
My guess is that these three factors combine to make the proposed scheme rather unattractive combined with simpler solutions such as just using more bits in the first place.
I tried some of the examples in these articles with Intel's Fortran Compiler and g77 and noted that some of those issue reported no longer seem valid whereas quite a few still very much are around.
Would you mind tell us what those "issues" where. Because the articles hardly deal with "issues" at all. What they deal with is the theoretic limitations that must exist in floating point, due to the fact that we have finite hardware, while real analysis assumes infinite precision. This should not have changed between 1991 and now (especially, since we have all standardized on IEEE floating point formats, but even if the article was from 1960, you should easily be able to "translate" it to your favourite floating point format (which is probably IEEE)).
Could someone, please, give me a pointer to some newer thoughts and/or new facts surrounding floating point programming.
There are very few new thoughts with regards to floating point programming, just as there are very few new thoughts on
the use of "if-then-else"-branches or "while"-loops. Floating point programming is basically a solved problem. The only problem with it is that it sometimes flies in the face of intuition, and most programmers are ignorant about it. This has not changed since 1991 either.
The articles you mentioned are very good articles for understanding issues surrounding floating point. Just make sure you read them with your brain, instead of just feeding your favourite compiler with any examples you see.
What has been improved since those articles were written?
Speed. Computers have become faster. (It's possible that there also have been some minor software improvements such as an ISO C addendum clarifying tricky areas with rounding modes, or something like that.)
What is still the same?
Essentially, nothing have changed.
How is the future, especially with the new platforms IA64 and AMD64?
Very predictable. Nothing will change there either. Non-IEEE floating point vector instructions, or "multimedia" instruction sets will probably continue to be unstandardized and platform-dependent.
I am most interested in the x86 and x86-64 architectures
There is nothing special about those architectures with respect to floating point (well, the x86 reuses its floating point registers for MMX instructions, but you shouldn't need to know that unless you use assembler).
But you cannot patent an idea without an implementation. Try actually reading beyond the title of the patent (which is always very general) to see the actual body (which is always very specific).
Back in the old days, that used to be true. But soon, the USPTO's basement became so crowded with various strange inventions and contraptions that this requirement was removed. As it stands now, the invention needs to be new, useful, and nonobvious. Nowhere is it stated that the invention must be something that the inventor can actually build and show to the patent office in a working form.
If you want to, feel free to patent teleportatition today. It might take some work to get it through the patent examiner, but I'm sure you would succeed after a while (unless it's already patented by someone else)
Why do you think it is necessary to convince the MPAA? They know full well that decss has legal uses. They just don't want it to exist, or be legal anymore, that's all!
You can propose all the anti-spam laws you want. But if you keep it restricted to one country, you won't go very far. Spammers will use other locations to send their spam from. So it only works if you have an international law.
Considering the fact that I am not from the US, and 99.999999999% of the spam I get is from the US, yes, it will help!
) Do you think that it is a good idea to trust the NSA not to put in back-door/spy-ware type code to enable them to snoop my personal information?
Yes, given that...
the NSA do not want to get caught doing it
the NSA knows that many people will be looking for such a backdoor, because finding it will mean instant fame
the code has been available for inspection quite some time now...
...I'd say, you are pretty safe!
Now, granted, a backdoor could exist, but it could equally well exist in any other distribution. If you want to be a conspiracy-theorist, there is little reason to believe they haven't already forced Linus or anyone else to accept some patches, or even installed them in gcc, as explained Ken Thompson's excellent article.
2) What other security-patched distro's can people recommend?
I have no idea. My guess would be that there are a lot more people writing security patches for linux, then there are people reviewing them, so I doubt anyone else knows much about this either. Everyone will probably recommend their own patches...:-)
The first is "Gödel, Escher, Bach: An eternal Golden Braid" by Douglas Hofstadter. If you haven't read it, it's the essential geek book, covering everything from...well the title should give you a clue... Read it! (watch the reviews
at amazon.com if you are unsure).
The second is "The Power of Myth" by Joseph Campbell, Bill Moyers, and Betty
Sue Flowers. This is also a geek book, although geared more at humanist geeks than computer geeks. It is really just one hell of a long interview with comparative mythology über-geek Joseph Campbell, who knows more about comparative mytholo
gy than, well, anyone. If you have ever wondered why it is common to celebrate marriage for example, this is the book to read. And also if you feel that modern
society must have lost something important in the process of becoming modern, and want to understand exactly what that is. Ok, it's not as good as the previous
book, but still very essential reading.
After some actual research, it seems I was at least wrong with respect to gcc. Yes, it seems to generate assembly even when not asked to, and, yes, it is I who have learning disabilities, not you.
No, I'm not. But I seem to be arguing with someone with a disability for learning.
In most C/C++ compilers, the compilation step is simply translating it to asm. Then the assembler is used to get to object code.
"Most" is a relative term. I can only think of one (lcc) C compiler that works that way, whereas most every other compiler I've heard about or used does not work that way. If you are willing to post a reasonably large list of (real-world, not student-project) compilers that verifyably works that way, I'll be willing to change my viewpoint. But anyway, gcc is not one of them.
However, to the user, compilation implies the compilation and assembly.
The user doesn't care either way. This is only of interest to nerds that have to know how everything works, or to compiler hackers.
Slashdot Mirror
Actually, the virus he talks about only works through social engineering. You have to manually open the zip file and click the .exe file.
Well, did OS/2 have any users before OS/2 2.1? Did linux have any users before Yggdrasil? Or more realistically, did OS/2 have any users before Warp 3, or linux before Slackware?
In any case, I think it's fair to say that actual users for both operating systems came at about the same time, even if OS/2 had been in development longer. That's at least what I remember, but I was an undergrad student back then, and didn't know too much about what went on in the real world, so I may be mistaken.
But OS/2 died much sooner. Sure, you can dispute that, and say that IBM never abandoned OS/2, but that didn't mean it attracted any new users. After the introduction of Windows 98 and NT, I think you could count the number of new OS/2 users on one hand. Meanwhile, linux shows no sign of stopping it's growth.
Does that answer your question?
They have an explanation for the general public, the general scientist, and the physicist. Obviously, they care about accurate science reporting.
Furthermore, spamming might be more or less legal in different jurisdictions, but you can usually get away with it. Willfully spreading viruses is not something you can get away with. Only very stupid spammers would ever try that technique (as explained in the previous paragraph, it wouldn't be particulary hard to trace the virus back to it's originator)
No why on earth would he need to defrag his diskdrive before installing linux? There are two ways of doing this, either repartition the disk drive, or you install it on a FAT partition with the VFAT file system (not really recommended but it works). None of them requires defragmentation though...
Dude. I'd hardly call $500 a month "financially crippling" somebody for life. Actually, its seems rather fair.
Well, the "crippling" part depends on your expected income. For someone at minimum wage, already struggling with monthly payments, loans, etc, that is a lot. For someone with a fat salary in some large corporation, it is almost negligible. And for people in between, it is something you will certainly feel, but will be able to live with. After five years in prison, chances are that you will end up making minimal wage.
As for the "fair" part. Well, if what has been said about the case is true, he did in deed commit a crime, and he serves five years for that. That's fair. Having to pay for potential losses for the rest of his life, in addition to his jail sentence, is not fair.
Overloading only makes sense in statically typed languages. When you have dynamic typing, the compiler can't statically determine the types of the arguments, this needs to be done at runtime (at least in the worst case, see below). The "+" function in lisp is just that, a function (although the compiler will typically inline parts of it). And you can override it (well, many implementations would disallow that for reasons of speed, but you can always use a new name, such as "add", "sum", "plus", "my+", or something similar. Since lisp uses the same syntax, whether the symbol looks like an operator, this isn't as bad as it sounds, writing (plus a b) or (add a b) is not much worse than simply writing (+ a b).
The reasoning behind not letting you override the built-in "+" is simple. "+" needs to be at least partially inlined to get good speed. Furthermore, good lisp compilers (such as cmucl, sbcl, Franz Lisp, etc) all have insanely advanced compilers that can do type-inference to analyze your code and try to find guarantees for e.g. numbers used as arguments to "+" always being fixed-size integers, thus removing any kind of run-time testing, and allowing the same speed as statically typed languages. Common Lisp has a number of primitives for adding type declarations to expressions to help the compiler in this process.
If you must insist on using the name "+", you would typically save your old "+" function under a new name, and use it to define a new function called "+" that does the appropriate thing for all kinds of arguments, including your newly defined data-type. Needless to say, this is not particulary efficient, but it's the most obvious way to do it in a dynamically typed language. If you use namespaces, you can ensure that your new enhanced "+" function will only be used in those modules that need it.
If common lisp was designed today, it would probably have a much more integrated object system, making built-in functions such as "+" being methods (some scheme implementations do this). Then, instead of overriding the fast built-in "+" to call a slow user-defined function, you would simply define new methods for "+" and your new datatype.
This means that fast things remain fast, even when you extend the meaning of "+" to new datatypes. Under the hood, this will be implemented as a fast "+" for builtin types, such as fixed-size integers, and anything else, such as complex numbers, interval arithmetic, strings, etc, going through the object system.
Adding new "slow" methods would not disturb the fast stuff, but since method lookup would typically go through a hash-table (vtables are only useful for "static" classes where you can't add new methods at runtime), it could potentially slow down other "slow" methods, but not by much, hash-tables are pretty fast regardless of size.
Unfortunately, according to the common lisp standard, "+" is a function and not a method. And typically, most implementations will fight hard to let you override it (I am not entirely sure what the standard says about it). Your best bet is to simply use a different name then "+", together with the CLOS object system. This is also more in line with the classic lisp philosophy, which often provides a "fast" function for simpler arguments, and a "slow" for more generic arguments, with different names. But ideally, we want a new funky fully object-oriented lisp.
I am not sure what python, ruby, javascript, or other more modern object-oriented scripting languages do here, but I would guess most of them allow you to do what you want (at least I'm pretty sure javascript will do the trick).
Well, lisp is not java :-)
Are exceptions part of LISP now though?
What do you mean?
Scheme was first created in 1975. Given that scheme had continuations from the start, I think it is quite likely that people in the lisp community had at least dabbled with exception-handling mechanisms earlier. Continuations is of course the ultimate generalization of that.
I would be very surprised to hear that either MacLisp or Interlisp (neither of which I am old enough to ever have used) did not support any kind of exception-handling mechanism. But it's possible that Lisp 1.5 missed it.
By the way, Common Lisp was standardized in 1984, and certainly supports stack unwinding and exceptions, although not general continuations, such as scheme.
So I guess LISP wins the "you can do it in LISP!" arguement, but at least not the "That's been in LISP since 1832" arguement ;)
I would be very surprised to find out that people haven't done transparent interval arithmetic in lisp since the dawn of time. Remember that a large part of early development of lisp was done simply to have a better environment for building computational algebra systems such as Macsyma, Reduce, and probably others. AI also was an important part of it of course. In any case, interval arithmetic seems to be an obvious idea that I am sure many people would dabble with, given early computings emphasis on math.
That is exactly why you need rollback. I never intended this to be interpreted as rollback of the current opcode, it was intended to mean rollback as far as you really needed. But I agree that I didn't write it clearly. And I should have thought more about it before writing. With side-effects, such rollbacks would soon become very tricky to implement correctly. But if you want to increase precision automatically, there is no other way to do it.
But you might not know where the problem is, or worse that there is a problem at all. Sometimes things look reasonable even when the math is all wrong.
Exactly. Accept no substitute, sometimes actual use of the brain can simplify computational problems immensely.
But now when I think about it you could create a compiler flag that converted all your doubles to doubles with max error.
Well, I don't see why we need to #define everything. But a good interval arithmetic library would be nice. Now that boost have one for C++ (haven't tried it myself), maybe people will even start using it.
precision int's are easy to implement, but this would be cleverer, and prolly impossible to do nicely in those languages.
This makes no sense. If you think you can do #define double interval_double in C/C++, I see no reason why it should be harder to do in lisp. In fact, as everything else, it should be much easier in lisp, and it has most likely also been done by lispers since at least the 1950's.
You are not using any software written by others I presume. It's not like you can start inspecting every script inside every .deb or .rpm package before installing it. Besides, there could be evil code in the executable as well. Better examine them too. But wait, there can be unsafe build-scripts there, we need to examine them too. But wait, do we trust our compiler, make, shell, etc... We'd better check them in the same way before doing anything further, let's get the source for them too. What about the kernel then? It seems to be able to do any black magic behind our backs. Better read up on that too. And to be safe, the first version of our compiler needs to be bootstrapped from binary code I enter myself on the computer console. But wait, how can I trust that there isn't nasty stuff in whatever I use to enter and examine the binary code. And how do I know the computer itself to be safe. Maybe the bios, microcode, etc, are programmed to do nasty things. To be really safe, I need a computer designed by myself too... And that means constructed from basic gates. I don't trust those complicated microprocessor vendors to be clean. No, the only way to be safe is to start with basic gates. (I think we can stop here, building your own gates or transistors is probably not going to help increase security much anyway).
I hope you get my point. There is nothing more dangerous about running scripts from the net without revising them, then it is about running linux, without revising it. We need to have a level of trust, otherwise everyone needs to reinvent the wheel all the time. That being said, you shouldn't trust everyone. And it doesn't mean we should mistrust everything we see either. At some point, we need to decide to start trusting others. Therefore it is quite reasonable of most users to not bother checking scripts in ximian updaters before running them. Just as most users choose to trust their linux vendor by not checking all the code there before installing it on their computer.
Consider the steps needed to do this on your average unix system: Save the attachment to your home-directory. Creating a new directory to unzip it's contents. Unzip the attachment. Set execute-permission on the executable file. Run it.
Now consider the steps needed to do this on your average windows system: Click the attachment to open it, and a new window opens up with the contents of the zip-file. Double-click the executable, and the virus runs.
It can be hard to see who exactly to blame here. Making opening attachments easy is good. Making handling of zip-files transparent is also good. Making it easy (and common) to run random executables, now that is microsofts fault. Even if winzip is not part of windows, this is exactly the user interface philosophy that windows encourages.
We have become so accustomed to clicking on random executables to do various tasks in windows, that every part of the windows user interface is geared towards making that simple. This is the main contribution of user interface design microsoft has given us. And yes, it is a bug, and it is their fault.
To me, it seems that the correct solution to all the problems is to not run any executables when you (double-)click them. Yes, that really means that if you double-click msword.exe in the proper folder on your local hard disk, it should not run!
If you want to run a program (such as word), it should be installed the proper way, with shortcuts in the proper folder on the start-menu. Or it should open as a result of clicking on a file with an associated extension (although I would prefer mime-type). Unsafe things should not be easy by default!
The windows gui has accustomed us to the opposite, but it really makes no sense. The only time we seem to need it is because of various installer programs needed for all kinds of software. This is also a bug, and should be avoided. Installers should use a common standardized package format, such as rpm, deb, or, in windows: .msi.
There should be no reason for us to pass executables around, and windows should make it really hard and cumbersome to do so. We should have user-interfaces that makes it easy to do safe things, and cumbersome to do unsafe things.
Safe and unsafe things should not be done in the same way. When I click to open a (safe) .jpg attachment, it is reasonable for it to come up in a non-cumbersome way. If I click to open an (unsafe) .pif file, the reasonable thing for the user interface to do is to protect me from my foolishness by doing nothing. It shouldn't ask for confirmation. It shouldn't scan it for viruses. It shouldn't do anything. Untill the .pif-file has been installed in a way that makes the GUI recognize it properly, it should be left alone.
Sure, this is all fine and dandy. But how does it help protect against users willfully double-clicking any executable you send them packed into a zip-file in the mail?
Then, what's the purpose?
Just sending the fucking attachment is much better for those users (the majority) that isn't permanently connected to the Internet.
Sure, just make sure you also doesn't become vulnerable to the old compressed 4GB of /dev/zero trick. It can really bring your mailserver down.
Well, I've got news for you buddy. That is all this virus needs to be damaging.
It doesn't do any damage beyond reproducing itself over the email. It doesn't need root privileges. All it needs to do is access your address book, and send itself further.
What's more. This virus doesn't really rely on insecurities in Outlook. It is sent as a zip file for christ's sake! It is safe! The only way it can spread is for a luser to open the zip-file, and double-click on the fucking virus to execute it.
So this has absolutely nothing to do with linux versus windows. Or outlook versus other mailers. All it boils down to is clueless users. And the only way to get rid of the problem is by educating the users.
Yes, this is pretty typical in most lisp or scheme implementations (it should have been in Python too, but for some reason isn't). Testing for overflow on e.g. x86 can be done by simply testing the overflow flag. Some 20 years ago, that might have been conceived of as fast.
But in order to be able to switch to larger representation, there needs to be an if-test somewhere. And that means there is a branch instruction behind every addition. Not fast. Especially on todays pipelined processors. In other words, the documentation/propaganda you've seen is lying.
However, what you loose in speed might not be that important, because, if you are lucky, you can arrange for that test to be needed anyways. This is because, when you have dynamic typing, an if-test would be needed anyways, and if you can arrange for your integers to be in some other range than pointers, then you can specualatively add (or whatever arithmetic operation you want) two fixed size integers before having tested that they really are fixed size integers, and then do something slow only if the result isn't what you should expect.
Not sure how well the same approach would work for floating point, but if you can do it reasonably efficiently for integral types, I guess why not?
Sure, you can do something similar. But it isn't necessarily faster or better because of that.
First, we can't check for just underflow or overflow or NaN's, if what we really are interested in is precision. So if we want to test precision, we need interval arithmetic (or something similar). This is already slowing down stuff by at least a factor of two.
Second, we need no just maintain this calculated precision value. We also need to monitor it all the time. This adds a lot of if-tests, slowing down the calculation even more.
Finally, if precision is too bad, we need to be able to rollback the current calculation. Because, if we do a calculation, and find that precision is lost beyond what is acceptable, then we need to redo the whole calculation, not just the last step. I have no idea what this will cost, but it will most likely be very expensive, and certainly complex.
My guess is that these three factors combine to make the proposed scheme rather unattractive combined with simpler solutions such as just using more bits in the first place.
Would you mind tell us what those "issues" where. Because the articles hardly deal with "issues" at all. What they deal with is the theoretic limitations that must exist in floating point, due to the fact that we have finite hardware, while real analysis assumes infinite precision. This should not have changed between 1991 and now (especially, since we have all standardized on IEEE floating point formats, but even if the article was from 1960, you should easily be able to "translate" it to your favourite floating point format (which is probably IEEE)).
Could someone, please, give me a pointer to some newer thoughts and/or new facts surrounding floating point programming.
There are very few new thoughts with regards to floating point programming, just as there are very few new thoughts on the use of "if-then-else"-branches or "while"-loops. Floating point programming is basically a solved problem. The only problem with it is that it sometimes flies in the face of intuition, and most programmers are ignorant about it. This has not changed since 1991 either.
The articles you mentioned are very good articles for understanding issues surrounding floating point. Just make sure you read them with your brain, instead of just feeding your favourite compiler with any examples you see.
What has been improved since those articles were written?
Speed. Computers have become faster. (It's possible that there also have been some minor software improvements such as an ISO C addendum clarifying tricky areas with rounding modes, or something like that.)
What is still the same?
Essentially, nothing have changed.
How is the future, especially with the new platforms IA64 and AMD64?
Very predictable. Nothing will change there either. Non-IEEE floating point vector instructions, or "multimedia" instruction sets will probably continue to be unstandardized and platform-dependent.
I am most interested in the x86 and x86-64 architectures
There is nothing special about those architectures with respect to floating point (well, the x86 reuses its floating point registers for MMX instructions, but you shouldn't need to know that unless you use assembler).
Back in the old days, that used to be true. But soon, the USPTO's basement became so crowded with various strange inventions and contraptions that this requirement was removed. As it stands now, the invention needs to be new, useful, and nonobvious. Nowhere is it stated that the invention must be something that the inventor can actually build and show to the patent office in a working form.
If you want to, feel free to patent teleportatition today. It might take some work to get it through the patent examiner, but I'm sure you would succeed after a while (unless it's already patented by someone else)
Why do you think it is necessary to convince the MPAA? They know full well that decss has legal uses. They just don't want it to exist, or be legal anymore, that's all!
Considering the fact that I am not from the US, and 99.999999999% of the spam I get is from the US, yes, it will help!
Yes, given that...
Now, granted, a backdoor could exist, but it could equally well exist in any other distribution. If you want to be a conspiracy-theorist, there is little reason to believe they haven't already forced Linus or anyone else to accept some patches, or even installed them in gcc, as explained Ken Thompson's excellent article.
2) What other security-patched distro's can people recommend?
I have no idea. My guess would be that there are a lot more people writing security patches for linux, then there are people reviewing them, so I doubt anyone else knows much about this either. Everyone will probably recommend their own patches... :-)
...that Mathematica is not a data language competing with the others at all.
The second is "The Power of Myth" by Joseph Campbell, Bill Moyers, and Betty Sue Flowers. This is also a geek book, although geared more at humanist geeks than computer geeks. It is really just one hell of a long interview with comparative mythology über-geek Joseph Campbell, who knows more about comparative mytholo gy than, well, anyone. If you have ever wondered why it is common to celebrate marriage for example, this is the book to read. And also if you feel that modern society must have lost something important in the process of becoming modern, and want to understand exactly what that is. Ok, it's not as good as the previous book, but still very essential reading.
Sorry about that. And I apologize for being rude.
No, I'm not. But I seem to be arguing with someone with a disability for learning.
In most C/C++ compilers, the compilation step is simply translating it to asm. Then the assembler is used to get to object code.
"Most" is a relative term. I can only think of one (lcc) C compiler that works that way, whereas most every other compiler I've heard about or used does not work that way. If you are willing to post a reasonably large list of (real-world, not student-project) compilers that verifyably works that way, I'll be willing to change my viewpoint. But anyway, gcc is not one of them.
However, to the user, compilation implies the compilation and assembly.
The user doesn't care either way. This is only of interest to nerds that have to know how everything works, or to compiler hackers.