Unfortunately, I have no expectations that a fully open Open Source committee will do a better job of it.
Every day, I hear from another party about all the 'great' things they wish they could do to change java. It sets my teeth on edge to hear them talk about all the vile things they want to do to my favorite language.
At least with Sun, I know where I stand. They're going to continue slowly but surely screwing up the language, but at least they'll do it slowly. The devil I know gives me maybe half a dozen more good years of coding enjoyment before things get really bad, at which point history suggests that some newer language will be grabbing the spotlight, anyway.
If the Open Source community wants to drive the evolution of a language, they should start writing their own, instead of trying to take away someone else's. That's what I'm doing.
This is a pretty poor shared secret. For one, it can easily fall prey to a simple replay attack. If you're going to turn away connections based upon them not knowing the secret handshake, you'd be better off incorporating some sort of challenge-response directly into the TCP connection handshake instead, wouldn't you?
Sticking a small cryptographically hashed payload onto the SYN, SYN_ACK and ACK packets would seem to give you better security.
Not to mention that most of the noteworthy early work on HTTP client and server implementations, on various measures of technical worth, completeness, and market penetration (ie, NCSA, Netscape, Microsoft) were all created where? That's right, in the United States.
The only code contribution from CERN, the httplib, was proof of concept at best. There was much nashing of teeth to be heard by anyone who had to work with, and more importantly, bug fix, that code.
I suspect the entire appt is done up in white on white in order to help the LEDs light things up enough so you don't trip over the coffee table. If you think the all-white decor looks dimly lit, wait until you try the same thing with a black couch and a leather armchair.
Oops. Looks like it's actually Mach 12, at 100km. Check out the pdf linked at the bottom of the page as "Hypersonic Airplane Space Tether Orbital Launch (HASTOL)"
Tethers, Inc. supposedly has a tether system design that could reach far enough down out of orbit to snatch an object moving at Mach 16 out of the upper atmosphere. I can't find the exact link, but here's the gist of the idea:
Once you go with 40+ wpm typing speed, and an editor with name/code completion, you never go back. I can't stand reading such terse crap as
#!/perl mkdir($str) unless -d $str;
What the hell does "-d" mean, anyway?
Re:walking upright
on
The Red Queen
·
· Score: 2, Interesting
In 95, the theory was that being upright helped with temperature regulation, allowing a larger brain. An upright stature presents a smaller profile to the noon-day sun, and it allows the back of the neck to open up, providing more radiative space. At some point in hominid evolution, we developed a pair of holes in the occipital lobe one on each side, where a pair of large veins emerge, allowing hot blood from the brain to cool as it travels down the back of the neck.
I don't know how the theories have changed since then.
What you're talking about is commonly known as Conceptual Integrity.
It's something that a lot of projects end up wrestling with, but community projects (open source, or otherwise), usually find themselves in trouble from word one.
Mosaic 'died' in 1997. Prior to that, it was a race to see who could steal good ideas from whom faster. Many of the innovations that were attributed to Netscape actually appeared in Mosaic first. To a much lesser extent, the reverse was also true. Since their delivery dates were frequent, and usually staggered, a feature in one browser sometimes would appear within only a couple of weeks of when it appeared in the other browser. Usually, it was NCSA that implemented them first. Many derived from just listening to the users. There was an extremely tight feedback loop between development, and the support department. QA and tech support were the same people, product design was an ephemeral group that consisted of whoever felt they should show up to the planning meetings, including some members of the support team, such as myself, and the head of Support/QA. Sometimes problems were reported as bugs, other times as feature requests, and they were reported in direct proportion to how often users were complaining.
Mostly what Netscape brought to the picture was better implementation of the same ideas (like properly nested tables, the eternal bane to Mosaic's existence). To us, everything else they did (adding proprietary tags, instead of going through the W3C, for instance) was about lock-in. We took the high ground, and of course lost, but at least we felt good about it. It -was- an NSF funded project, after all. We were getting funding pressure for competing with a commercial entity. We didn't want or need to 'win', we just wanted and needed to improve things. That was our mandate.
When Microsoft came into the picture, and NCSA bowed out, the browser war ceased being about new ideas, because Microsoft is all about parroting everybody else. There was no innovation rivalry anymore, and the well dried up. Now the only source of input was the W3C, which is not nearly as nimble as a development team that's delivering new code every 5 weeks.
> The consumers would revolt. You can only abuse the consumer so much before they will not take it any longer.
Okay, fine.
But do you really want to be one of the poor schmucks who has to live under the thumb of the proverbial King George or Louis XVI?
Things shouldn't have to get so bad that outright revolt is the driving force for change. A civilized society shouldn't have to get to the point of insanity (people taking up pitchforks and torches, running around rioting and chopping people's heads off, or hiding in the woods with muskets to ambush passing Red-Coats) before life becomes sane again.
Revolt is very impolite. People will avoid it until there are no other options left, reasonable or otherwise. And if you're a smart little dictator, you can get in and get out before the revolution comes, leaving someone else to hold the bag. Sure, punishment and retribution come, eventually, but does it give back what was taken? No.
Touch screens wear easily. They work on subtle electrical signals, which makes them highly susceptible to dirt, and liquid. Food and touchpads absolutely do not mix. And I'm not talking about smearing ketchup on your device. Put down your ice cold soda on a humid day, and there's enough moisture on your hand to drive a touchpad batshit loony.
Piezoelectric sensors, by contrast, can be internally mounted, instead of surface mounted. You can eat a hotdog, or stand outside in the pouring rain searching for you hotel on the map, and the damned thing will still work like a champ.
This disturbing trend of half of things being larger than the median size is occuring everywhere in nature. It's spreading like a plague from the field of mathematics into our everyday lives.
In fact, I recently discovered that it's also happening in the dictionary.
I saw these at the local market about a month ago, and I impulse bought one. It was a little on the watery side (in other words, the flavor wasn't terribly intense), but then that wasn't exactly the best time of year for watermelon, so it's not exactly a definitive taste test.
Sure, in most reasonable cases, static analysis can tell you that the access is safe, and so you can turn of the checks as the calling class is being resolved. If it's not clear (like due to the class version incompatibility example I mentioned above), then the check still needs to be made. But since 99% of the questionable accesses are actually going to throw an IllegalAccessException anyway, a few extra clock cycles for each of those checks is in the noise floor.
My point is, it's all amortized down to next to nothing, so you shouldn't lose any sleep over considering using such a technique.
You don't know what you're talking about, and I am unable to convince you of this, despite repeated attempts. But since I'm such a masochist, I'll try one last time. If you don't get it, that's your problem. I tried.
1) Java DOES do runtime checks. Want to see? Make two classes, one with a public member field, and the other that accesses it. Compile. Change the member field to private. Only recompile that file, not the dependent one. You'll get an exception at runtime. Try the same thing with a method instead, and you'll get similar results. Because only the VM can modify the code once it's loaded, they need only check access rights once for each call site. If it succeeds, you don't need to check again, because the relationship between the caller and the callee is fixed at class resolution time.
2) Virtually every security concern in the JDK is protected by exactly this facility, either directly by 'owning' data that the callers have no rights to, or indirectly by checking ACLs, SecurityContexts, and/or Permissions, all of which are Java Objects that are themselves protected from tampering by these facilities. Despite several false starts in coming up with a reasonable security API for the JDK, the current facilities are more than adequate. In fact, they're quite powerful, expressive, and fine-grained, as the AC peer to this response says. All security infrastructures I've ever heard of, VM or OS, pale in comparison.
You confessed earlier that you didn't know what I was talking about. Now, I guess it's my turn.
I certainly know the difference between private data and private data members. I'm aware that it's possible to design a language and VM such that all privileged data is kept apart from the user's code. Most of this isn't hardly germane to this discussion because the CLR is not such a VM (nor is the JVM).
Further, I know that it is not a 'huge overhead' to check field-level permissions at runtime - Java already does it. Read up, and maybe you'll learn something, like never to say never. Java has a security hole in this respect, sure, but that's -only- because someone decided it was necessary to provide an API call to allow trusted code to turn off access checks on a given field/method.
I'm also aware that the trend in language design is toward comparatively simpler languages and more complicated libraries, so you'd better get used to enforced data member privacy, because it's probably only going to become more common, not less.
This 'process level memory protection' which you refer to typically consists of some combination of the following:
1) One application, one OS process (OS protection facilities utilized heavily) 2) No reachability between the objects belonging to one application from those belonging to another. 3) Limited reachability between objects owned by 'the system' and those owned by a running application. 4) Runtime enforcement of 'data hiding'
For data that truly belongs to the VM itself, it's simple enough to guarantee reachability constraints. Some VMs even play tricks where data that I can see but cannot modify is protected using the OS memory protection facilities. However, when the data belongs to the libraries, then #3 normally requires #4 to implement.
Let's say there's a file (for instance, a password file) that's used by the libraries to provide my code a service, but my code is strictly forbidden from loading that file directly (because I could steal the encrypted passwords and brute force them later). Let's further say that loading and processing this file is time-consuming. Maybe it's a network resource, maybe it's a complicated file format, or maybe we access it very very frequently.
In order to use that file, some part of the system has to exceed my security priveleges in order to access it. It could get the data from an service that I cannot see, it could store a private reference to the data, or it could retrieve the data momentarily (eg, only hold it in a local variable). In this situation, retrieving the data on each request is infeasible, so the values are cached, but hidden.
If the VM does not provide truly secure data hiding (ie, protecting private data), then either
- no security-sensitive services can be provided by the libraries - those services will be horribly inefficient - those services will not be secure or, - The system uses an exotic form of reachability control (more below).
A system could be implemented that does the last option. You could, for instance, hide every class that does any real (secure) work behind a simple messenger that does nothing but pass messages to its invisible friend. You could do this, only nobody (well, nobody well-known) has. It's awkward for the designers of the libraries, especially since libraries may start life innocently, and only sprout (or identify) security issues later. Certainly Java and.Net do not employ such an approach.
Slashdot Mirror
Unfortunately, I have no expectations that a fully open Open Source committee will do a better job of it.
Every day, I hear from another party about all the 'great' things they wish they could do to change java. It sets my teeth on edge to hear them talk about all the vile things they want to do to my favorite language.
At least with Sun, I know where I stand. They're going to continue slowly but surely screwing up the language, but at least they'll do it slowly. The devil I know gives me maybe half a dozen more good years of coding enjoyment before things get really bad, at which point history suggests that some newer language will be grabbing the spotlight, anyway.
If the Open Source community wants to drive the evolution of a language, they should start writing their own, instead of trying to take away someone else's. That's what I'm doing.
This is a pretty poor shared secret. For one, it can easily fall prey to a simple replay attack. If you're going to turn away connections based upon them not knowing the secret handshake, you'd be better off incorporating some sort of challenge-response directly into the TCP connection handshake instead, wouldn't you?
Sticking a small cryptographically hashed payload onto the SYN, SYN_ACK and ACK packets would seem to give you better security.
Not to mention that most of the noteworthy early work on HTTP client and server implementations, on various measures of technical worth, completeness, and market penetration (ie, NCSA, Netscape, Microsoft) were all created where? That's right, in the United States.
The only code contribution from CERN, the httplib, was proof of concept at best. There was much nashing of teeth to be heard by anyone who had to work with, and more importantly, bug fix, that code.
Here's your thought of the day:
Advertising works, but would it be so effective (and hence, so pernicious) if it weren't a tax write-off?
Or, the company could just Open Source the server software when they EOL the game.
I suspect the entire appt is done up in white on white in order to help the LEDs light things up enough so you don't trip over the coffee table. If you think the all-white decor looks dimly lit, wait until you try the same thing with a black couch and a leather armchair.
Right. This is the legalized pyramid scheme, known as Multi-Level Marketing (MLM).
The one my high-school physics instructor used is simple enough that I still remember it after more than ten years:
One part liquid laundry starch
One part corn starch
mix well
Oops. Looks like it's actually Mach 12, at 100km.
Check out the pdf linked at the bottom of the page as "Hypersonic Airplane Space Tether Orbital Launch (HASTOL)"
Tethers, Inc. supposedly has a tether system design that could reach far enough down out of orbit to snatch an object moving at Mach 16 out of the upper atmosphere. I can't find the exact link, but here's the gist of the idea:
http://www.tethers.com/OrbitToOrbit.html
Once you go with 40+ wpm typing speed, and an editor with name/code completion, you never go back. I can't stand reading such terse crap as
#!/perl
mkdir($str) unless -d $str;
What the hell does "-d" mean, anyway?
In 95, the theory was that being upright helped with temperature regulation, allowing a larger brain. An upright stature presents a smaller profile to the noon-day sun, and it allows the back of the neck to open up, providing more radiative space. At some point in hominid evolution, we developed a pair of holes in the occipital lobe one on each side, where a pair of large veins emerge, allowing hot blood from the brain to cool as it travels down the back of the neck.
I don't know how the theories have changed since then.
What you're talking about is commonly known as Conceptual Integrity.
It's something that a lot of projects end up wrestling with, but community projects (open source, or otherwise), usually find themselves in trouble from word one.
And no worries about micrometeroid impacts shredding your gosamer sail like so much wet kleenex.
Such an impact with an M2P2 field would, of course, strip off some of your plasma, but that's what a reserve tank is for. Your 'sail' is self-healing.
Mosaic 'died' in 1997. Prior to that, it was a race to see who could steal good ideas from whom faster. Many of the innovations that were attributed to Netscape actually appeared in Mosaic first. To a much lesser extent, the reverse was also true. Since their delivery dates were frequent, and usually staggered, a feature in one browser sometimes would appear within only a couple of weeks of when it appeared in the other browser. Usually, it was NCSA that implemented them first. Many derived from just listening to the users. There was an extremely tight feedback loop between development, and the support department. QA and tech support were the same people, product design was an ephemeral group that consisted of whoever felt they should show up to the planning meetings, including some members of the support team, such as myself, and the head of Support/QA. Sometimes problems were reported as bugs, other times as feature requests, and they were reported in direct proportion to how often users were complaining.
Mostly what Netscape brought to the picture was better implementation of the same ideas (like properly nested tables, the eternal bane to Mosaic's existence). To us, everything else they did (adding proprietary tags, instead of going through the W3C, for instance) was about lock-in. We took the high ground, and of course lost, but at least we felt good about it. It -was- an NSF funded project, after all. We were getting funding pressure for competing with a commercial entity. We didn't want or need to 'win', we just wanted and needed to improve things. That was our mandate.
When Microsoft came into the picture, and NCSA bowed out, the browser war ceased being about new ideas, because Microsoft is all about parroting everybody else. There was no innovation rivalry anymore, and the well dried up. Now the only source of input was the W3C, which is not nearly as nimble as a development team that's delivering new code every 5 weeks.
> The consumers would revolt. You can only abuse the consumer so much before they will not take it any longer.
Okay, fine.
But do you really want to be one of the poor schmucks who has to live under the thumb of the proverbial King George or Louis XVI?
Things shouldn't have to get so bad that outright revolt is the driving force for change. A civilized society shouldn't have to get to the point of insanity (people taking up pitchforks and torches, running around rioting and chopping people's heads off, or hiding in the woods with muskets to ambush passing Red-Coats) before life becomes sane again.
Revolt is very impolite. People will avoid it until there are no other options left, reasonable or otherwise. And if you're a smart little dictator, you can get in and get out before the revolution comes, leaving someone else to hold the bag. Sure, punishment and retribution come, eventually, but does it give back what was taken? No.
I hoped you're enjoying your Odor Eaters Extra Odor Control shoe inserts.
Can we interest you in another pair of Dr Scholl's Lift Inserts for Short Men With Inferiority Complexes?
Isn't it about time you bought some new underwear? Those Hanes Her Ways you're wearing are 2 years old.
Touch screens wear easily. They work on subtle electrical signals, which makes them highly susceptible to dirt, and liquid. Food and touchpads absolutely do not mix. And I'm not talking about smearing ketchup on your device. Put down your ice cold soda on a humid day, and there's enough moisture on your hand to drive a touchpad batshit loony.
Piezoelectric sensors, by contrast, can be internally mounted, instead of surface mounted. You can eat a hotdog, or stand outside in the pouring rain searching for you hotel on the map, and the damned thing will still work like a champ.
This disturbing trend of half of things being larger than the median size is occuring everywhere in nature. It's spreading like a plague from the field of mathematics into our everyday lives.
In fact, I recently discovered that it's also happening in the dictionary.
This must be stopped before it's too late!
I saw these at the local market about a month ago, and I impulse bought one. It was a little on the watery side (in other words, the flavor wasn't terribly intense), but then that wasn't exactly the best time of year for watermelon, so it's not exactly a definitive taste test.
Refrigeration was invented by a German (Carl von Linde), for a German Brewery (Spaten), to chill German beer.
Sure, in most reasonable cases, static analysis can tell you that the access is safe, and so you can turn of the checks as the calling class is being resolved. If it's not clear (like due to the class version incompatibility example I mentioned above), then the check still needs to be made. But since 99% of the questionable accesses are actually going to throw an IllegalAccessException anyway, a few extra clock cycles for each of those checks is in the noise floor.
My point is, it's all amortized down to next to nothing, so you shouldn't lose any sleep over considering using such a technique.
You don't know what you're talking about, and I am unable to convince you of this, despite repeated attempts. But since I'm such a masochist, I'll try one last time. If you don't get it, that's your problem. I tried.
1) Java DOES do runtime checks. Want to see?
Make two classes, one with a public member field, and the other that accesses it. Compile. Change the member field to private. Only recompile that file, not the dependent one. You'll get an exception at runtime. Try the same thing with a method instead, and you'll get similar results. Because only the VM can modify the code once it's loaded, they need only check access rights once for each call site. If it succeeds, you don't need to check again, because the relationship between the caller and the callee is fixed at class resolution time.
2) Virtually every security concern in the JDK is protected by exactly this facility, either directly by 'owning' data that the callers have no rights to, or indirectly by checking ACLs, SecurityContexts, and/or Permissions, all of which are Java Objects that are themselves protected from tampering by these facilities. Despite several false starts in coming up with a reasonable security API for the JDK, the current facilities are more than adequate. In fact, they're quite powerful, expressive, and fine-grained, as the AC peer to this response says. All security infrastructures I've ever heard of, VM or OS, pale in comparison.
You confessed earlier that you didn't know what I was talking about. Now, I guess it's my turn.
I certainly know the difference between private data and private data members. I'm aware that it's possible to design a language and VM such that all privileged data is kept apart from the user's code. Most of this isn't hardly germane to this discussion because the CLR is not such a VM (nor is the JVM).
Further, I know that it is not a 'huge overhead' to check field-level permissions at runtime - Java already does it. Read up, and maybe you'll learn something, like never to say never. Java has a security hole in this respect, sure, but that's -only- because someone decided it was necessary to provide an API call to allow trusted code to turn off access checks on a given field/method.
I'm also aware that the trend in language design is toward comparatively simpler languages and more complicated libraries, so you'd better get used to enforced data member privacy, because it's probably only going to become more common, not less.
> I don't even know what the hell you just said.
.Net do not employ such an approach.
Then let me clarify.
This 'process level memory protection' which you refer to typically consists of some combination of the following:
1) One application, one OS process (OS protection facilities utilized heavily)
2) No reachability between the objects belonging to one application from those belonging to another.
3) Limited reachability between objects owned by 'the system' and those owned by a running application.
4) Runtime enforcement of 'data hiding'
For data that truly belongs to the VM itself, it's simple enough to guarantee reachability constraints. Some VMs even play tricks where data that I can see but cannot modify is protected using the OS memory protection facilities. However, when the data belongs to the libraries, then #3 normally requires #4 to implement.
Let's say there's a file (for instance, a password file) that's used by the libraries to provide my code a service, but my code is strictly forbidden from loading that file directly (because I could steal the encrypted passwords and brute force them later). Let's further say that loading and processing this file is time-consuming. Maybe it's a network resource, maybe it's a complicated file format, or maybe we access it very very frequently.
In order to use that file, some part of the system has to exceed my security priveleges in order to access it. It could get the data from an service that I cannot see, it could store a private reference to the data, or it could retrieve the data momentarily (eg, only hold it in a local variable). In this situation, retrieving the data on each request is infeasible, so the values are cached, but hidden.
If the VM does not provide truly secure data hiding (ie, protecting private data), then either
- no security-sensitive services can be provided by the libraries
- those services will be horribly inefficient
- those services will not be secure
or,
- The system uses an exotic form of reachability control (more below).
A system could be implemented that does the last option. You could, for instance, hide every class that does any real (secure) work behind a simple messenger that does nothing but pass messages to its invisible friend. You could do this, only nobody (well, nobody well-known) has. It's awkward for the designers of the libraries, especially since libraries may start life innocently, and only sprout (or identify) security issues later. Certainly Java and