The hacker controlled/malicious browser simply morphs the incoming JS as it comes off the wire (e.g. a filter on the socket data) to do whatever is necessary to bypass any real security check and return the "I am safe" result.
It could (e.g.) simply reverse the sense of: if (bad_security_here())...
Into: if (! bad_security_here())...
Or, do whatever else is necessary to nullify the security check.
Client side security checks are largely meaningless! If you control the browser, you can hack it any way you want, and you control what the JS does/can do.
A native app might be harder to morph, but, ultimately, the same technique can be applied [by patching binary bytes] to nullify the security checks.
They are only useful as a "health checkup" for a legitimate user's browser. But, Google's stated goal was:
The reason is that Google uses JavaScript to run risk assessment checks on the users accessing the login page, and if JavaScript is disabled, this allows crooks to pass through those checks undetected.
As I mentioned above, [real] crooks can easily get around this, so this is faux security at best.
At worst [as others have mentioned], foisting Javascript on users that do not want it, opens a gigantic Pandora's box of security holes for other sites that might download malicious javascript code.
There is one small advantage to having a PDF viewer in the browser, but it's a [beneficial] side effect for a missing browser feature.
If you do a google search for something and on the results page is a link to a PDF, the link _isn't_ a direct link to the final PDF file. It's a "result" link that actually points to google (e.g. google?url?sa=t&foo=bar). It redirects when you actually click on it. So, if you right click and select "copy link location", you'll get the link pointing to google and not the final site URL.
For ordinary site links, you just click on the search page link and when you land you have the final link in the page URL, which you can bookmark, copy, etc.
For PDFs, if your action is to run Adobe Reader, it will download the PDF but it loses the sense of the final link. With the embedded viewer, the final link is available in the viewer window's URL, just like an ordinary web page.
Firefox can't establish a connection to the server at krebsonsecurity.com.
The site could be temporarily unavailable or too busy. Try again in a few moments.
If you are unable to load any pages, check your computer's network connection.
If your computer or network is protected by a firewall or proxy, make sure that Firefox is permitted to access the Web.
Actually, IIRC, they didn't copy the signatures. When you build an android app, you use Oracle's JDK [and/or openJDK or some such] and get the signatures from that. Just like if you were using the JDK to create your own Java [non-Android] app. Otherwise, anybody writing Java code would be in the same boat.
Oracle has a copyright on the API. Oracle was trying to convert this to a "patent" on it. If Oracle had a patent [which they can't get], then Google would not have been able to create the underlying [Dalvik] from scratch re-implementation of the JVM.
If Oracle had won here, ironically, they would have had to open source the code to their database software. They port to Linux and it had GPL v2 [as does glibc, etc.]. Also, they use C, and the ISO C spec has a copyright.
If Oracle had won, anyone writing a C program would have had to make a royalty payment to ISO.
Further, the stdio.h that comes with glibc has a copyright. That doesn't prevent BSD from creating their own stdio.h [they are both built from scratch, even if they both define similar things to implement the POSIX specifications]. Actually, if Oracle had prevailed, all Linux implementations, gcc, glibc would be shut down because POSIX [specs] could never have existed. POSIX specs were a "clean room" reimplementation of the _specifications_ of interfaces and programs that had copyrights (i.e. AT&T had copyrights on the _Unix_ man pages for open/close/read/write and other system calls and utilities like ls/df/du, etc.)
What can a site do? Run a script to detect an ad blocker? Suggest a monthly payment and block the page from that user or request the ad block is removed?
Wired http://www.wired.com/ has started doing that and I've started not visiting their site, even though I whitelisted them so I could do it for free. Screw them...
On the other hand, Stack Overflow https://stackoverflow.com/ has stated publicly that they are fine with ad blockers. Their reasoning is that if you're running one, you don't want ads, and wouldn't click on any if you saw them.
I've been on slashdot for years and just started with stackoverflow/stackexchange three months ago. I did about five other posts here and they're somewhat based on my SO experiences. SO's code is proprietary, but they also base it on markdown. Maybe cut a deal?
Adopt a reputation system similar to stackexchange. Right now, _everybody_ [who has been on slashdot for any length of time] gets posts started at +2.
The highest a post can is +5.
But, why not allow posts starting at +10 for users who have earned that by having a history of making good posts
Allow anyone with sufficient reputation to be able to cast unlimited votes [ala reddit or stackexchange]. The same rules should apply. If you post on a given page, your moderation doesn't count.
Ironically, of late, when I have mod points to use, I can't seem to find a page I wish to moderate [or feel qualified to do so]. When I _don't_ have mod points, I find pages I _would_ like to moderate.
Moderation should _not_ be completely anonymous. If a person upvotes/downvotes, anybody should be able to agree/disagree. This is like fine tuned metamoderation and the result should accrue to the moderator's reputation in some fashion.
Users should also be able to moderate as to whether the post is on topic or not. The post may be brilliant, insightful, etc. but not really related to the TFA. So, how about "on topic"/"off topic" votes.
This should have gone in my other post: http://ask.slashdot.org/commen... but how about allowing users to sort posts dynamically based on different criteria for each page
Provide the ability to edit posts [possibly for a fixed period of time, say 5-10 minutes]. The edits should be discoverable by anyone (e.g. "show older versions" button). And/or allow the ability to _append_ to posts.
There are many scenarios where a poster forgets some trivial detail and posts [it happens a lot]. They reply to their own post with a correction. This adds to clutter. Also, many repliers never see such corrections and the poster gets hammered based solely on the first message, even though they've already done their "mea culpa".
Also, someone who is quite knowledgeable about a given topic may not be able to provide all the relevant knowledge they have in a single sitting. They may wish to trim one post, reorganize it, to make things more clear, without having to do a separate post [which probably won't be seen anyway].
Right now, slashdot is _just_ a chat room of sorts. Except for the links to the TFA, there is no long term value to the thread posts. Very few people will revisit a slashdot page, looking for reference material. Even the "ask slashdot: how do I handle this situation?" pages that can have a lot of useful advice [and do not have a TFA] are difficult to use for that purpose.
Right now you can only set a message visibility level based on score for your entire account.
On a given page, usually the first posted threads are _long_ and usually off-topic to TFA [or drift that way quickly]. This is more prevalent the more difficult the [scientific] topic is. Fewer people understand it, but still want to post.
For example, a post about a discovery at CERN might generate a long thread about the merits of government funding of research. Fair enough. But, for someone looking for a discussion of the true scientific data, etc. would have to scroll through all that. That's a lot of work to get to the more germane posts/threads that usually appear nearer the bottom of the page.
How about a collapse/expand button on _each_ message that will collapse/expand [expose/hide] everything under it.
This would help reduce the effect of the "early posters" that "shanghai" a page with topics that are only obliquely connected with the central topic of a given page.
Now, I'm _not_ against oblique threads. Some are actually interesting. If people wish to reply under these, all to the good.
But, we should give users more ability to filter out the threads they're _not_ interested in reading, or more importantly, scrolling over to get to the threads they _are_ interested in.
On stackexchange, any user can see upvotes/downvotes/comments/etc within 10 minutes [automatically updated on the top bar]. No waiting a day or two to see replies, comment moderation, etc.
Require all ACs to have a valid login [or have a way to differentiate them internally].
On a given page, the first AC poster is known as AC#1. The AC second poster [if different] is AC#2. And, so on...
That way, we can see if different ACs are having a conversation [which is fine], or we just have one AC running amok and creating a phony conversation with themselves, just to stir things up.
On another page, the numbers start from 1 (i.e. _no_ correlation between AC#1 on page X and AC#1 on page Y).
This preserves anonymity but also gives a particular page more sanity. It might cut down on the anonymous trolling that seems to have taken over Slashdot.
Several AC's replied to me about speed of light being [roughly] one foot per nanosecond [which I had forgotten]. So, 13.7 us is 13,700 ns, or 13,700 feet, or 2.5 miles [just as you said]. Wow! I know that GPS receivers [try to] use several satellites. Can they compensate for this without an almanac update [automatic or manual]? Or, if they use the faulty one, what happens? Would they try to average it in or reject it as too far off the average of the others?
The time discrepancy is 13.7 microseconds [not milliseconds]. I don't know how that translates to position accuracy, but, to me, even that seems a bit large for something derived from an atomic clock.
After the stagefright bug, Google implemented a "rapid response" update system (i.e.) older systems could get security fix updates [but not necessarily feature enhancements]. This preserves the market for new devices but allows older ones to remain secure.
Google rolled this out to its various vendors (e.g. Samsung, Moto, etc.). Several of them have pledged to honor this. Thus, I recently got an OTA [security] update from Samsung for my Galaxy S3 [that was EOL] to fix stagefright.
There was a bit of NRE to put this in place by Google [and the vendors]. Now, I expect, that it should be fairly easy to publish security updates even for older phones.
It's in everybody's best interests to do so. Vendors don't lose the market for new phones. They don't lose market share due to EOL security concerns anymore (e.g. people switch to iPhone simply because Apple can/could publish the security updates anytime). What was an Apple advantage is not one anymore.
Did you do this with fedup? From what I could see, it was possible [despite the dire warnings from fedora about "don't do it"].
And, I've edited grub.cfg to remove "quiet" and "rhgb" not so much because of aesthetics, but because my graphics card was having issues with some versions of the nouveau driver.
I just got an OTA update that fixed the stagefright vuln for my [Boost] Galaxy S3. AFAICT, it was [mostly] just security fixes, which is fine.
IMO, Google had to create the tools for the "rapid response" updates, which they did. Now, [IMO smart] vendors like Moto, Samsung, et. al. are beginning to use them.
As a computer engineer myself, I use git. I know how relatively easy it is to apply source patches to older tree branches using it. Since git is at the core of Android source tree development, this is also easy to do. Google just had to package this up as a release system.
This works for everybody: Consumers, vendors, and telcos. It improves the brand quality/loyalty. I really like Android, but the prospect of "being left behind" on security fixes was beginning to make me think [reluctantly] about Apple/iPhone/iOS because of the security update issue.
It also can address the "fragmentation" issue, if the monthly updates add some forward compatibility libraries. Apps crashing because they were built for Android version N, when I only have N-x. I don't mind a few feature restrictions, because that's better than outright freeze/crash/lockup/etc. necessitating a reboot.
If I _had_ to write python, for some reason, I'd probably write a little pre-compiler to take something maintainable that I'd write and output whitespace-tokenized python.
Google has been working on Dart [has its own VM which is more efficient, but can cross-compile to the JVM]. But, Dart hasn't caught on quite the way they hoped. And, then there's Scala... And, I do believe perl6 can [or will] compile to the JVM.
They could also migrate away from the JVM since they [sort of] do already by doing JIT conversion to dex format [which is a "general purpose register" model rather than a "stack machine" model, IIRC].
This gets done when a new APK is installed. Also, when my Galaxy S3 gets a firmware update, after the 2nd auto-reboot, it goes through an "optimizing apps" phase for all my installed apps [the dex conversion, AFAICT]. This could be extended to translate legacy binary API calls to whatever they come up with. For new development, developers just use the new API definition files [which sidestep the alleged copyright issue]
No, I'm looking at all job mixes. Ripping through a large array is going to be memory bound. Business code will benefit more from 64 bit.
When you do a function call in 32 bit, you have to calculate the argument values, then do pushes to the stack. In 64 bit, you put them directly into the correct registers. The optimizer is usually good enough to do the calculation directly on the target register (e.g. it doesn't calc the value in %rax and then move it to %rXX--it does the calc directly on %rXX). So, for four arguments, you save four push instructions, not to mention storing the the cache/dram. Further, if some of the args are just passed along: fncA(a,b,c,d) {...
fncB(a,b,7,9) }
The a/b values are simply already in the correct regs, so you skip two fetches and two pushes.
Once again, the extra regs allow the exec unit to see the parallelism available. This can be [and is] applied to almost every five instruction sequence in any function.
Oh, forgot to mention the RIP relative addressing advantage when generating PIC (position independent code). In 64 bit, address calculation is done relative to the %rip (program counter) register. This is wonderful for shared libraries (e.g..so's,.dll's) which are built using PIC. In 32 bit, you have to burn the %ebx register to have a base register to address from. So, the available register count dwindles by one.
Speculative execution. If you have a sequence like:
inst1
inst2
inst3
inst4
test...
bnz value_nonzero value_is_zero:
inst5
inst6...
b elsewhere
value_is_nonzero:
inst20
inst21...
The execution unit may execute both pathways simultaneously [speculatively] (e.g. either the branch is taken or not). The exec unit may not have enough info to decide the branch (e.g. the data dependency graph shows that one part is waiting on a memory fetch--Or it's waiting on results from the [relatively slow] floating point unit). But, the exec unit doesn't wait until the branch is decided. It keeps executing both in separate instruction streams because it notices that they are independent of what the branch is waiting for.
When the branch is [able to be] decided, it will throw away the path that isn't used. The advantage is that whatever decision path is used, we're already several instructions into it. That is, we didn't have to wait until the test results were available. This can be nested. If one or more of the paths have themselves conditional branching, they, too, will split and do speculative execution. These speculative paths form a tree structure. IIRC, x86 have a max tree depth of four?
Doing this is greatly aided by the extra registers. It reduces the number of pipeline stalls.
Seriously, if any of the above is news to you, I'd refrain from making statements about 64 bit performance. Your original about "many objects being 2x the size" was my clue. Even if you are a programmer of sorts, it seems to me that you don't truly understand much about the underlying architecture [x86 in particular].
I have two gmail accounts. One for sensitive stuff [medical, financial, etc] and I use thunderbird configured for POP3, partly because of gmail's goofy handling of subfolders doesn't mix will with thunderbird using IMAP. So, I just pull everything to local folders and have many filter rules.
The other gmail account was created when I got a smart phone [Samsung galaxy s3] and I just use the samsung email client [using IMAP]. I use it mostly to send links to articles from firefox on the phone, so I can read later on desktop and bookmark there. The other reason is that no sensitive stuff ever shows up on the smart phone.
When I have to access the second account on a desktop/laptop, that's where I've been using evolution. I'll give kmail a try there--thanks.
Only addresses/pointers [and longs] double in size. Most generated code uses the lower 8 regs were possible, so no prefix byte. Also, offsets can be smaller due to RIP relative addressing. Because the ABI specifies the first six function arguments are in registers, no wasteful pushes on calls. Also, because of the extra registers, this reduces "register pressure". That is, you don't have to store the value in a register to the stack frame just to make room for another value because you don't have enough registers to go around ["stack spill"]. So, you do fewer extraneous memory accesses. Because of the 64 bit wide registers, you can do real 64 bit multiply/divides.
The CPU instruction execution unit is much smarter than you imagine. Some of the instructions may be larger, but they're fetched a cache line at a time. They then get predecoded and put into a cached instruction execution queue.
The execution unit doesn't just "look at one instruction, execute it, then forget about it". While executing an instruction, it's looking ahead at several instructions to see which ones can be executed simultaneously with the current one. Within a given function, the execution unit just refetches from the queue and doesn't even need to redecode instructions from the L1 cache
With more registers, it is easier for the execution unit to detect parallelism and perform out-of-order, parallel, and speculative execution that make things go faster. If something gets "spilled" back to the stack, the compiler knows it did this, but the execution can't [and shouldn't] because it can't discern whether the stack write was for "spill" or whether a function that will need the data in memory will [soon] be called.
I regularly write and build programs and I regularly disassemble them to see if the code is efficient enough. They are quite compact.
And, given all of the above, overall, 64 bit is about 30% faster. Based on what I've read, and what I've benchmarked.
Slashdot Mirror
We are the Borg ...
You will be assimilated ...
Resistance is futile ...
You are absolutely correct.
The hacker controlled/malicious browser simply morphs the incoming JS as it comes off the wire (e.g. a filter on the socket data) to do whatever is necessary to bypass any real security check and return the "I am safe" result.
It could (e.g.) simply reverse the sense of:
...
if (bad_security_here())
Into:
...
if (! bad_security_here())
Or, do whatever else is necessary to nullify the security check.
Client side security checks are largely meaningless! If you control the browser, you can hack it any way you want, and you control what the JS does/can do.
A native app might be harder to morph, but, ultimately, the same technique can be applied [by patching binary bytes] to nullify the security checks.
They are only useful as a "health checkup" for a legitimate user's browser. But, Google's stated goal was:
The reason is that Google uses JavaScript to run risk assessment checks on the users accessing the login page, and if JavaScript is disabled, this allows crooks to pass through those checks undetected.
As I mentioned above, [real] crooks can easily get around this, so this is faux security at best.
At worst [as others have mentioned], foisting Javascript on users that do not want it, opens a gigantic Pandora's box of security holes for other sites that might download malicious javascript code.
Probably. IIRC ...
MRAM consumes less power than DRAM (vs. more). MRAM is _faster_ than DRAM (and is as fast as L2 cache).
It also has a very small bit cell size (so very high density).
So, it beats out 3D-XPoint (aka Optane) on almost every point.
Also, MRAM doesn't "wear out". From what I've read, 3D-XPoint is better than flash on this, but, eventually, has a wear out point.
There is one small advantage to having a PDF viewer in the browser, but it's a [beneficial] side effect for a missing browser feature.
If you do a google search for something and on the results page is a link to a PDF, the link _isn't_ a direct link to the final PDF file. It's a "result" link that actually points to google (e.g. google?url?sa=t&foo=bar). It redirects when you actually click on it. So, if you right click and select "copy link location", you'll get the link pointing to google and not the final site URL.
For ordinary site links, you just click on the search page link and when you land you have the final link in the page URL, which you can bookmark, copy, etc.
For PDFs, if your action is to run Adobe Reader, it will download the PDF but it loses the sense of the final link. With the embedded viewer, the final link is available in the viewer window's URL, just like an ordinary web page.
I just tried the two top links and get:
Firefox can't establish a connection to the server at krebsonsecurity.com.
The site could be temporarily unavailable or too busy. Try again in a few moments.
If you are unable to load any pages, check your computer's network connection.
If your computer or network is protected by a firewall or proxy, make sure that Firefox is permitted to access the Web.
Actually, IIRC, they didn't copy the signatures. When you build an android app, you use Oracle's JDK [and/or openJDK or some such] and get the signatures from that. Just like if you were using the JDK to create your own Java [non-Android] app. Otherwise, anybody writing Java code would be in the same boat.
Oracle has a copyright on the API. Oracle was trying to convert this to a "patent" on it. If Oracle had a patent [which they can't get], then Google would not have been able to create the underlying [Dalvik] from scratch re-implementation of the JVM.
If Oracle had won here, ironically, they would have had to open source the code to their database software. They port to Linux and it had GPL v2 [as does glibc, etc.]. Also, they use C, and the ISO C spec has a copyright.
If Oracle had won, anyone writing a C program would have had to make a royalty payment to ISO.
Further, the stdio.h that comes with glibc has a copyright. That doesn't prevent BSD from creating their own stdio.h [they are both built from scratch, even if they both define similar things to implement the POSIX specifications]. Actually, if Oracle had prevailed, all Linux implementations, gcc, glibc would be shut down because POSIX [specs] could never have existed. POSIX specs were a "clean room" reimplementation of the _specifications_ of interfaces and programs that had copyrights (i.e. AT&T had copyrights on the _Unix_ man pages for open/close/read/write and other system calls and utilities like ls/df/du, etc.)
What can a site do? Run a script to detect an ad blocker? Suggest a monthly payment and block the page from that user or request the ad block is removed?
Wired http://www.wired.com/ has started doing that and I've started not visiting their site, even though I whitelisted them so I could do it for free. Screw them ...
On the other hand, Stack Overflow https://stackoverflow.com/ has stated publicly that they are fine with ad blockers. Their reasoning is that if you're running one, you don't want ads, and wouldn't click on any if you saw them.
Actually, what seems to have happened is that they _did_ have a backup. But, they had to roll back to an old one.
Seriously. No backup?
Maybe they used Azure for their backup ...
I've been on slashdot for years and just started with stackoverflow/stackexchange three months ago. I did about five other posts here and they're somewhat based on my SO experiences. SO's code is proprietary, but they also base it on markdown. Maybe cut a deal?
Adopt a reputation system similar to stackexchange. Right now, _everybody_ [who has been on slashdot for any length of time] gets posts started at +2.
The highest a post can is +5.
But, why not allow posts starting at +10 for users who have earned that by having a history of making good posts
Allow anyone with sufficient reputation to be able to cast unlimited votes [ala reddit or stackexchange]. The same rules should apply. If you post on a given page, your moderation doesn't count.
Ironically, of late, when I have mod points to use, I can't seem to find a page I wish to moderate [or feel qualified to do so]. When I _don't_ have mod points, I find pages I _would_ like to moderate.
Moderation should _not_ be completely anonymous. If a person upvotes/downvotes, anybody should be able to agree/disagree. This is like fine tuned metamoderation and the result should accrue to the moderator's reputation in some fashion.
Users should also be able to moderate as to whether the post is on topic or not. The post may be brilliant, insightful, etc. but not really related to the TFA. So, how about "on topic"/"off topic" votes.
This should have gone in my other post: http://ask.slashdot.org/commen... but how about allowing users to sort posts dynamically based on different criteria for each page
Provide the ability to edit posts [possibly for a fixed period of time, say 5-10 minutes]. The edits should be discoverable by anyone (e.g. "show older versions" button). And/or allow the ability to _append_ to posts.
There are many scenarios where a poster forgets some trivial detail and posts [it happens a lot]. They reply to their own post with a correction. This adds to clutter. Also, many repliers never see such corrections and the poster gets hammered based solely on the first message, even though they've already done their "mea culpa".
Also, someone who is quite knowledgeable about a given topic may not be able to provide all the relevant knowledge they have in a single sitting. They may wish to trim one post, reorganize it, to make things more clear, without having to do a separate post [which probably won't be seen anyway].
Right now, slashdot is _just_ a chat room of sorts. Except for the links to the TFA, there is no long term value to the thread posts. Very few people will revisit a slashdot page, looking for reference material. Even the "ask slashdot: how do I handle this situation?" pages that can have a lot of useful advice [and do not have a TFA] are difficult to use for that purpose.
Right now you can only set a message visibility level based on score for your entire account.
On a given page, usually the first posted threads are _long_ and usually off-topic to TFA [or drift that way quickly]. This is more prevalent the more difficult the [scientific] topic is. Fewer people understand it, but still want to post.
For example, a post about a discovery at CERN might generate a long thread about the merits of government funding of research. Fair enough. But, for someone looking for a discussion of the true scientific data, etc. would have to scroll through all that. That's a lot of work to get to the more germane posts/threads that usually appear nearer the bottom of the page.
How about a collapse/expand button on _each_ message that will collapse/expand [expose/hide] everything under it.
This would help reduce the effect of the "early posters" that "shanghai" a page with topics that are only obliquely connected with the central topic of a given page.
Now, I'm _not_ against oblique threads. Some are actually interesting. If people wish to reply under these, all to the good.
But, we should give users more ability to filter out the threads they're _not_ interested in reading, or more importantly, scrolling over to get to the threads they _are_ interested in.
On stackexchange, any user can see upvotes/downvotes/comments/etc within 10 minutes [automatically updated on the top bar]. No waiting a day or two to see replies, comment moderation, etc.
Require all ACs to have a valid login [or have a way to differentiate them internally].
On a given page, the first AC poster is known as AC#1. The AC second poster [if different] is AC#2. And, so on ...
That way, we can see if different ACs are having a conversation [which is fine], or we just have one AC running amok and creating a phony conversation with themselves, just to stir things up.
On another page, the numbers start from 1 (i.e. _no_ correlation between AC#1 on page X and AC#1 on page Y).
This preserves anonymity but also gives a particular page more sanity. It might cut down on the anonymous trolling that seems to have taken over Slashdot.
Several AC's replied to me about speed of light being [roughly] one foot per nanosecond [which I had forgotten]. So, 13.7 us is 13,700 ns, or 13,700 feet, or 2.5 miles [just as you said]. Wow! I know that GPS receivers [try to] use several satellites. Can they compensate for this without an almanac update [automatic or manual]? Or, if they use the faulty one, what happens? Would they try to average it in or reject it as too far off the average of the others?
The time discrepancy is 13.7 microseconds [not milliseconds]. I don't know how that translates to position accuracy, but, to me, even that seems a bit large for something derived from an atomic clock.
After the stagefright bug, Google implemented a "rapid response" update system (i.e.) older systems could get security fix updates [but not necessarily feature enhancements]. This preserves the market for new devices but allows older ones to remain secure.
Google rolled this out to its various vendors (e.g. Samsung, Moto, etc.). Several of them have pledged to honor this. Thus, I recently got an OTA [security] update from Samsung for my Galaxy S3 [that was EOL] to fix stagefright.
There was a bit of NRE to put this in place by Google [and the vendors]. Now, I expect, that it should be fairly easy to publish security updates even for older phones.
It's in everybody's best interests to do so. Vendors don't lose the market for new phones. They don't lose market share due to EOL security concerns anymore (e.g. people switch to iPhone simply because Apple can/could publish the security updates anytime). What was an Apple advantage is not one anymore.
Did you do this with fedup? From what I could see, it was possible [despite the dire warnings from fedora about "don't do it"].
And, I've edited grub.cfg to remove "quiet" and "rhgb" not so much because of aesthetics, but because my graphics card was having issues with some versions of the nouveau driver.
I just got an OTA update that fixed the stagefright vuln for my [Boost] Galaxy S3. AFAICT, it was [mostly] just security fixes, which is fine.
IMO, Google had to create the tools for the "rapid response" updates, which they did. Now, [IMO smart] vendors like Moto, Samsung, et. al. are beginning to use them.
As a computer engineer myself, I use git. I know how relatively easy it is to apply source patches to older tree branches using it. Since git is at the core of Android source tree development, this is also easy to do. Google just had to package this up as a release system.
This works for everybody: Consumers, vendors, and telcos. It improves the brand quality/loyalty. I really like Android, but the prospect of "being left behind" on security fixes was beginning to make me think [reluctantly] about Apple/iPhone/iOS because of the security update issue.
It also can address the "fragmentation" issue, if the monthly updates add some forward compatibility libraries. Apps crashing because they were built for Android version N, when I only have N-x. I don't mind a few feature restrictions, because that's better than outright freeze/crash/lockup/etc. necessitating a reboot.
If I _had_ to write python, for some reason, I'd probably write a little pre-compiler to take something maintainable that I'd write and output whitespace-tokenized python.
Been there, done that. In perl ;-)
Google has been working on Dart [has its own VM which is more efficient, but can cross-compile to the JVM]. But, Dart hasn't caught on quite the way they hoped. And, then there's Scala ... And, I do believe perl6 can [or will] compile to the JVM.
They could also migrate away from the JVM since they [sort of] do already by doing JIT conversion to dex format [which is a "general purpose register" model rather than a "stack machine" model, IIRC].
This gets done when a new APK is installed. Also, when my Galaxy S3 gets a firmware update, after the 2nd auto-reboot, it goes through an "optimizing apps" phase for all my installed apps [the dex conversion, AFAICT]. This could be extended to translate legacy binary API calls to whatever they come up with. For new development, developers just use the new API definition files [which sidestep the alleged copyright issue]
No, I'm looking at all job mixes. Ripping through a large array is going to be memory bound. Business code will benefit more from 64 bit.
When you do a function call in 32 bit, you have to calculate the argument values, then do pushes to the stack. In 64 bit, you put them directly into the correct registers. The optimizer is usually good enough to do the calculation directly on the target register (e.g. it doesn't calc the value in %rax and then move it to %rXX--it does the calc directly on %rXX). So, for four arguments, you save four push instructions, not to mention storing the the cache/dram. Further, if some of the args are just passed along: ...
fncA(a,b,c,d)
{
fncB(a,b,7,9)
}
The a/b values are simply already in the correct regs, so you skip two fetches and two pushes.
Once again, the extra regs allow the exec unit to see the parallelism available. This can be [and is] applied to almost every five instruction sequence in any function.
Oh, forgot to mention the RIP relative addressing advantage when generating PIC (position independent code). In 64 bit, address calculation is done relative to the %rip (program counter) register. This is wonderful for shared libraries (e.g. .so's, .dll's) which are built using PIC. In 32 bit, you have to burn the %ebx register to have a base register to address from. So, the available register count dwindles by one.
Speculative execution. If you have a sequence like: ... ...
inst1
inst2
inst3
inst4
test
bnz value_nonzero
value_is_zero:
inst5
inst6
b elsewhere
value_is_nonzero: ...
inst20
inst21
The execution unit may execute both pathways simultaneously [speculatively] (e.g. either the branch is taken or not). The exec unit may not have enough info to decide the branch (e.g. the data dependency graph shows that one part is waiting on a memory fetch--Or it's waiting on results from the [relatively slow] floating point unit). But, the exec unit doesn't wait until the branch is decided. It keeps executing both in separate instruction streams because it notices that they are independent of what the branch is waiting for.
When the branch is [able to be] decided, it will throw away the path that isn't used. The advantage is that whatever decision path is used, we're already several instructions into it. That is, we didn't have to wait until the test results were available. This can be nested. If one or more of the paths have themselves conditional branching, they, too, will split and do speculative execution. These speculative paths form a tree structure. IIRC, x86 have a max tree depth of four?
Doing this is greatly aided by the extra registers. It reduces the number of pipeline stalls.
Seriously, if any of the above is news to you, I'd refrain from making statements about 64 bit performance. Your original about "many objects being 2x the size" was my clue. Even if you are a programmer of sorts, it seems to me that you don't truly understand much about the underlying architecture [x86 in particular].
Nice to hear some positive feedback on kmail.
I have two gmail accounts. One for sensitive stuff [medical, financial, etc] and I use thunderbird configured for POP3, partly because of gmail's goofy handling of subfolders doesn't mix will with thunderbird using IMAP. So, I just pull everything to local folders and have many filter rules.
The other gmail account was created when I got a smart phone [Samsung galaxy s3] and I just use the samsung email client [using IMAP]. I use it mostly to send links to articles from firefox on the phone, so I can read later on desktop and bookmark there. The other reason is that no sensitive stuff ever shows up on the smart phone.
When I have to access the second account on a desktop/laptop, that's where I've been using evolution. I'll give kmail a try there--thanks.
Not really true.
Only addresses/pointers [and longs] double in size. Most generated code uses the lower 8 regs were possible, so no prefix byte. Also, offsets can be smaller due to RIP relative addressing. Because the ABI specifies the first six function arguments are in registers, no wasteful pushes on calls. Also, because of the extra registers, this reduces "register pressure". That is, you don't have to store the value in a register to the stack frame just to make room for another value because you don't have enough registers to go around ["stack spill"]. So, you do fewer extraneous memory accesses. Because of the 64 bit wide registers, you can do real 64 bit multiply/divides.
The CPU instruction execution unit is much smarter than you imagine. Some of the instructions may be larger, but they're fetched a cache line at a time. They then get predecoded and put into a cached instruction execution queue.
The execution unit doesn't just "look at one instruction, execute it, then forget about it". While executing an instruction, it's looking ahead at several instructions to see which ones can be executed simultaneously with the current one. Within a given function, the execution unit just refetches from the queue and doesn't even need to redecode instructions from the L1 cache
With more registers, it is easier for the execution unit to detect parallelism and perform out-of-order, parallel, and speculative execution that make things go faster. If something gets "spilled" back to the stack, the compiler knows it did this, but the execution can't [and shouldn't] because it can't discern whether the stack write was for "spill" or whether a function that will need the data in memory will [soon] be called.
I regularly write and build programs and I regularly disassemble them to see if the code is efficient enough. They are quite compact.
And, given all of the above, overall, 64 bit is about 30% faster. Based on what I've read, and what I've benchmarked.