The secret to very good managers I've worked with is that they realize that the staff working under them does have more talent than the management does.
As someone who has been managed by a very good manager earlier in my career, I'd modify the above slightly. Specifically, very good managers realise that the staff working under them have far more talent at the jobs they were hired to do.
OTOH, very good managers almost always have far more talent at the job they were hired to do (managing) than do the staff under them.
They have a monospaced typeface, but it's not useable for programming - doesn't even have a significant distinction between zero and O, let alone any other programmer-friendly features.
Since I presume they're going to want people at Google to use Noto as standard, it seems sensible to me that they create a programmers' version.
If you're not ready to commit to Windows 10 yet, I would recommend getting your machine registered within the free period, then revert to the previous version.
There are 2 ways to do this:
1. Upgrade your existing OS, then roll back. Obviously this has some risks in terms of drivers, etc.
2. Clean install Win 10 on a different partition/drive, using the product key from your existing Windows install (not sure if this will work for OEM systems after extracting the product key). Then you can either dual-boot, or simply go back to using the previous OS.
The first release of pypy (well, technically pypy3) that supported Python 3 was over a year ago (February 2015). However it is still Python 3.2.5 (they're working on 3.3+ support).
Regarding the rest of your post, a common approach is to write the low-level access code in C and everything on top in Python. The C code can release the GIL (only need to reacquire it if calling back into the Python subsystem).
In Mercurial I just create a new named branch (an optional step, but I prefer it), do in-progress commits and change the phase to secret (so they can't be pushed to another repository until the phase is changed back to draft).
Once I've got things to the desired code I modify and rebase the changesets until I have the series I want. Basically exactly the same process - secret commits provide essentially the same functionality as the git stash, but since they're just changesets in the graph it's one fewer concept to learn. There are various extensions that people like to use, but I find that just the base rebase + the Facebook-developed commit --amend --rebase extension gives me all the power I need.
If you enable changeset evolution then you don't even need to worry about putting commits into the secret phase - you can push, pull and modify history as you like and let changeset evolution propagate obsolescence markers to other repos. However I'm still not 100% ready to change over to evolution yet - I still see too much churn on it on the mercurial-devel list for my taste.
I feel your pain. With a bit of work, it is possible to use Mercurial for your day-to-day work, and then ClearCase Remote Client (or whatever it's called now) to sync to ClearCase. I know - I've done it.
The biggest issue is ensuring that the timestamps are as CCRC expects - the.ccrc files (I think that's right - it's been about 5 years) hold the timestamps in a somewhat obfuscated format.
I hated plasma screens - they always looked "smeary" to me. Only way I can think of to describe it. Maybe I only saw bad ones, but I saw enough to think that's unlikely.
Thanks - didn't turn up in my web searches (except for disambiguation #5 on Wikipedia) and considering I was born in the same year as Land of the Lost started it's not surprising I wasn't aware of the link.
Whilst this is currently true, the situation is improving rapidly. I've been periodically testing the OpenELEC Kodi Jarvis alpha builds on my Raspberry Pi 2.
The previous time I tested it (a month or so ago), 720p HEVC was just playable - ~100% CPU on both cores, but only dropping the occasional frame. The time before that, 720p HEVC was unwatchable. But with build #1016 (which includes FFMPEG 2.8.1) I was getting smooth playback and averaging around 60% CPU on both cores.
HEVC will obviously never have the same hardware requirements that h264 does now, but there is a lot of work currently going into reducing the requirements.
Of course, I'd much prefer that royalty-free codecs take the fore.
We had a program that was doing session matching of RTP streams (via RTCP). We had to be able to handle a potentially very high load.
Things had been going OK - development progressing, QA testing going well. And then one day our scaling tests took a nosedive. Whereas we had been handling tens of thousands of RTP sessions with decent CPU load, suddenly we were running at 100% CPU with an order of magnitude fewer sessions.
I spent over a week inspecting recent commits, profiling, etc. I could see where it was happening in a general sense, but couldn't pin down the precise cause. And then a comment by one of the other developers connected up with everything I'd been looking at.
Turns out that we had been using a single instance of an object to handle all sessions going through a particular server, but that resulted in incorrect matching - it was missing a vital identifier. So an additional field had been added to hold the conversation ID, and an instance was created for each conversation.
Now, that in itself wasn't an issue - but the objects were stored in a hash table. Objects for the same server but different conversations compared non-equal... but the conversation ID hadn't been included as part of the hashcode calculation. So all conversation objects for a particular server would hash the same (but compare different).
We had 3 servers and tens of thousands of conversations between endpoints. Instead of the respective server objects being approximately evenly spread across the hash map, they were all stuck into a single bucket per server... so instead of a nice amortised O(1) lookup, we instead effectively had an O(N) lookup for these objects - and they were being looked up a lot.
The effect was completely invisible under low load and in unit tests. The hash codes weren't verified as being different in the unit tests as there was the theoretical possibility that the hashcodes being verified as different could end up the same with a new version of the compiler/library/etc.
I use an ISP with an Australia call centre, with call centre staff who actually have the latitude and training to recognise that I know what I'm talking about and go off-script.
What I'm getting is actually irrelevant to how Turnbull has acted, but for full disclosure, I was due to have had FTTP build in progress by now. I'm currently slated to have FTTN build started sometime in the 12 months. And I will be paying the money to apply for FoD and we'll see just how eager they are to follow up with that...
If I had been in a fixed wireless area I'd have been pretty happy - I probably would have had it by now, and could have been on the 50/20 trial (my ISP is part of the trial).
Nothing Malcolm Turnbull says should be believed. There have been calls by this same government that using a VPN should be illegal, and it wouldn't surprise me in the slightest if they tried to get legislation to that effect passed.
Go read up on exactly what Turnbull (and the current government) promised about the NBN prior to the last election and everything that has gone on since.
Not only has he broken every promise or implied promise that he made before the election, but he's then gone on to make further promises that he's continued to break. Is a country using FTTN? Point at them as a shining example. Does that same country then switch away from FTTN? Either misrepresent what they're doing, or never mention them again!
The man is a consumate politician - never answers a question; immediately attacks all critics; and both claims credit for everything the previous government did (or set up and couldn't be stopped) and blames them for all the failings of the current government in the same breath. And somehow manages to keep a lot of people believing that he actually knows what he's talking about and should be believed.
The only thing he's kept to has been Tony Abbot's directive to "destroy the NBN".
If blood were taken that way, I think you'd probably get a very different type of person doing it. SLAP, SLAP, SLAP - nope, the vein still hasn't risen up, time to get the paddles;)
On a serious note, many thanks to James and the researchers who discovered this. Wasn't an issue for my family (Dad O-, mum O+, and my sister is O+ so OK for her too) but a literal lifesaver for many other families.
If you know the password, your (human) perception would be that it takes slightly longer to open. The actual processing time required though would be significantly greater.
If you don't know the password, it takes that extra processing time *for each password you try* i.e. it's multiplicative. So if you're trying 300 passwords, for the part which takes 300x as long per password, it's now 90000x as long (for that part) to go through the full list.
I work from home ~95% of the time. I try to stick to a 40-hour week, but quite often I push into 45 or 50 hours.
The thing is, I don't have a commute. I start working almost immediately after waking up; eat breakfast while going through emails from the US; take a few breaks during the day (including for lunch), and usually finish around 3pm.
But if I'm heavily involved in something (I'm a software developer), I might keep working until 5pm, or even dinner. If I do that a couple of times in the week, I've hit 45+ hours.
I had a commute, that would be 40 hours a week *plus* 5-10 hours depending on traffic. Plus as a contractor I'm billing for all the hours I work...
Slashdot Mirror
As someone who has been managed by a very good manager earlier in my career, I'd modify the above slightly. Specifically, very good managers realise that the staff working under them have far more talent at the jobs they were hired to do.
OTOH, very good managers almost always have far more talent at the job they were hired to do (managing) than do the staff under them.
They have a monospaced typeface, but it's not useable for programming - doesn't even have a significant distinction between zero and O, let alone any other programmer-friendly features.
Since I presume they're going to want people at Google to use Noto as standard, it seems sensible to me that they create a programmers' version.
And the XBMC Foundation is trying its best to break this perceived association.
https://kodi.tv/the-piracy-box...
If you're not ready to commit to Windows 10 yet, I would recommend getting your machine registered within the free period, then revert to the previous version.
There are 2 ways to do this:
1. Upgrade your existing OS, then roll back. Obviously this has some risks in terms of drivers, etc.
2. Clean install Win 10 on a different partition/drive, using the product key from your existing Windows install (not sure if this will work for OEM systems after extracting the product key). Then you can either dual-boot, or simply go back to using the previous OS.
The first release of pypy (well, technically pypy3) that supported Python 3 was over a year ago (February 2015). However it is still Python 3.2.5 (they're working on 3.3+ support).
Regarding the rest of your post, a common approach is to write the low-level access code in C and everything on top in Python. The C code can release the GIL (only need to reacquire it if calling back into the Python subsystem).
Have a look at cffi.
That would be pypy.
In Mercurial I just create a new named branch (an optional step, but I prefer it), do in-progress commits and change the phase to secret (so they can't be pushed to another repository until the phase is changed back to draft).
Once I've got things to the desired code I modify and rebase the changesets until I have the series I want. Basically exactly the same process - secret commits provide essentially the same functionality as the git stash, but since they're just changesets in the graph it's one fewer concept to learn. There are various extensions that people like to use, but I find that just the base rebase + the Facebook-developed commit --amend --rebase extension gives me all the power I need.
If you enable changeset evolution then you don't even need to worry about putting commits into the secret phase - you can push, pull and modify history as you like and let changeset evolution propagate obsolescence markers to other repos. However I'm still not 100% ready to change over to evolution yet - I still see too much churn on it on the mercurial-devel list for my taste.
I feel your pain. With a bit of work, it is possible to use Mercurial for your day-to-day work, and then ClearCase Remote Client (or whatever it's called now) to sync to ClearCase. I know - I've done it.
The biggest issue is ensuring that the timestamps are as CCRC expects - the .ccrc files (I think that's right - it's been about 5 years) hold the timestamps in a somewhat obfuscated format.
I hated plasma screens - they always looked "smeary" to me. Only way I can think of to describe it. Maybe I only saw bad ones, but I saw enough to think that's unlikely.
I also hated the amount of heat they put out ...
Thanks - didn't turn up in my web searches (except for disambiguation #5 on Wikipedia) and considering I was born in the same year as Land of the Lost started it's not surprising I wasn't aware of the link.
Seems like a company we can trust with people's lives.
Whilst this is currently true, the situation is improving rapidly. I've been periodically testing the OpenELEC Kodi Jarvis alpha builds on my Raspberry Pi 2.
The previous time I tested it (a month or so ago), 720p HEVC was just playable - ~100% CPU on both cores, but only dropping the occasional frame. The time before that, 720p HEVC was unwatchable. But with build #1016 (which includes FFMPEG 2.8.1) I was getting smooth playback and averaging around 60% CPU on both cores.
HEVC will obviously never have the same hardware requirements that h264 does now, but there is a lot of work currently going into reducing the requirements.
Of course, I'd much prefer that royalty-free codecs take the fore.
We had a program that was doing session matching of RTP streams (via RTCP). We had to be able to handle a potentially very high load.
Things had been going OK - development progressing, QA testing going well. And then one day our scaling tests took a nosedive. Whereas we had been handling tens of thousands of RTP sessions with decent CPU load, suddenly we were running at 100% CPU with an order of magnitude fewer sessions.
I spent over a week inspecting recent commits, profiling, etc. I could see where it was happening in a general sense, but couldn't pin down the precise cause. And then a comment by one of the other developers connected up with everything I'd been looking at.
Turns out that we had been using a single instance of an object to handle all sessions going through a particular server, but that resulted in incorrect matching - it was missing a vital identifier. So an additional field had been added to hold the conversation ID, and an instance was created for each conversation.
Now, that in itself wasn't an issue - but the objects were stored in a hash table. Objects for the same server but different conversations compared non-equal ... but the conversation ID hadn't been included as part of the hashcode calculation. So all conversation objects for a particular server would hash the same (but compare different).
We had 3 servers and tens of thousands of conversations between endpoints. Instead of the respective server objects being approximately evenly spread across the hash map, they were all stuck into a single bucket per server ... so instead of a nice amortised O(1) lookup, we instead effectively had an O(N) lookup for these objects - and they were being looked up a lot.
The effect was completely invisible under low load and in unit tests. The hash codes weren't verified as being different in the unit tests as there was the theoretical possibility that the hashcodes being verified as different could end up the same with a new version of the compiler/library/etc.
I use an ISP with an Australia call centre, with call centre staff who actually have the latitude and training to recognise that I know what I'm talking about and go off-script.
And yes, I do pay a premium for that.
What I'm getting is actually irrelevant to how Turnbull has acted, but for full disclosure, I was due to have had FTTP build in progress by now. I'm currently slated to have FTTN build started sometime in the 12 months. And I will be paying the money to apply for FoD and we'll see just how eager they are to follow up with that ...
If I had been in a fixed wireless area I'd have been pretty happy - I probably would have had it by now, and could have been on the 50/20 trial (my ISP is part of the trial).
Nothing Malcolm Turnbull says should be believed. There have been calls by this same government that using a VPN should be illegal, and it wouldn't surprise me in the slightest if they tried to get legislation to that effect passed.
Go read up on exactly what Turnbull (and the current government) promised about the NBN prior to the last election and everything that has gone on since.
Not only has he broken every promise or implied promise that he made before the election, but he's then gone on to make further promises that he's continued to break. Is a country using FTTN? Point at them as a shining example. Does that same country then switch away from FTTN? Either misrepresent what they're doing, or never mention them again!
The man is a consumate politician - never answers a question; immediately attacks all critics; and both claims credit for everything the previous government did (or set up and couldn't be stopped) and blames them for all the failings of the current government in the same breath. And somehow manages to keep a lot of people believing that he actually knows what he's talking about and should be believed.
The only thing he's kept to has been Tony Abbot's directive to "destroy the NBN".
My guess is he's left-handed. When they take blood they recommend taking it from your non-primary arm unless there's a specific reason not to.
That would be "Golden Arse".
If blood were taken that way, I think you'd probably get a very different type of person doing it. SLAP, SLAP, SLAP - nope, the vein still hasn't risen up, time to get the paddles ;)
On a serious note, many thanks to James and the researchers who discovered this. Wasn't an issue for my family (Dad O-, mum O+, and my sister is O+ so OK for her too) but a literal lifesaver for many other families.
If you know the password, your (human) perception would be that it takes slightly longer to open. The actual processing time required though would be significantly greater.
If you don't know the password, it takes that extra processing time *for each password you try* i.e. it's multiplicative. So if you're trying 300 passwords, for the part which takes 300x as long per password, it's now 90000x as long (for that part) to go through the full list.
http://www.pccasegear.com/inde...
I used to buy from AusPC Market a long time ago. These days I normally use PC Case Gear.
Our current government are arseholes. Yes, I am saying the other mob is better. Not much better perhaps, but better than this bunch of complete dicks.
Don't get me started on what they've done to our National Broadband Network.
No, I didn't vote for them.
So exactly what do you get with Groovy that you don't get with Jython (Python on the Java VM)? Apart from different syntax of course ...
One of the great things about Python is it runs just about anywhere. There are even embedded versions.
The only real problem with Jython is it doesn't implement Python 3 yet.
And of course, typo. "... pretty much".
https://github.com/OpenELEC/Op...
Just determined in the last week to be due to async suspend/resume. From the various reports, oretty much all Intel hardware is affected.
I work from home ~95% of the time. I try to stick to a 40-hour week, but quite often I push into 45 or 50 hours.
The thing is, I don't have a commute. I start working almost immediately after waking up; eat breakfast while going through emails from the US; take a few breaks during the day (including for lunch), and usually finish around 3pm.
But if I'm heavily involved in something (I'm a software developer), I might keep working until 5pm, or even dinner. If I do that a couple of times in the week, I've hit 45+ hours.
I had a commute, that would be 40 hours a week *plus* 5-10 hours depending on traffic. Plus as a contractor I'm billing for all the hours I work ...