Having it in the registry means you know where it is,
That's like saying you know where every configuration file is because it's stored somewhere under '/'.
(Although you do have a point about every program using a different syntax. Using the same syntax does really help all that much because you still have to understand the semantics of what you're changing to screw something up).
Yeah, and if you did't have a net connection to your computer, you wouldn't get viruses, trojans, or worms.
Wrongo! I can personally attest to the fact that viruses were rampant in the old Amiga days where our all our data was being moved around on diskettes. So there.
I infer from this that you'd trust any other download from BT? Why?
Firstly, what you said simply doesn't follow from what he said. Having said that, there are things you can trust to a certain degree. Example: Media files (granted they can contain malicious content designed for flaws in mp3 player apps, but if you keep your apps up-to-date it shouldn't be a problem) and some executable content. Normally, executable content can be sandboxed to a user with no rights on the system, however a Windows service pack cannot (for obvious reasons).
The was talking about logical linear addressing. Fragmentation can be handled quite easily at the memory mapping level simply by mapping consecutive logical pages to consecutive physical pages. (Or are you talking about some other form of fragmentation?)
Many people have 1GB RAM and certain current x32 OS'es cannot use more than ~900MB physical memory without slowing down quite a bit (because addressing more requires lots of trickery with the page tables and segmentation model).
(According to the Linux kernel config help it's not worth it to switch on 1GB/2GB/whatever support to address more memory unless you have at least 2GB physical RAM).
No, it is worth something. If his software wasn't secure, offering the guarantee would have been an extremely arrogant move. Guess what? DJB is extremely arrogant (as many clever people tend to be).
DJB is arguably enough of an asshole that I suspect that there are numerous people who would go out of their way to find security holes in his guaranteed software, just to spite him.
You failed to answer my point about who gets to judge the "entrants" and the rules of the contest.
Look, it's a simple matter of economics: Auditing code is mostly tedious and there are sufficiently many ways of earning much more money (and with a guaranteed payoff!) auditing code that no amount of spite is worth it.
The $500 guantee is worthless. How many hours do you think it takes to audit the djbdns source code? Anything more than 50, and you'd only need to make $10 an hour at your current job to make it a very unprofitable way to spend your time.
(Also: Who judges the "entrants" for the $500 prize? That's right, DJB does, and there are no formal rules as to exactly what qualifies as a security bug).
this page, problems remained up until (at least) BIND 8.2.2-P5. Pretty sad since this attack has been known for ages (especially since it's so easy to prevent).
The $500 security guarantee is utterly irrelevant. (Btw: Who gets to judge what is a security problem? That's right, DJB himself. If that doesn't tell you something, then you're not the sharpest tool in the shed).
The $500 correpsonds to less than 50 hours at $10 an hour (being extremely generous with the hourly wages here, in favour of the "gaurantee"). Do you think anyone can audit the djbdns source code -- even ignoring the fact that it's largely uncommented and messy (#define, what's that?) -- in 50 hours? No, I didn't think so.
BIND is open source, but that doesn't make it safe and secure. it's probobly more insecure just because of that.
BIND may be Open Source (note capitalization) while djbdns isn't. That doesn't mean you can't get source for djbdns. In fact it's probably easier to get source than binaries for djbdns because of the unbelievably stupid djbdns license.
So they are both equally "insecure" from that perspective.
but have it backwards because you don't understand how the law works
... that it is you who do not understand how patent law works. Anybody using a patented "algorithm" can be sued for patent infringement.
Furthermore, Microsoft cannot grant indemnification from patent lawsuits to their customers; only the patent holder and the government (since they grant the patent in the first place) can do that; the only thing Microsoft can do is provide patent lawsuit insurance to the buyers of their products, and I don't see them doing that any time soon -- the infringe-by-using nature of patents makes this so hideously expensive that it's basically impossible to insure against patent lawsuits.
In a MUD, you have rooms, players, weapons, monsters, items inside the rooms, items in inventories (actually that's inside the player)... it's just very natural.
My problem with this example is that
type weapon =
Sword of...
| Mace of...
|...
type item =
Weapon of weapon
| Table of...
| Chair of...
|...
type room =
(item list) * (monster list) * (...)
seems just as natural, and with pattern matching your language can automatically ensure that all cases are handled properly.
Another beef I have with OOP is the lack of symmetry. Example: If a player can take damage from a monster, where do you put the method to accomplish this? There are 2 (more if you count other classes, such as a theoretical "Turn" class) possibilities, but they each have their advantages and disadvantages, making the choice non-trivial. Sure one gets better at this with experience, but should it really be necessary? With the functional approach it's obvious, and you can unify all the common data/operations through building the types up properly.
everyone uses it, because it's all they know exists.
Or maybe they tried it and found it lacking?
And what is this fascination with OOP? The only task I can think of (please name some more if can think of any) that lends itself naturally towards OOP is GUI/Widget handling. Everything else is much better expressed using so-called "sum types" (read about ML to find out what they are) and pattern matching.
Forcing everything into the OOP way of thinking without even considering that e.g. the functional/declarative way of doing things might be better suited to some tasks is certainly not clever. So much for Ruby (and Java, but the Java people probably didn't know any better at the time).
Strong typing != Static Typing. Java and Python both have strong typing. Java also has static typing whereas Python has dynamic typing. Better for maintainability? Sure, in some circumstances... until you're forced to break the typing just to be able to have collections of (syntactically*) incompatible elements. (Note that the new generics in Java2 1.5 don't solve all the problems related to this).
(*) I.e. they don't/can't inherit from each other or implement the same interface. This happens when you don't control the source of all the classes you need to use.
Over languages like C and C++ you may add garbage collection, bounds checking, security constraints
Garbage collection: Wrong! You can add GC to C and C++ (Google for the "Boehm" garbage collector), what you cannot do is take GC out of Java.
Bounds checking in C/C++: Add a BoundsCheckedArray which supports the same operations as a native array, and you can use them almost interchangably.
The above leads me to believe that you have absolutely no idea what you're talking about or trolling.
Not all information is text based either. How do you store family photos in an easy to find manner? What directory/filename structure will allow you to quickly find the photo of daughterA at locationB taken sometime in yearC that doesn't contain ex-partnerD?
I'd go for / and just look through the 10 photos that are stored there (possibly named after the people in the photos, but I'm lazy so I usually just leave them with names like IMGXXXX.jpg), but I digress.
My question (and I believe, the original poster's) is this: If people cannot be relied upon to even provide a file name that's meaningful, what makes you think that they'll be inclined to even provide a list of the people in photos, locations, etc.? Of course, one could just be obnoxious(sp?) and require that the user provide at least 3 pieces of metadata to identify a file. Not sure how well that would work, though.
My current naming scheme is quite simple: Make sure that the path to your data contains all the metadata that you will want to search for. Then you can trivially use "locate" to find what you're looking for. Free text search in path names is actually quite powerful once you start naming files reasonably and putting the files into directory names which contain all the metadata necessary to retrieve them.
(I would love system-wide virtual folders (backed by metadata) though,...:))
The only place I see people relatively consistently using metadata is music, but that's only because they actually don't have to: Somebody's already done it for them and put the results on FreeDB or Musicbrainz...
In short: People are generally too lazy to make this work reasonably for most people. That's not to say I won't be using it. In fact, I'm quite looking forward to it.:)
The ability to undo after the fact would also complicate free space allocation (which is already quite nontrivial in file systems like Reiser4) because you'd have to find an (arbitrary) balance between: "Do we remove this file permanently" and "do we allocate some other free (but clearly suboptimal) blocks?". I.e.: There are lots of policy decisions which are usually best left to userspace.
I wrote a longer reply which got lost (bloody crashy browser), but essentially is boils down to: The semantics are unclear without expanding the traditional UNIX system calls to include more semantic details about the context of the various operations (including allowing for real transactions). Adding this would make this unreasonably slow, because most of the time it's not actually needed (only user operations on files need this support, and it's completely wasted on anything else).
For user files you can also approximate this by just using tla on your home directory (with appropriate embedded ID tags to prevent mv's from screwing up the file "tracking").
automatically map bad blocks to good blocks, but you can monitor the current number of bad blocks through SMART. If your drive is causing errors you had better stop using it (production environment or no) as quickly as possible. Bad blocks are almost always a sign of impending failure.
Jebus, do you want to run a production system on a drive with known bad blocks? Whoever hired you must be a complete moron.
Slashdot Mirror
That's like saying you know where every configuration file is because it's stored somewhere under '/'.
(Although you do have a point about every program using a different syntax. Using the same syntax does really help all that much because you still have to understand the semantics of what you're changing to screw something up).
Hands down. (Yes, there is actually a movie by that name. It's on IMDB)
Wrongo! I can personally attest to the fact that viruses were rampant in the old Amiga days where our all our data was being moved around on diskettes. So there.
Satan will be skating to work today.
Firstly, what you said simply doesn't follow from what he said. Having said that, there are things you can trust to a certain degree. Example: Media files (granted they can contain malicious content designed for flaws in mp3 player apps, but if you keep your apps up-to-date it shouldn't be a problem) and some executable content. Normally, executable content can be sandboxed to a user with no rights on the system, however a Windows service pack cannot (for obvious reasons).
So there.
Note that the quoted bit does not contain a reference to defecation or urination. What else could one possibly use toilet paper for? ;)
The graphics aren't that good.
The was talking about logical linear addressing. Fragmentation can be handled quite easily at the memory mapping level simply by mapping consecutive logical pages to consecutive physical pages. (Or are you talking about some other form of fragmentation?)
Many people have 1GB RAM and certain current x32 OS'es cannot use more than ~900MB physical memory without slowing down quite a bit (because addressing more requires lots of trickery with the page tables and segmentation model).
(According to the Linux kernel config help it's not worth it to switch on 1GB/2GB/whatever support to address more memory unless you have at least 2GB physical RAM).
I believe that's just the new colour scheme.
Guess what? DJB is extremely arrogant (as many clever people tend to be).
You failed to answer my point about who gets to judge the "entrants" and the rules of the contest.
Look, it's a simple matter of economics: Auditing code is mostly tedious and there are sufficiently many ways of earning much more money (and with a guaranteed payoff!) auditing code that no amount of spite is worth it.
The DJB license does not do that (and even prevents modified source distribution). End of story.
The $500 guantee is worthless. How many hours do you think it takes to audit the djbdns source code? Anything more than 50, and you'd only need to make $10 an hour at your current job to make it a very unprofitable way to spend your time.
(Also: Who judges the "entrants" for the $500 prize? That's right, DJB does, and there are no formal rules as to exactly what qualifies as a security bug).
this page, problems remained up until (at least) BIND 8.2.2-P5. Pretty sad since this attack has been known for ages (especially since it's so easy to prevent).
The $500 correpsonds to less than 50 hours at $10 an hour (being extremely generous with the hourly wages here, in favour of the "gaurantee"). Do you think anyone can audit the djbdns source code -- even ignoring the fact that it's largely uncommented and messy (#define, what's that?) -- in 50 hours? No, I didn't think so.
BIND may be Open Source (note capitalization) while djbdns isn't. That doesn't mean you can't get source for djbdns. In fact it's probably easier to get source than binaries for djbdns because of the unbelievably stupid djbdns license.
So they are both equally "insecure" from that perspective.
Furthermore, Microsoft cannot grant indemnification from patent lawsuits to their customers; only the patent holder and the government (since they grant the patent in the first place) can do that; the only thing Microsoft can do is provide patent lawsuit insurance to the buyers of their products, and I don't see them doing that any time soon -- the infringe-by-using nature of patents makes this so hideously expensive that it's basically impossible to insure against patent lawsuits.
to see the headlines, you silly person! :)
My problem with this example is thatseems just as natural, and with pattern matching your language can automatically ensure that all cases are handled properly.
Another beef I have with OOP is the lack of symmetry. Example: If a player can take damage from a monster, where do you put the method to accomplish this? There are 2 (more if you count other classes, such as a theoretical "Turn" class) possibilities, but they each have their advantages and disadvantages, making the choice non-trivial. Sure one gets better at this with experience, but should it really be necessary? With the functional approach it's obvious, and you can unify all the common data/operations through building the types up properly.
AAAAAAAHAHAHAH! Thanks for the laugh.
Or maybe they tried it and found it lacking?
And what is this fascination with OOP? The only task I can think of (please name some more if can think of any) that lends itself naturally towards OOP is GUI/Widget handling. Everything else is much better expressed using so-called "sum types" (read about ML to find out what they are) and pattern matching.
Forcing everything into the OOP way of thinking without even considering that e.g. the functional/declarative way of doing things might be better suited to some tasks is certainly not clever. So much for Ruby (and Java, but the Java people probably didn't know any better at the time).
(*) I.e. they don't/can't inherit from each other or implement the same interface. This happens when you don't control the source of all the classes you need to use.
Garbage collection: Wrong! You can add GC to C and C++ (Google for the "Boehm" garbage collector), what you cannot do is take GC out of Java.
Bounds checking in C/C++: Add a BoundsCheckedArray which supports the same operations as a native array, and you can use them almost interchangably.
The above leads me to believe that you have absolutely no idea what you're talking about or trolling.
I'd go for / and just look through the 10 photos that are stored there (possibly named after the people in the photos, but I'm lazy so I usually just leave them with names like IMGXXXX.jpg), but I digress.
My question (and I believe, the original poster's) is this: If people cannot be relied upon to even provide a file name that's meaningful, what makes you think that they'll be inclined to even provide a list of the people in photos, locations, etc.? Of course, one could just be obnoxious(sp?) and require that the user provide at least 3 pieces of metadata to identify a file. Not sure how well that would work, though.
My current naming scheme is quite simple: Make sure that the path to your data contains all the metadata that you will want to search for. Then you can trivially use "locate" to find what you're looking for. Free text search in path names is actually quite powerful once you start naming files reasonably and putting the files into directory names which contain all the metadata necessary to retrieve them.
(I would love system-wide virtual folders (backed by metadata) though,
The only place I see people relatively consistently using metadata is music, but that's only because they actually don't have to: Somebody's already done it for them and put the results on FreeDB or Musicbrainz...
In short: People are generally too lazy to make this work reasonably for most people. That's not to say I won't be using it. In fact, I'm quite looking forward to it.
The ability to undo after the fact would also complicate free space allocation (which is already quite nontrivial in file systems like Reiser4) because you'd have to find an (arbitrary) balance between: "Do we remove this file permanently" and "do we allocate some other free (but clearly suboptimal) blocks?". I.e.: There are lots of policy decisions which are usually best left to userspace.
I wrote a longer reply which got lost (bloody crashy browser), but essentially is boils down to: The semantics are unclear without expanding the traditional UNIX system calls to include more semantic details about the context of the various operations (including allowing for real transactions). Adding this would make this unreasonably slow, because most of the time it's not actually needed (only user operations on files need this support, and it's completely wasted on anything else).
For user files you can also approximate this by just using tla on your home directory (with appropriate embedded ID tags to prevent mv's from screwing up the file "tracking").
automatically map bad blocks to good blocks, but you can monitor the current number of bad blocks through SMART. If your drive is causing errors you had better stop using it (production environment or no) as quickly as possible. Bad blocks are almost always a sign of impending failure.
Jebus, do you want to run a production system on a drive with known bad blocks? Whoever hired you must be a complete moron.