This is like if Google just suddenly started calling Hell's Kitchen something else. Or renamed SOHO for no reason.
Except that as the article notes, the name was actually created a few years ago by a neighborhood nonprofit steering group that residents voted for: The East Cut name originated from a neighborhood nonprofit group in San Francisco that residents voted to create in 2015 to clean and secure the area.
Google didn't just suddenly rename it for no reason. The issue is more subtle than that; in previous times, the neighborhood council decision would either be ignored or take a long time to spread and catch on. With Google's ubiquity, changing it on Google maps has an immediate effect. Whether that's bad and jarring or good and avoids ambiguity, it's certainly new and different.
1. None of these were in “the early days of PC gaming”; they were a decade plus after PC gaming exploded during the Commodore 64/Applie II/etc era. Games like Catacomb, Ultima Underworld, and early ID entries like Hovertank 3D and Wolfenstein 3D had already birthed the FPS genre. Doom was a huge deal and certainly catalyzed things for the mid-90s and established FPSes as a prestige genre (as well as helping the popularity of online play).
2. Duke Nukem and Duke Nukem 2 (the latter of which came out the same year as Doom) were side-scrolling 2D platformers. The “2.5D” version was Duke Nukem 3D, which came out like 3 years later than Doom during the explosion of post-Doom FPSes. It was closer to the Quake era than the Doom era. Claiming that it's part of some “big 3” is really weird; it's better grouped in with the rest of the 2.5D-era post-Doom games like Marathon, Heretic, Hexen, Star Wars: Dark Forces, etc.
I mostly agree, though if the license on the generated audio is liberal enough I could see using this to create audio books of public domain texts in a crowd-sourced project. Feed the texts through (which, if distributed reasonably, shouldn't really be a significant privacy intrusion; the information's all out there already) and then save it for future use so it's still available even if the cloud service goes down.
Fuzzing is great, but he doesn't seem to understand what a language flaw is.
In the case of Python, he's found 2 methods in libraries that can call shell commands. Leaving aside that this would be a library issue rather than a language issue, there's no evidence that it's even that.
Python explicitly doesn't have sandboxing. Like most languages (including C, C++, etc), the documented behavior is that if you control the program and environment then you're fully allowed to import subprocess or os and run whatever you want. You don't need to find "hidden" ways to run a subprocess, you can directly "import subprocess" and run stuff.
This is doubly true because of the nature of the modules investigated. The first "flaw" is that mimetools has a deprecated "pipeto" method that lets you pipe to arbitrary commands. But mimetools is already well-known to expose os access in millions of ways (most obviously, it imports and exposes os, so if for some bizarre reason you want to avoid importing os yourself, you can simply run "mimetools.os.popen" directly); no competent programmer would expect otherwise.
The second "flaw" is that pydoc runs a pager program which lets you run an arbitrary command if you control the program environment. Of course, the documentation states explicitly that the specified pager program will be used. It's unclear what part of the behavior here he thinks even surprising. And, again, the pydoc module imports and exposes "os" in exactly the same way that mimetools does.
Earlier this week security-hardened Android build CopperheadOS temporarily blocked Nexus updates on its servers after finding out that other companies have been flashing the ROM onto Nexus phones and selling them commercially in violation of the CopperheadOS licensing terms. The incident highlights an inherent problem in getting open source to be used by the masses
This is FUD. If CopperheadOS prohibits selling it commercially, then they are not using an open-source license. By definition, open-source licenses cannot prevent others from selling the software commercially or otherwise prohibit redistribution or discriminate against fields of endeavor (including business use).
And, indeed, most sources (e.g. https://en.wikipedia.org/wiki/...) call the Copperhead license "source available" rather than "open source" because of these non-open-source restrictions.
1. Free Redistribution The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale.... 2. 6. No Discrimination Against Fields of Endeavor The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.
And flashing it onto a ROM would constitute a derived work covered under section 3 of the OSD.
Unlike the others, DAP's numbers come from billions of visits over the past 90 days to over 400 US executive branch government domains
This strikes me as being a very poor source to use if you're interested in overall desktop statistics. People visit government domains much more often from work than from home, and government workers visit government sites more often than non-government workers do. Alternative OSes are less common in government jobs than non-government positions, and there's probably a skew one way or the other in generic home vs. work statistics.
I'm not disputing that the recent stats cited are wrong, just objecting to advocating what seems to be an inherently statistically biased source as the "most accurate" for this statistic.
"The new version tests another change to notifications in which apps can only make a notification sound alert once per second."
This is definitely a minor thing, but once you've started looking at it should be a lot more limited. A configurable time would be ideal, but if you want to make it a sensible default it should be more like one sound alert every 10 minutes unless you've looked at a notification in between--if you're actually checking messages as they come in you'll still get all the defaults, but you won't have to silence 5 in a row if you're busy or don't care about them.
Yes. The real problem is that Microsoft is advocating for slow-rolling disclosure of security vulnerabilities by hiding patches until the stable release comes out. That's fine, it's not an insane stance, but they're presenting it as though that's obvious and noncontroversial and that there are no drawbacks to their methodology and no advantages to Google's full disclosure policy. That's where they're being disingenuous--full disclosure vs. slow disclosure is one of the more hotly debated topics in security circles, and Microsoft knows it (or should).
If they want to advocate for slow disclosure, they should at least acknowledge that they're taking one side of a controversial topic about which a lot of serious security people disagree, not pretend that Google is just doing something recklessly idiotic and should clearly do things the Microsoft way.
On the surface slow-rolling things seems like a good idea--why show the attackers the breach before you've repaired the wall? The problem with that line of thinking is that it presumes that you're the only one who's found the breach, and that attackers aren't already exploiting it. That's generally naÃve, you have no way of knowing whether a vulnerability is being actively exploited or not.
By disclosing fully, you make it possible for people to protect themselves or to make judgements about how serious the issue is for them. You also make companies take security more seriously in the future, which hopefully leads to greater global security even if the local impact is muddier.
There are obvious trade-offs the other way, as well. But Microsoft pretending that full disclosure is inherently bad for security is duplicitous.
The Fire has a fine battery life for a tablet, but it's still horrible compared to e-ink readers, which usually last a month or two between charges if you average an hour of reading a day. E-ink displays only draw current for screen updates, so the majority of the time when you're reading (as opposed to flipping the page) the device draws very little power.
That link has only the source code. It does not include the training data set.
The submission link requires CC-0 attribution, which makes me hopeful that they plan to release the data freely. But I hunted all over the site and couldn't find either a link to the data or any comment about their plans for it going forward.
He's no longer the head, but it's not his "former company"; he remained as chairman until 2014 and has been a technology adviser since then. He actually puts in more time at the company now than he did in the chairman years.
The quote is about Windows phone profits, not Microsoft as a whole. Microsoft did see a downturn in overall profits last year when phone revenue tanked, but this year a boom in cloud products has turned that around nicely.
The article is still wrong, though, because it confuses profits and revenues (Windows phone is not profitable at all, and I don't think it ever was). If you click through far enough the original article doesn't make that mistake:
https://www.neowin.net/news/ye... During the quarter ending in December, Microsoft's phone revenue dropped to just $200 million, which included some sales of feature phones, before the company completed its sale of that business unit to Foxconn in November. That figure has now dropped to virtually nothing.
According to the company's 10-Q filing to the SEC for Q3 FY2015, its phone hardware revenue for that quarter totalled $1.397 billion. One year later, in its 10-Q for Q3 FY2016, Microsoft said that phone revenue had fallen by $662 million, reducing it to $735 million.
Today, as Microsoft published its earnings report for Q3 FY2017, it revealed that its "Phone revenue declined $730 million". Based on its earlier financial disclosures, that means the company's phone hardware revenue fell to just $5 million for the entire quarter ending March 31, 2017.
Clark only has 3 of the 5 major credit bureaus listed at that link; PRBC is a little wonky, but if you're freezing your credit you'll want to freeze it with Equifax, Experian, Innovis, and TransUnion. http://krebsonsecurity.com/201... has all 4, or use Clark's links and add https://www.innovis.com/person...
The Bering Sea's typically not involved in the Indonesia raft theory. The Kon-Tiki route was all south of the equator. And the Bering Strait was a land route beginning c. 21,000 BP, though access along the coast was blocked by ice until about 17,000 BP and the interior route didn't clear up until about 13,500 BP. There's a pretty good history of the sea level in the area here: http://theconversation.com/fir...
But like I said there's plenty of other evidence against the theory, at least as a significant driver of human migration.
The OP's bizarre, too (I ascribe that to the media losing something in translation, not necessarily the original research); Clovis-first has been out of favor for decades now, and the timing on when the Bering crossing was open doesn't agree with anything I've seen espoused in recent years. The inland route probably de-iced c. 13,500 BP, and the coastal route by 17,000 BP give or take. And most mDNA evidence has suggested that the coastal route was used, so the timing's not only fine for humans in Mexico by 13,000 BP, but even a few millenia earlier.
I'm guessing the research was phrased more as "here's additional evidence against Clovis-first and for an earlier date" and the reporters added some sloppy wording around it to sensationalize things.
This was essentially the theory that drove his Kon-Tiki expedition, exteded past Polynesia into Indonesia. https://en.wikipedia.org/wiki/...
It's a really good theory, but DNA and linguistic evidence suggest there's not much basis for it (though of course they can't do much to rule out isolated instances as opposed to larger trends).
In Canada the earliest peoples are referred to as "First Nations." https://en.wikipedia.org/wiki/... [wikipedia.org]. I like that term. I wish we would use it here (i.e. in the USA) as well.
I'm not a huge fan; "First" is a Eurocentric label that's a little dismissive of pre-Columbian cultures in the Americas. It doesn't reflect the fact that there was a rich history of cultures rising and falling in North America prior to European contact. The natives at the time were really the latest in a series of different cultures in Canada (and the Americas), not the first. See https://en.wikipedia.org/wiki/... and https://en.wikipedia.org/wiki/... and https://en.wikipedia.org/wiki/... among many others.
Copy collection and other compacting approaches have some major advantages, especially decreasing memory fragmentation, but they also have major disadvantages including higher latency and loss of cache coherence. And greater overall memory use - the old "double your memory" problem is long since solved, but if you have very large objects there are still issues there. Compacting was super popular in the 1990s but many modern GCs have moved back toward more traditional mark-sweep with incremental/generational enhancements, especially in high performance NUMA environments.
Copy collect (and related mark-compact, etc approaches) is certainly still viable in many circumstances and there have been a lot of advances in minimizing the latency impact, but calling current mark-sweep based approaches outdated or not "real" GC is nonsense.
The Bohem collector "uses a mark-sweep algorithm". I.e. NOT a modern GC
I'm not a C++ fan at all, but in this context this doesn't make sense. The vast majority of Java implementations (including the Oracle JDK) also use mark-sweep GC algorithms too, and many of the most cutting edge GC algorithms are mark-sweep algorithms. Boehm-Weiser uses a pretty sophisticated mark-sweep policy that is both generational and incremental.
http://javarevisited.blogspot.... notes that: "Concurrent Mark Sweep Garbage collector is most widely used garbage collector in java and it uses an algorithm to first mark object which needs to collect when garbage collection triggers."
"Interpreted" is not a language feature, it's an implementation detail. There are C interpreters like EiC (and even assembly interpreters used in things like Bochs) and Python JIT compilers like PyPy.
2. Run directly from source
Even CPython compiles to bytecode, which is a tad more efficient that running directly from source.
Beyond that, Java has proper Garbage Collection rather than reference-counted garbage
Neither the Python nor Java language defines a GC algorithm, ref-counting or otherwise, and different implementations of each use different GC methods. PyPy, for instance (which is the Python JIT implementation that most people who care about performance use) has no ref counting but uses an incremental hybrid mark-sweep GC.
Even the CPython implementation, which does use ref-counting, combines it with a generational GC to detect cycles.
Java has real support for native threads running on different cores instead of whatever kind of wimpy simulation (green threads?) is offered on Python
Python has native support for OS-level threads and has since the bad old days when the 1.1 JVM only had green threads. Python also has superior support for multiprocessing (e.g. the ability to fork() without exec(), which Java historically has lacked) which means you're not stuck throwing out memory protection every time you want to have concurrency.
You're probably conflating OS-level thread support with the global interpreter lock, which is an actual Python pain point for concurrent programming in some circumstances.
Java has a standardized GUI library in Swing instead of what the heck are you supposed to use in Python?
Alternatively one might say that Python has a real cross-platform library in wxpython that actually uses the native widgets rather than attempting to emulate them badly a la Swing.
Python fails because it's bitch to import code from SomeUnknownD00d into yours, hoping SUD was kind enough to convert tabs to spaces. And to logical spaces. If my code has tabstops of 4, and SUD has tabstops of 2, all bets are off.
This is wrong. SomeUnknownD00d can use whatever tab stop and mix of spaces/tabs that he wants and you can import from your code no problem, even if your tab stop is different or you use all spaces or whatever. Spacing only has to be consistent within a single block, there's no inter-module dependency there.
Most thieves work as teams. Robbery is one of the crimes most likely to have a group of perpetrators, but even so the majority of robberies (55-60%) are committed by solo individuals.
That was a valid point 5 years ago. Things have changed, at least when it comes to PHP.
PHP 7 running on fpm or HHVM is very fast, almost as fast as nodejs. This is not your grandfather's internet.
Python on PyPy is significantly faster than PHP7 for compute-intensive workloads, and in some cases is competitive with Java. It's still about 50%-75% slower than C/C++/Rust, but it's pretty respectable.
Slashdot Mirror
This is like if Google just suddenly started calling Hell's Kitchen something else. Or renamed SOHO for no reason.
Except that as the article notes, the name was actually created a few years ago by a neighborhood nonprofit steering group that residents voted for: The East Cut name originated from a neighborhood nonprofit group in San Francisco that residents voted to create in 2015 to clean and secure the area.
Google didn't just suddenly rename it for no reason. The issue is more subtle than that; in previous times, the neighborhood council decision would either be ignored or take a long time to spread and catch on. With Google's ubiquity, changing it on Google maps has an immediate effect. Whether that's bad and jarring or good and avoids ambiguity, it's certainly new and different.
1. None of these were in “the early days of PC gaming”; they were a decade plus after PC gaming exploded during the Commodore 64/Applie II/etc era. Games like Catacomb, Ultima Underworld, and early ID entries like Hovertank 3D and Wolfenstein 3D had already birthed the FPS genre. Doom was a huge deal and certainly catalyzed things for the mid-90s and established FPSes as a prestige genre (as well as helping the popularity of online play).
2. Duke Nukem and Duke Nukem 2 (the latter of which came out the same year as Doom) were side-scrolling 2D platformers. The “2.5D” version was Duke Nukem 3D, which came out like 3 years later than Doom during the explosion of post-Doom FPSes. It was closer to the Quake era than the Doom era. Claiming that it's part of some “big 3” is really weird; it's better grouped in with the rest of the 2.5D-era post-Doom games like Marathon, Heretic, Hexen, Star Wars: Dark Forces, etc.
I mostly agree, though if the license on the generated audio is liberal enough I could see using this to create audio books of public domain texts in a crowd-sourced project. Feed the texts through (which, if distributed reasonably, shouldn't really be a significant privacy intrusion; the information's all out there already) and then save it for future use so it's still available even if the cloud service goes down.
Fuzzing is great, but he doesn't seem to understand what a language flaw is.
In the case of Python, he's found 2 methods in libraries that can call shell commands. Leaving aside that this would be a library issue rather than a language issue, there's no evidence that it's even that.
Python explicitly doesn't have sandboxing. Like most languages (including C, C++, etc), the documented behavior is that if you control the program and environment then you're fully allowed to import subprocess or os and run whatever you want. You don't need to find "hidden" ways to run a subprocess, you can directly "import subprocess" and run stuff.
This is doubly true because of the nature of the modules investigated. The first "flaw" is that mimetools has a deprecated "pipeto" method that lets you pipe to arbitrary commands. But mimetools is already well-known to expose os access in millions of ways (most obviously, it imports and exposes os, so if for some bizarre reason you want to avoid importing os yourself, you can simply run "mimetools.os.popen" directly); no competent programmer would expect otherwise.
The second "flaw" is that pydoc runs a pager program which lets you run an arbitrary command if you control the program environment. Of course, the documentation states explicitly that the specified pager program will be used. It's unclear what part of the behavior here he thinks even surprising. And, again, the pydoc module imports and exposes "os" in exactly the same way that mimetools does.
This is FUD. If CopperheadOS prohibits selling it commercially, then they are not using an open-source license. By definition, open-source licenses cannot prevent others from selling the software commercially or otherwise prohibit redistribution or discriminate against fields of endeavor (including business use).
And, indeed, most sources (e.g. https://en.wikipedia.org/wiki/...) call the Copperhead license "source available" rather than "open source" because of these non-open-source restrictions.
See https://opensource.org/osd
1. Free Redistribution
The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale.
2. 6. No Discrimination Against Fields of Endeavor
The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.
And flashing it onto a ROM would constitute a derived work covered under section 3 of the OSD.
Unlike the others, DAP's numbers come from billions of visits over the past 90 days to over 400 US executive branch government domains
This strikes me as being a very poor source to use if you're interested in overall desktop statistics. People visit government domains much more often from work than from home, and government workers visit government sites more often than non-government workers do. Alternative OSes are less common in government jobs than non-government positions, and there's probably a skew one way or the other in generic home vs. work statistics.
I'm not disputing that the recent stats cited are wrong, just objecting to advocating what seems to be an inherently statistically biased source as the "most accurate" for this statistic.
"The new version tests another change to notifications in which apps can only make a notification sound alert once per second."
This is definitely a minor thing, but once you've started looking at it should be a lot more limited. A configurable time would be ideal, but if you want to make it a sensible default it should be more like one sound alert every 10 minutes unless you've looked at a notification in between--if you're actually checking messages as they come in you'll still get all the defaults, but you won't have to silence 5 in a row if you're busy or don't care about them.
Yes. The real problem is that Microsoft is advocating for slow-rolling disclosure of security vulnerabilities by hiding patches until the stable release comes out. That's fine, it's not an insane stance, but they're presenting it as though that's obvious and noncontroversial and that there are no drawbacks to their methodology and no advantages to Google's full disclosure policy. That's where they're being disingenuous--full disclosure vs. slow disclosure is one of the more hotly debated topics in security circles, and Microsoft knows it (or should).
If they want to advocate for slow disclosure, they should at least acknowledge that they're taking one side of a controversial topic about which a lot of serious security people disagree, not pretend that Google is just doing something recklessly idiotic and should clearly do things the Microsoft way.
Bruce Schneier summarizes the counterargument here: https://www.schneier.com/essay...
On the surface slow-rolling things seems like a good idea--why show the attackers the breach before you've repaired the wall? The problem with that line of thinking is that it presumes that you're the only one who's found the breach, and that attackers aren't already exploiting it. That's generally naÃve, you have no way of knowing whether a vulnerability is being actively exploited or not.
By disclosing fully, you make it possible for people to protect themselves or to make judgements about how serious the issue is for them. You also make companies take security more seriously in the future, which hopefully leads to greater global security even if the local impact is muddier.
There are obvious trade-offs the other way, as well. But Microsoft
pretending that full disclosure is inherently bad for security is duplicitous.
The Fire has a fine battery life for a tablet, but it's still horrible compared to e-ink readers, which usually last a month or two between charges if you average an hour of reading a day. E-ink displays only draw current for screen updates, so the majority of the time when you're reading (as opposed to flipping the page) the device draws very little power.
The Kobo Aura H2O and H2O2 are both IP67 as well and avoid the Kindle ecosystem. I've very happy with my H2O.
That link has only the source code. It does not include the training data set.
The submission link requires CC-0 attribution, which makes me hopeful that they plan to release the data freely. But I hunted all over the site and couldn't find either a link to the data or any comment about their plans for it going forward.
He's no longer the head, but it's not his "former company"; he remained as chairman until 2014 and has been a technology adviser since then. He actually puts in more time at the company now than he did in the chairman years.
https://www.theverge.com/2014/...
The quote is about Windows phone profits, not Microsoft as a whole. Microsoft did see a downturn in overall profits last year when phone revenue tanked, but this year a boom in cloud products has turned that around nicely.
The article is still wrong, though, because it confuses profits and revenues (Windows phone is not profitable at all, and I don't think it ever was). If you click through far enough the original article doesn't make that mistake:
https://www.neowin.net/news/ye...
During the quarter ending in December, Microsoft's phone revenue dropped to just $200 million, which included some sales of feature phones, before the company completed its sale of that business unit to Foxconn in November. That figure has now dropped to virtually nothing.
According to the company's 10-Q filing to the SEC for Q3 FY2015, its phone hardware revenue for that quarter totalled $1.397 billion. One year later, in its 10-Q for Q3 FY2016, Microsoft said that phone revenue had fallen by $662 million, reducing it to $735 million.
Today, as Microsoft published its earnings report for Q3 FY2017, it revealed that its "Phone revenue declined $730 million". Based on its earlier financial disclosures, that means the company's phone hardware revenue fell to just $5 million for the entire quarter ending March 31, 2017.
Clark only has 3 of the 5 major credit bureaus listed at that link; PRBC is a little wonky, but if you're freezing your credit you'll want to freeze it with Equifax, Experian, Innovis, and TransUnion. http://krebsonsecurity.com/201... has all 4, or use Clark's links and add https://www.innovis.com/person...
If it made Experian go out of business, and the other two invest heavily in security to prevent another event
I assume that's a thinko for Equifax (not experian)
There are 4 other credit bureaus, not 2; Experian, Innovis, PRBC, Transunion. Though PRBC is weird.
The Bering Sea's typically not involved in the Indonesia raft theory. The Kon-Tiki route was all south of the equator. And the Bering Strait was a land route beginning c. 21,000 BP, though access along the coast was blocked by ice until about 17,000 BP and the interior route didn't clear up until about 13,500 BP. There's a pretty good history of the sea level in the area here: http://theconversation.com/fir...
But like I said there's plenty of other evidence against the theory, at least as a significant driver of human migration.
The OP's bizarre, too (I ascribe that to the media losing something in translation, not necessarily the original research); Clovis-first has been out of favor for decades now, and the timing on when the Bering crossing was open doesn't agree with anything I've seen espoused in recent years. The inland route probably de-iced c. 13,500 BP, and the coastal route by 17,000 BP give or take. And most mDNA evidence has suggested that the coastal route was used, so the timing's not only fine for humans in Mexico by 13,000 BP, but even a few millenia earlier.
I'm guessing the research was phrased more as "here's additional evidence against Clovis-first and for an earlier date" and the reporters added some sloppy wording around it to sensationalize things.
Thor Heyerdahl is that you?
This was essentially the theory that drove his Kon-Tiki expedition, exteded past Polynesia into Indonesia. https://en.wikipedia.org/wiki/...
It's a really good theory, but DNA and linguistic evidence suggest there's not much basis for it (though of course they can't do much to rule out isolated instances as opposed to larger trends).
In Canada the earliest peoples are referred to as "First Nations." https://en.wikipedia.org/wiki/... [wikipedia.org]. I like that term. I wish we would use it here (i.e. in the USA) as well.
I'm not a huge fan; "First" is a Eurocentric label that's a little dismissive of pre-Columbian cultures in the Americas. It doesn't reflect the fact that there was a rich history of cultures rising and falling in North America prior to European contact. The natives at the time were really the latest in a series of different cultures in Canada (and the Americas), not the first. See https://en.wikipedia.org/wiki/... and https://en.wikipedia.org/wiki/... and https://en.wikipedia.org/wiki/... among many others.
Copy collection and other compacting approaches have some major advantages, especially decreasing memory fragmentation, but they also have major disadvantages including higher latency and loss of cache coherence. And greater overall memory use - the old "double your memory" problem is long since solved, but if you have very large objects there are still issues there. Compacting was super popular in the 1990s but many modern GCs have moved back toward more traditional mark-sweep with incremental /generational enhancements, especially in high performance NUMA environments.
Copy collect (and related mark-compact, etc approaches) is certainly still viable in many circumstances and there have been a lot of advances in minimizing the latency impact, but calling current mark-sweep based approaches outdated or not "real" GC is nonsense.
The Bohem collector "uses a mark-sweep algorithm". I.e. NOT a modern GC
I'm not a C++ fan at all, but in this context this doesn't make sense. The vast majority of Java implementations (including the Oracle JDK) also use mark-sweep GC algorithms too, and many of the most cutting edge GC algorithms are mark-sweep algorithms. Boehm-Weiser uses a pretty sophisticated mark-sweep policy that is both generational and incremental.
http://javarevisited.blogspot.... notes that:
"Concurrent Mark Sweep Garbage collector is most widely used garbage collector in java and it uses an algorithm to first mark object which needs to collect when garbage collection triggers."
http://www.oracle.com/webfolde... explains the current generational mark-sweep algorithm used by the Oracle JDK (standard Java).
Scripting languages are:
1. Interpreted
"Interpreted" is not a language feature, it's an implementation detail. There are C interpreters like EiC (and even assembly interpreters used in things like Bochs) and Python JIT compilers like PyPy.
2. Run directly from source
Even CPython compiles to bytecode, which is a tad more efficient that running directly from source.
Beyond that, Java has proper Garbage Collection rather than reference-counted garbage
Neither the Python nor Java language defines a GC algorithm, ref-counting or otherwise, and different implementations of each use different GC methods. PyPy, for instance (which is the Python JIT implementation that most people who care about performance use) has no ref counting but uses an incremental hybrid mark-sweep GC.
Even the CPython implementation, which does use ref-counting, combines it with a generational GC to detect cycles.
Java has real support for native threads running on different cores instead of whatever kind of wimpy simulation (green threads?) is offered on Python
Python has native support for OS-level threads and has since the bad old days when the 1.1 JVM only had green threads. Python also has superior support for multiprocessing (e.g. the ability to fork() without exec(), which Java historically has lacked) which means you're not stuck throwing out memory protection every time you want to have concurrency.
You're probably conflating OS-level thread support with the global interpreter lock, which is an actual Python pain point for concurrent programming in some circumstances.
Java has a standardized GUI library in Swing instead of what the heck are you supposed to use in Python?
Alternatively one might say that Python has a real cross-platform library in wxpython that actually uses the native widgets rather than attempting to emulate them badly a la Swing.
Python fails because it's bitch to import code from SomeUnknownD00d into yours, hoping SUD was kind enough to convert tabs to spaces. And to logical spaces. If my code has tabstops of 4, and SUD has tabstops of 2, all bets are off.
This is wrong. SomeUnknownD00d can use whatever tab stop and mix of spaces/tabs that he wants and you can import from your code no problem, even if your tab stop is different or you use all spaces or whatever. Spacing only has to be consistent within a single block, there's no inter-module dependency there.
Most thieves work as teams.
Robbery is one of the crimes most likely to have a group of perpetrators, but even so the majority of robberies (55-60%) are committed by solo individuals.
https://books.google.com/books...
That was a valid point 5 years ago. Things have changed, at least when it comes to PHP.
PHP 7 running on fpm or HHVM is very fast, almost as fast as nodejs. This is not your grandfather's internet.
Python on PyPy is significantly faster than PHP7 for compute-intensive workloads, and in some cases is competitive with Java. It's still about 50%-75% slower than C/C++/Rust, but it's pretty respectable.
https://blog.famzah.net/2016/0...