No, although humans still have many distinct animal treats there is a difference. We have things like science, math, etc. which allows us to look into the future.
My teachers in primary school always told us that we are not that much different than animals, and that there are animals out there with better eyes, ears, noses etc.. But the biggest difference is of course the bigger, more sophisticated brain, made possible through better energy management (e.g. the diet and walking upright).
We don't call materials, crops or stock "natural" if they are specifically engineered by humans. Otherwise my television set would be a prime example of nature at its best.
You know that Adobe deliberately takes control away from the user. It's like S&W making guns without a safety. Earlier Adobe flash for instance had a pause option, but the advertisers did not like that one bit. This is true of all Adobe product. It's like that Adobe reader that has millions of settings but does have all kinds of issues with searching, selecting text or placing bookmarks.
The biggest problem with Adobe products is that they are all about Adobe, instead of the user.
This makes me realize how much I miss the early days of the internet. Everything was more "academical" and many things in it were making a mockery of the commercialized world or were just funny for being funny. Don't forget that GIMP is an old program - one where those kind of names were considered cool and were probably responsible for making the program a hit in the first place.
Are you guys insane? Capacitive screens are interesting for a single simple reason: no need to use the stylus.
And if you think that does not matter, I've used various palm devices using a stylus and the difference is just HUGE.
First of all, you don't have to worry about loosing the frickin' stylus. Second, you can control your device with one hand. Third, you don't have to get out the stylus to control the phone. Not a problem when using it continuously, but you'll notice the difference when you need to do anything fast. And last but strangely important, the dexterity of a hand it much better when it does not have to handle a tool. With a pencil you are continuously trying to get the pressure right. I've never felt that way when using the capacitive screen. Finally, my android has feedback when I press keys.
Of course, a resistive touchscreen has one very big plus: precision. Unfortunately, I'll never be able to play too many logical games on my Android without using the trackball (thanks HTC for at least including that on my Hero).
OK, that was new to me, so I'll have to retract my previous statement. When I started to read into it the suspicion was that these were copied from Harmony. My opinion was based on that "fact". As it looks now Google is in some serious trouble.
That the code was decompiled was probably suspected by most Java devs, since the variable names were clearly lost at some point. Especially the argument names are a good hint: they look a lot like the arg0-argX that are common when only the.class files are available to e.g. the Eclipse IDE. Personally I thought it was likely a lazy programmer that "skipped" one or two classes when trying to reimplement the Java interfaces.
And it could still be just that, although it is now more likely that this was a developer hired by Google.
There are many, many people using Android phones. The Android phone system is the only (relatively) open smart phone system in use. In the end, it is very likely that everybody will be using something like a smartphone. So maybe you are not looking at this deep enough.
And there are many other things; this is stiffling innovation, abusing the law system and making a mockery of IP rights in general.
If you are complaining that people are trying to find reasons to find uproar, I graciously disagree. They find issues that are important to them within their fields of interest. That's why we are reading Slashdot, and that why it is evil - within this specific field.
Complaining that a lot of people have enough time on their hands? Welcome to Slashdot (but personally, I like being on Slashdot, it's a good way to enjoy myself and you cannot be productive all of the time).
No, that's a nagging feeling. I mean that if I come home after a long days work and my body is screaming for nutrition, that kind of feeling.
What you are doing is showing me some kind of examples of extreme evil and telling me that Oracle cannot be evil because it doesn't compare.
Well, my hunger will never compare with the hunger of rather large parts of Afrika or North Korea, but that's no reason to abandon the term for everyday use.
Ignoring the feelings of millions of Java devs by going after Google does constitute evil. Being so locked up in your company culture that you cannot see the bigger consequences certainly is.
First of all, it is unlikely that Google actually programmed that part. It was probably part of Harmony.
They could have just nicely asked to reimplement the conflicting classes, instead they are trying to outmanouvre Google using lawsuits.
Personally, I would like them to supply J2ME to android on top of the Dalvic VM and Harmony so they could rake in some money from the phone manufacturers or carriers.
J2ME is not suitable for a smart phone, what the heck are they trying to accomplish here?
That's true, but the VM does not run Java byte code. So, although you are correct, the GP is as well. That it is compiled from Java source code does not change that fact.
The NX bit is only a stop gap measure. My point is that adding more security and more modularity by design is a good thing; it makes it harder to hack a system. This is also why managed code is a good thing; if you don't have access to the machine stack, you cannot attack it. The NX bit makes very little sense for interpreted languages or those running in a VM (using a separate memory space).
Yeah, well, that claim is neither in the introduction or in the conclusion. Actually, the word "impossible" does not seem to be present *anywhere* in the paper, so we may safely assume that that is another gross Slashdot overstatement (actually the article is about data access within a development model / runtime system, so you may even state that it is plain BS).
"Fabric integrates many ideas from prior work, including compile-time and run-time information flow, access control, peer-to-peer replication, and optimistic transactions. This novel integration makes possible a higher-level program- ming model that simplifies reasoning about security and con- sistency. Indeed, it does not seem possible to provide a high- level programming model like that of Fabric by simply lay- ering previous distributed systems abstractions."
Gosh, it is almost like they know that those things already existed... I know, I know, reading the article, unfair advantage.
'... you can't ever trust programmers to Do Things The Right Way"
I do development as well, and you can *bet* I don't ever trust programmers to do things the right way - including myself. The trick is to minimize exposure of the system and limit the severity of the bugs.
Java is only so so. For instance, it does offer memory protection between classes, but it is not as modularized as it should be, and you do have many mutable and non-thread safe constructs (e.g. Java byte array).
If this language can minimize security risks, I warmly welcome it. We could wait for the programmer to become bug proof, but that is like asking the user to understand OS security. It's just not going to happen (sorry).
They partition it into several pieces so that you have modular access conditions. Java is already build in such a way that you cannot directly access the hardware - you can just run byte code. Of course, there may be bugs in native libraries or in the byte code execution, but that is a rather small attack surface. Basically, that's always what you try to do; you limit the exposure of security relevant features. There will of course still be bugs, but they should be much more localized.
Building this on C++ would not make sense, since you cannot have modular security if your application logic runs in a single memory space. The only things you can do against that is trying to mitigate the fact that you *do* have access. Examples of mitigating that are the non-execute bit, random memory layouts with "no-go areas" and static analysis of code.
So sure, there may still be holes. But I may at least be sure that that bug in the TCP socket library is not exposed to the part of the code that verifies user input, or badly written code in library X.
Well, it will maybe bring down the barrier. And don't forget that insecure software costs loads of money. Maybe not in front then certainly later during the maintenance cycle. Of course, if you are able to charge for maintenance hours, you may be in luck.
Secure software may make a lot of sense for core security components. Proving that something is secure can be hard, any software that will bring that cost down is very welcome. If this is required depends on the type of software of course.
Yes, and it does not prevent burglary either. If you mess up the transport & application protocol you are in trouble, but what has that to do with secure *programming*? Christ, I bet you can make programs with it that display your password in 10 feet high numbers as well (given a large enough monitor).
And of course, there are a lot of carriers that *do* allow you to install new firmware. I've had no problem with my carrier anyway. And as long as I don't mess up their infrastructure, they'll probably be fine with that.
Yeah, that stupid green community, always looking for their own interest. Lets not do anything or follow any logic, since they don't care about us anyway. Why do the apologist capitalists always try and project their own defects onto the people that actually try and change the world for the better?
"Their primary concern is to cause humans to stop using fossil fuels."
Slashdot Mirror
Absolutely, can't see any issue with jet powered individuals flying over crowded areas.
No, although humans still have many distinct animal treats there is a difference. We have things like science, math, etc. which allows us to look into the future.
My teachers in primary school always told us that we are not that much different than animals, and that there are animals out there with better eyes, ears, noses etc.. But the biggest difference is of course the bigger, more sophisticated brain, made possible through better energy management (e.g. the diet and walking upright).
We don't call materials, crops or stock "natural" if they are specifically engineered by humans. Otherwise my television set would be a prime example of nature at its best.
You know that Adobe deliberately takes control away from the user. It's like S&W making guns without a safety. Earlier Adobe flash for instance had a pause option, but the advertisers did not like that one bit. This is true of all Adobe product. It's like that Adobe reader that has millions of settings but does have all kinds of issues with searching, selecting text or placing bookmarks.
The biggest problem with Adobe products is that they are all about Adobe, instead of the user.
No need to explain the dish, just point out that you can find any nearby IKEA using Google maps :)
This makes me realize how much I miss the early days of the internet. Everything was more "academical" and many things in it were making a mockery of the commercialized world or were just funny for being funny. Don't forget that GIMP is an old program - one where those kind of names were considered cool and were probably responsible for making the program a hit in the first place.
Now, GET OFF MY LAWN, or I'll BASH you!
Are you guys insane? Capacitive screens are interesting for a single simple reason: no need to use the stylus.
And if you think that does not matter, I've used various palm devices using a stylus and the difference is just HUGE.
First of all, you don't have to worry about loosing the frickin' stylus.
Second, you can control your device with one hand.
Third, you don't have to get out the stylus to control the phone. Not a problem when using it continuously, but you'll notice the difference when you need to do anything fast.
And last but strangely important, the dexterity of a hand it much better when it does not have to handle a tool. With a pencil you are continuously trying to get the pressure right. I've never felt that way when using the capacitive screen.
Finally, my android has feedback when I press keys.
Of course, a resistive touchscreen has one very big plus: precision. Unfortunately, I'll never be able to play too many logical games on my Android without using the trackball (thanks HTC for at least including that on my Hero).
OK, that was new to me, so I'll have to retract my previous statement. When I started to read into it the suspicion was that these were copied from Harmony. My opinion was based on that "fact". As it looks now Google is in some serious trouble.
That the code was decompiled was probably suspected by most Java devs, since the variable names were clearly lost at some point. Especially the argument names are a good hint: they look a lot like the arg0-argX that are common when only the .class files are available to e.g. the Eclipse IDE. Personally I thought it was likely a lazy programmer that "skipped" one or two classes when trying to reimplement the Java interfaces.
And it could still be just that, although it is now more likely that this was a developer hired by Google.
There are many, many people using Android phones. The Android phone system is the only (relatively) open smart phone system in use. In the end, it is very likely that everybody will be using something like a smartphone. So maybe you are not looking at this deep enough.
And there are many other things; this is stiffling innovation, abusing the law system and making a mockery of IP rights in general.
If you are complaining that people are trying to find reasons to find uproar, I graciously disagree. They find issues that are important to them within their fields of interest. That's why we are reading Slashdot, and that why it is evil - within this specific field.
Complaining that a lot of people have enough time on their hands? Welcome to Slashdot (but personally, I like being on Slashdot, it's a good way to enjoy myself and you cannot be productive all of the time).
No, that's a nagging feeling. I mean that if I come home after a long days work and my body is screaming for nutrition, that kind of feeling.
What you are doing is showing me some kind of examples of extreme evil and telling me that Oracle cannot be evil because it doesn't compare.
Well, my hunger will never compare with the hunger of rather large parts of Afrika or North Korea, but that's no reason to abandon the term for everyday use.
Ignoring the feelings of millions of Java devs by going after Google does constitute evil. Being so locked up in your company culture that you cannot see the bigger consequences certainly is.
Uh, that's not the OpenJDK license, that is the Oracle Java license.
This is pure evil from Oracle.
First of all, it is unlikely that Google actually programmed that part. It was probably part of Harmony.
They could have just nicely asked to reimplement the conflicting classes, instead they are trying to outmanouvre Google using lawsuits.
Personally, I would like them to supply J2ME to android on top of the Dalvic VM and Harmony so they could rake in some money from the phone manufacturers or carriers.
J2ME is not suitable for a smart phone, what the heck are they trying to accomplish here?
Ah, you must be one of those people that tell me I cannot be hungry because so many people are starving.
That's true, but the VM does not run Java byte code. So, although you are correct, the GP is as well. That it is compiled from Java source code does not change that fact.
The NX bit is only a stop gap measure. My point is that adding more security and more modularity by design is a good thing; it makes it harder to hack a system. This is also why managed code is a good thing; if you don't have access to the machine stack, you cannot attack it. The NX bit makes very little sense for interpreted languages or those running in a VM (using a separate memory space).
Yeah, well, that claim is neither in the introduction or in the conclusion. Actually, the word "impossible" does not seem to be present *anywhere* in the paper, so we may safely assume that that is another gross Slashdot overstatement (actually the article is about data access within a development model / runtime system, so you may even state that it is plain BS).
"Fabric integrates many ideas from prior work, including
compile-time and run-time information flow, access control,
peer-to-peer replication, and optimistic transactions. This
novel integration makes possible a higher-level program-
ming model that simplifies reasoning about security and con-
sistency. Indeed, it does not seem possible to provide a high-
level programming model like that of Fabric by simply lay-
ering previous distributed systems abstractions."
Gosh, it is almost like they know that those things already existed... I know, I know, reading the article, unfair advantage.
'... you can't ever trust programmers to Do Things The Right Way"
I do development as well, and you can *bet* I don't ever trust programmers to do things the right way - including myself. The trick is to minimize exposure of the system and limit the severity of the bugs.
Java is only so so. For instance, it does offer memory protection between classes, but it is not as modularized as it should be, and you do have many mutable and non-thread safe constructs (e.g. Java byte array).
If this language can minimize security risks, I warmly welcome it. We could wait for the programmer to become bug proof, but that is like asking the user to understand OS security. It's just not going to happen (sorry).
They partition it into several pieces so that you have modular access conditions. Java is already build in such a way that you cannot directly access the hardware - you can just run byte code. Of course, there may be bugs in native libraries or in the byte code execution, but that is a rather small attack surface. Basically, that's always what you try to do; you limit the exposure of security relevant features. There will of course still be bugs, but they should be much more localized.
Building this on C++ would not make sense, since you cannot have modular security if your application logic runs in a single memory space. The only things you can do against that is trying to mitigate the fact that you *do* have access. Examples of mitigating that are the non-execute bit, random memory layouts with "no-go areas" and static analysis of code.
So sure, there may still be holes. But I may at least be sure that that bug in the TCP socket library is not exposed to the part of the code that verifies user input, or badly written code in library X.
That is maybe, but *you* don't.
Of course, security is about secure systems and this programming language won't fill all the gaps, but you hardly have to remind Slashdot of that.
But maybe I'm confused and you have an interesting point to bare?
Well, it will maybe bring down the barrier. And don't forget that insecure software costs loads of money. Maybe not in front then certainly later during the maintenance cycle. Of course, if you are able to charge for maintenance hours, you may be in luck.
Secure software may make a lot of sense for core security components. Proving that something is secure can be hard, any software that will bring that cost down is very welcome. If this is required depends on the type of software of course.
Yes, and it does not prevent burglary either. If you mess up the transport & application protocol you are in trouble, but what has that to do with secure *programming*? Christ, I bet you can make programs with it that display your password in 10 feet high numbers as well (given a large enough monitor).
Wow, I knew these stones are big, but I never thought you could drive through it.
And of course, there are a lot of carriers that *do* allow you to install new firmware. I've had no problem with my carrier anyway. And as long as I don't mess up their infrastructure, they'll probably be fine with that.
Yeah, that stupid green community, always looking for their own interest. Lets not do anything or follow any logic, since they don't care about us anyway. Why do the apologist capitalists always try and project their own defects onto the people that actually try and change the world for the better?
"Their primary concern is to cause humans to stop using fossil fuels."
FUD I tell you.
Actually, it is a somewhat customized version of LDAP as well, as far as I've seen. Usable, but certainly not without its quirks.