I went for a wife that may not be as sleek and sexy as some models, but has high functionality, low maintenance, and doesn't annoy me. Haven't had to replace/upgrade yet, so I think I made a good choice..
Given that JavaScript runs in the browser process, that's still dangerous. Even with process-per-tab isolation, JavaScript that exploits Spectre could potentially steal:
TLS session key
Cookies for a different domain that an asset is loaded from
Yeah, I don't get the Kinect hate. My brother went down the Xbox path because of the Kinect and the superior dancing games it supports. My kids had plenty of fun playing them at Christmas. It's not something I'm into, but my brother and my kids sure have fun with it.
It comes from the traditional Indian names for powers of ten. We follow the French system which goes "thousand" (10^3), "million" (10^6), etc. on powers of 10^3 In India, the first major division happens at 10^5, the "lakh", and it's every 10^2 from there onwards - 10^7 is the "crore", 10^9 is the "arab", then the next ones with special names are 10^15 the "padma" and 10^17 the "shankh". So when you're doing digit grouping, you group every two digits past 10^5, e.g. 1,23,45,678 (yeah, the asymmetry with the last three digits is a bit weird). It's nothing to do with superstition, just different traditional names for powers of ten. There's some info at Wikipedia. Note that India isn't the only country that doesn't think in powers of 10^3 - in Japan, the first major division happens at 10^4 (the "man").
You can't see past the limitations of your favourite tool. In C++ or other sane languages, a lot of things can be scoped so they can't be used before they're initialised. You get an error at compile time rather than having it blow up when code path is hit in production. You actually get tools to reduce mutable state, which allows for better optimisation as well as identifying a whole class of errors at compile time. Functional languages (e.g. Erlang or F#) do this even better. Your whole point seems to be that you use Python's exception tracebacks (which are no better than Java or C++ with symbols) to compensate for inadequate unit testing and not being able to control scope.
A mistake in my line of work can cost millions in seconds. If you want a program to blow up on accessing an uninitialised member in C++, use boost::optional (or std::optional if you're using C++17), or a dynamically allocated object so it'll fault on a null pointer access. In python, an attribute error could be caused by a typo, incomplete refactoring, or an API change that you didn't deal with properly, besides a value being used before it's initialised.
At any rate, this is the kind of thing that you should be capturing in unit tests, and if you're getting it in production, you're not the kind of person I'd want working on software where mistakes cost money/lives.
The problem with relying on disciplined developers to specify types in interfaces is that it breaks down in the real world. Everyone's subject to time pressure, stress, and other reasons to compromise. There's also nothing enforcing the types specified in the interface, and there's nothing enforcing the interface provided by those types. You really need 100% unit test coverage to ensure every code path accepts/yields the specified types. C++ at least ensures you can't inadvertently supply/return an unexpected type before you even get as far as running the unit test.
Pascal and ANSI C are very similar, but pre-ANSI C is a completely different beast, far more similar to BCPL. In fact, ANSI C could almost be described as Pascal with C syntax.
Pre-ANSI C didn't have prototypes - it assumed any undeclared name was an external function. It didn't automatically convert int to long if the function expected it, etc. - you had to explicitly cast. You had to be careful to cast results of functions correctly, too. All it had was a set of rules for how argument types were stacked, and it was up to you not to pass something a function wasn't expecting. This is closer to assembly language programming than Pascal or ANSI C.
I know I'll get flamed for this, but Python is really error-prone in a particular area, and that's its ridiculously weak name resolution rules. In a language like C, Perl, or even PHP, names are resolved during the compile phase. The compiler knows which definition of a name is going to be used at any point. Python doesn't have this - when it runs across a name, it walks up the scope hierarchy looking for a candidate.
This means that code can run happily for months or even years, until it just crashes with an undefined name error. This could be because of a rarely-used code path with a typo in it, botched refactoring of a rarely-used code path, or a particular set of rare circumstances where a global name isn't set before the code gets to a certain place.
The usual response is that unit tests should catch this. But let's face it, 100% unit test coverage is pretty rare, particularly for the kind of fast turnaround stuff that Python's frequently used for. Also, unit testing isn't necessarily going to simulate a corner case where a global doesn't get set before code that uses it executes. It also makes refactoring more risky because there's no point where the compiler can tell you you're referencing a name that's no longer defined, or no longer has a certain method/field.
This is the kind of area where it's really useful if the compiler can help you, and Python's ridiculously weak name resolution rules make that completely impossible.
What do you mean "NEC Town"? Fujitsu FM Towns was a DOS-based x86 multimedia computer (with a spin-off games console, the FM Towns Marty). NEC PC-98 series were DOS-based x86 PCs. The Sharp x68000 used a 68k CPU and ran the DOS-inspired HumanOS.
A wristwatch is still more practical than pulling your phone out in a lot of situations. Diving, cycling, surfing, even running. It's a lot easier and safer to glance at your wrist than to pull a phone out, and in some cases the phone wouldn't survive the activity at all.
Yeah, over the last couple of decades, Japanese porn has transitioned. Around 2000, pretty much all Japanese porn had condoms and ejaculation on chest or face. Now most of it's done without condoms with ejaculation in vagina more often than not ("nakadashi").
Had this problem a lot early on in the rollout by Coles and Woolworths in Australia, but over a year or so they made them far more forgiving. Never have a problem with them complaining about extra/missing weight any more.
No he isn't. He's US-born, raised and educated, graduating from one of your prestigious law schools and working as a lawyer for a glorious US telecommunications megacorporation. He's American through-and-through.
GM Volt/Bolt, Nissan Leaf, Mitsubishi MiEV or whatever it's called - all more affordable electric vehicles. In general I support not subsidising conspicuous consumption.
None of the Australian government IT incompetence surprises me. I know a lot of the people who work on these systems, and they're the kind of people who wouldn't get hired anywhere else. Don't get me wrong, a lot of them are really nice guys/gals and I'd have a beer with them any day of the week, they're just terrible developers. A lot of them were pushed by their parents to study computer science on the tail end of the dotcom bubble. Well-meaning parents thought they'd be setting up their kids for a safe and potentially lucrative career, but the kids really weren't interested in it and in many cases had no aptitude for it. So you ended up with a large oversupply of mediocre developers, who found it hard to find employment in the industry.
The government, wanting to at least appear to drag themselves into the 21st century, started hiring developers to build new internal systems and public-facing web sites for the Department of Social Security (DSS), Australian Taxation Office (ATO), Medicare, etc. The pay they offered wasn't great, and it often required you to move to Canberra. So they definitely weren't attracting the best and brightest, but it did allow a lot of these mediocre developers to get jobs that were enough to make their parents proud of them. But since they aren't really paid very well, and there's no tangible benefit for performing above average (e.g. can't get a bonus for landing a big sale by implementing a new feature), they don't have much of an incentive to work hard or skill up. So they muck around playing indoor cricket in the corridors, and playing CS:GO on the days when they're working from home.
Interestingly, some Australian government departments seem to be a lot more competent with their IT, notably the Department of Foreign Affairs and Trade (DFAT) and the Australian Securities and Investment Commission (ASIC). These departments spend a lot more time dealing with the businesses that bring money into the country (Australia is still very much a primary producer/exporter), so there seems to be a bit more pressure to have things working.
Where do you live? I pay close to $100/month for power in Australia when all I'm doing is running two Xeon servers (no lights, no heating, nothing else). My beer bill is a lot lower than my power bill. BTW you can buy me beer on Patreon if you have money you want to throw away;)
Bullshit. It was widely deployed in enterprise environments. Businesses were demanding higher-performance systems from Sun and Opteron 64 was all they could deliver. Businesses switched over as quickly as they could recompile in-house applications, and Java stuff just moved across.
SPARC was losing badly in price/performance by the point the 64-bit Opterons came along. The SunPro compilers, while having excellent code generation for SPARC, were clearly showing their age and lagging GCC and MSVC in C++ features. GCC had pretty poor SPARC code generation, but did quite well for x86-64. This meant with an x86-64 box running Solaria, you could get better performance and use a less frustrating compiler, without losing all your investment in the Solaris ecosystem. (Alpha was dead by that point, and Itanium was always a joke.)
The 64-bit AMD Opterons quickly gained a foothold in the server space, e.g. running Solaris. Also, Intel's first x86-64 implementation, the NetBurst-based Pentium D, had terrible performance per watt. The initial Intel Core CPUs lacked x86-64 support, and it wasn't until the Core 2 that they had a competitive offering. By this time, Windows for x86-64 was widespread.
Slashdot Mirror
I went for a wife that may not be as sleek and sexy as some models, but has high functionality, low maintenance, and doesn't annoy me. Haven't had to replace/upgrade yet, so I think I made a good choice..
Given that JavaScript runs in the browser process, that's still dangerous. Even with process-per-tab isolation, JavaScript that exploits Spectre could potentially steal:
Yeah, I don't get the Kinect hate. My brother went down the Xbox path because of the Kinect and the superior dancing games it supports. My kids had plenty of fun playing them at Christmas. It's not something I'm into, but my brother and my kids sure have fun with it.
It comes from the traditional Indian names for powers of ten. We follow the French system which goes "thousand" (10^3), "million" (10^6), etc. on powers of 10^3 In India, the first major division happens at 10^5, the "lakh", and it's every 10^2 from there onwards - 10^7 is the "crore", 10^9 is the "arab", then the next ones with special names are 10^15 the "padma" and 10^17 the "shankh". So when you're doing digit grouping, you group every two digits past 10^5, e.g. 1,23,45,678 (yeah, the asymmetry with the last three digits is a bit weird). It's nothing to do with superstition, just different traditional names for powers of ten. There's some info at Wikipedia. Note that India isn't the only country that doesn't think in powers of 10^3 - in Japan, the first major division happens at 10^4 (the "man").
You can't see past the limitations of your favourite tool. In C++ or other sane languages, a lot of things can be scoped so they can't be used before they're initialised. You get an error at compile time rather than having it blow up when code path is hit in production. You actually get tools to reduce mutable state, which allows for better optimisation as well as identifying a whole class of errors at compile time. Functional languages (e.g. Erlang or F#) do this even better. Your whole point seems to be that you use Python's exception tracebacks (which are no better than Java or C++ with symbols) to compensate for inadequate unit testing and not being able to control scope.
A mistake in my line of work can cost millions in seconds. If you want a program to blow up on accessing an uninitialised member in C++, use boost::optional (or std::optional if you're using C++17), or a dynamically allocated object so it'll fault on a null pointer access. In python, an attribute error could be caused by a typo, incomplete refactoring, or an API change that you didn't deal with properly, besides a value being used before it's initialised.
At any rate, this is the kind of thing that you should be capturing in unit tests, and if you're getting it in production, you're not the kind of person I'd want working on software where mistakes cost money/lives.
The problem with relying on disciplined developers to specify types in interfaces is that it breaks down in the real world. Everyone's subject to time pressure, stress, and other reasons to compromise. There's also nothing enforcing the types specified in the interface, and there's nothing enforcing the interface provided by those types. You really need 100% unit test coverage to ensure every code path accepts/yields the specified types. C++ at least ensures you can't inadvertently supply/return an unexpected type before you even get as far as running the unit test.
Pascal and ANSI C are very similar, but pre-ANSI C is a completely different beast, far more similar to BCPL. In fact, ANSI C could almost be described as Pascal with C syntax.
Pre-ANSI C didn't have prototypes - it assumed any undeclared name was an external function. It didn't automatically convert int to long if the function expected it, etc. - you had to explicitly cast. You had to be careful to cast results of functions correctly, too. All it had was a set of rules for how argument types were stacked, and it was up to you not to pass something a function wasn't expecting. This is closer to assembly language programming than Pascal or ANSI C.
I know I'll get flamed for this, but Python is really error-prone in a particular area, and that's its ridiculously weak name resolution rules. In a language like C, Perl, or even PHP, names are resolved during the compile phase. The compiler knows which definition of a name is going to be used at any point. Python doesn't have this - when it runs across a name, it walks up the scope hierarchy looking for a candidate.
This means that code can run happily for months or even years, until it just crashes with an undefined name error. This could be because of a rarely-used code path with a typo in it, botched refactoring of a rarely-used code path, or a particular set of rare circumstances where a global name isn't set before the code gets to a certain place.
The usual response is that unit tests should catch this. But let's face it, 100% unit test coverage is pretty rare, particularly for the kind of fast turnaround stuff that Python's frequently used for. Also, unit testing isn't necessarily going to simulate a corner case where a global doesn't get set before code that uses it executes. It also makes refactoring more risky because there's no point where the compiler can tell you you're referencing a name that's no longer defined, or no longer has a certain method/field.
This is the kind of area where it's really useful if the compiler can help you, and Python's ridiculously weak name resolution rules make that completely impossible.
I don't know the price for a Black Hawk, but in the late '90s, a rotor blade for a Bell JetRanger cost about AU$30,000.
Australia managed to switch to metric without that kind of upheaval. The two aren't necessarily tied together.
What the hell were you calling a Mac XL then? The only thing called a Mac XL was the eX-Lisa, hence the initialism.
What do you mean "NEC Town"? Fujitsu FM Towns was a DOS-based x86 multimedia computer (with a spin-off games console, the FM Towns Marty). NEC PC-98 series were DOS-based x86 PCs. The Sharp x68000 used a 68k CPU and ran the DOS-inspired HumanOS.
A wristwatch is still more practical than pulling your phone out in a lot of situations. Diving, cycling, surfing, even running. It's a lot easier and safer to glance at your wrist than to pull a phone out, and in some cases the phone wouldn't survive the activity at all.
Gorillas in the Amazon? That's less plausible than UFOs. What's this bus driver smoking?
Yeah, over the last couple of decades, Japanese porn has transitioned. Around 2000, pretty much all Japanese porn had condoms and ejaculation on chest or face. Now most of it's done without condoms with ejaculation in vagina more often than not ("nakadashi").
Had this problem a lot early on in the rollout by Coles and Woolworths in Australia, but over a year or so they made them far more forgiving. Never have a problem with them complaining about extra/missing weight any more.
No he isn't. He's US-born, raised and educated, graduating from one of your prestigious law schools and working as a lawyer for a glorious US telecommunications megacorporation. He's American through-and-through.
GM Volt/Bolt, Nissan Leaf, Mitsubishi MiEV or whatever it's called - all more affordable electric vehicles. In general I support not subsidising conspicuous consumption.
None of the Australian government IT incompetence surprises me. I know a lot of the people who work on these systems, and they're the kind of people who wouldn't get hired anywhere else. Don't get me wrong, a lot of them are really nice guys/gals and I'd have a beer with them any day of the week, they're just terrible developers. A lot of them were pushed by their parents to study computer science on the tail end of the dotcom bubble. Well-meaning parents thought they'd be setting up their kids for a safe and potentially lucrative career, but the kids really weren't interested in it and in many cases had no aptitude for it. So you ended up with a large oversupply of mediocre developers, who found it hard to find employment in the industry.
The government, wanting to at least appear to drag themselves into the 21st century, started hiring developers to build new internal systems and public-facing web sites for the Department of Social Security (DSS), Australian Taxation Office (ATO), Medicare, etc. The pay they offered wasn't great, and it often required you to move to Canberra. So they definitely weren't attracting the best and brightest, but it did allow a lot of these mediocre developers to get jobs that were enough to make their parents proud of them. But since they aren't really paid very well, and there's no tangible benefit for performing above average (e.g. can't get a bonus for landing a big sale by implementing a new feature), they don't have much of an incentive to work hard or skill up. So they muck around playing indoor cricket in the corridors, and playing CS:GO on the days when they're working from home.
Interestingly, some Australian government departments seem to be a lot more competent with their IT, notably the Department of Foreign Affairs and Trade (DFAT) and the Australian Securities and Investment Commission (ASIC). These departments spend a lot more time dealing with the businesses that bring money into the country (Australia is still very much a primary producer/exporter), so there seems to be a bit more pressure to have things working.
Pretty much all the phone makers. None of the flagship LG or Samsung phones will stay charged at full CPU load.
Where do you live? I pay close to $100/month for power in Australia when all I'm doing is running two Xeon servers (no lights, no heating, nothing else). My beer bill is a lot lower than my power bill. BTW you can buy me beer on Patreon if you have money you want to throw away ;)
Gangnam Style is East Asian, not South Asian.
Bullshit. It was widely deployed in enterprise environments. Businesses were demanding higher-performance systems from Sun and Opteron 64 was all they could deliver. Businesses switched over as quickly as they could recompile in-house applications, and Java stuff just moved across.
SPARC was losing badly in price/performance by the point the 64-bit Opterons came along. The SunPro compilers, while having excellent code generation for SPARC, were clearly showing their age and lagging GCC and MSVC in C++ features. GCC had pretty poor SPARC code generation, but did quite well for x86-64. This meant with an x86-64 box running Solaria, you could get better performance and use a less frustrating compiler, without losing all your investment in the Solaris ecosystem. (Alpha was dead by that point, and Itanium was always a joke.)
The 64-bit AMD Opterons quickly gained a foothold in the server space, e.g. running Solaris. Also, Intel's first x86-64 implementation, the NetBurst-based Pentium D, had terrible performance per watt. The initial Intel Core CPUs lacked x86-64 support, and it wasn't until the Core 2 that they had a competitive offering. By this time, Windows for x86-64 was widespread.