Mostly that Javascript has a lot of new developers, new enough that they're easily influenced by hype. The Javascript community seems to over-emphasize having a pretty website rather than technical merit.
Also, that Javascript exists in an environment with a different set of problems than most others. Solutions have yet to be well fleshed out, and there are a lot of different ideas being tested. So even the more experienced devs are going to be more prone to create a shifting landscape.
Well, hold on. Intel gets the added slowdown that any I/O is going to take a lot more cycles to perform than it used to, but AMD isn't out of the hot seat either. The Spectre variant that AMD is also vulnerable to is going to cause an even larger general-purpose slowdown to fix. Any app with the fix will have effectively disabled branch target prediction, which many modern programming languages depend on being fast.
So for instance, the ~10% slowdown Intel measured on some worst-case Javascript is also going to apply to AMD. It might be more or less depending on how well optimized AMD's branch target prediction implementation is.
Google has created "retpoline", a technique which allows an indirect branch (e.g. a vtable call) to occur in a way that effectively disables speculative execution by isolating branch target prediction into a safe effectless loop. This addresses Variant 2 (aka Spectre).
Retpoline does not depend on or assist a CPU or an OS patch: it is done purely at the software level, per-app, by a compiler. There is no simple OS-wide patch.
Google says a retpoline call has performance "within cycles" of a regular old mispredicted branch. The zero-cost predictions we're used to are a thing of the past, because it effectively forces misprediction. I'd be curious to see a benchmark of an indirection-heavy platform like.NET.
This does not help address or optimize Variant 3, which is what the big kernel patches for Page Table Isolation are needed for. So, your I/O-dependent apps like databases are still going to take a big performance hit. Nor does it address Variant 1.
so many people are willing to believe that just $3000 in well placed Facebook ads is all it took to 'steal' an election.
It'd be convenient to dismiss if it was just Facebook ads, but it wasn't. The large number of fake comments all over Facebook, Twitter, Reddit, etc. designed to misinform and ultimately drive a deep wedge between US citizens. Trump has even been found retweeting some of these fake accounts.
Most under 20 are getting their entertainment from Youtube, Hulu, Netflix, etc. -- and I'd bet many kids under 10 are growing up without the classic TV experience that most adults remember. Hell, I know a kid who'd rather watch Youtube or Twitch than any TV show... and he tells me most of his class is the same way.
There's definitely room for a new internet provider, but I think cable is firmly and deservedly dying.
It's not racing, but drifting is definitely not just dumb showboating; there is actually a very high amount of skill involved. Mike participates in Formula Drift, which is the best of the best and is judged technically.
Author knows nothing about security. Updated crypto algorithms / libraries have next to nothing to do with application security. How many apps are hacked through outdated crypto algorithms?
You've missed the point. This is a second line of defense intended to protect your users after your app has been hacked, when the attacker has dumped your database of password hashes. It helps to prevent them from using GPU-accelerated brute forcing to reverse user passwords that would then be plugged into other websites.
The primary purpose of recent key derivation algorithms like Argon2 is to guard against GPU-accelerated brute-forcing. Traditional methods like salted hashes or PBKDF2 are otherwise still secure.
The Chinese have no expectation of "real news" -- *all* of their mainstream news is filtered through the lens of their government, and they know it.
In a small way this might put them at a better position than USA right now, where many people have a disconnect believing their news couldn't possibly be "fake news".
Perf is very important to me, so yes I've measured. You've reached a flawed conclusion from whatever you measured.
When I started writing C#, coming from C++ it would drive me nuts seeing all the blatantly wasted instructions, memory bloat, indirection, and extreme lack of locality that.NET has. It relies very heavily on the CPU's branch target prediction and cache to be reasonably fast, which has the effect of your "hot path" needing to be smaller in C# than it needs to be in C++.
It's been a decade since I started using C# and it still occasionally drives me nuts when I'm trying to write fast code. I do like C# for a number of its features, but performance is not one of them -- it is merely adequately fast for what I use it for.
To me, a C replacement needs a handful of things: portability, stability (language-wise), low-level hardware access, performance, and small size (both in terms of language and compiled code).
I'm all for a replacement being a safer-by-default language. The restriction on that, of course, being that I can also write unsafe code when I deem necessary and without jumping through hoops.
C++ absolutely fails the small size requirement, but in terms of safety I think it is on better ground: modern C++ practices are very much focused on easy to implement zero-cost abstractions that make code not only safer but more flexible.
Well written C# and Java is actually more efficient than C/++. Partially because it can do whole of program optimization. Partially because it can optimize for a particular processor rather than a generic one at a separate compile time. Partly because garbage collections minimizes the need to copy data structures (particularly in C++), and smart pointers are grossly inefficient compared to generational garbage collection. Partially because it allows focus on algorithms rather than fixing nasty bugs.
As someone who writes a ton of C# and C++... no. C# might be fast enough, and things trivially transcribed can be faster due to default implementations, but, C++ will literally always win in the end. It might take two or three times longer to write the C++, but it will win. That's kind of the reason C++ still exists: if you need to, you can make it fast. For everything else there's [insert high-level language here]. Because things like C# only let you go so far with optimization, and then C++ lets you go ten steps further.
The promise of "the JIT will just make it all faster in the end" is an old one that has been made for decades by JITed languages. The promise has never been fulfilled -- it's pie in the sky marketing fluff.
GC is good for certain highly scalable lock-free algorithms, though. I'll give it that. Not much else.
For what C is used for, none of those are even approaching "critical". A lot of criticism leveled at C and C++ these days tends to come from high-level devs who simply don't have enough context for what someone could want in an improved C. As someone who clearly has a better understanding, you could do better to rise above hyperbole.
At this point with C, there are very few things everyone can get behind as an improvement. A lot of people like it for its small non-magic surface area, and something like e.g. tagged unions would even be too much syntax sugar. I think if people wanted a broadly more powerful language they'd move right to C++, but they don't -- so we need to look at why that is, and maybe we'll have a better idea of what a "new C" could possibly look like.
Basically you're only buying from the third-party by name rather than in practice.
This is a really simplified view, and it's not special to Amazon. Third-party logistics is a huge business. Very few companies do their own warehousing/shipping -- even the large ones. Many 3PLs will also host a web store for you as a value-add.
Companies do this because it's not their core business. They want to focus on their product/marketing/purchasing/etc. -- the fulfillment of it is an important but small part of their business. And if you're really really small like many of the sellers on Amazon, then you might be even more laser focused and not want to manage your own web store.
This is my biggest worry about the Kingkiller Chronicle adaptation that's been hinted at for a while. The network will be looking at it to bring over the GoT audience, and the story will absolutely fall flat if they try to force it.
Anyone who's comparing LOtR to GoT clearly doesn't understand anything about Tolkien and why he was writing his stories.
Indeed. GRRM has specifically said he set out for GoT to be a "what happens after LotR" kind of story -- to see how a kingdom falls apart after the happy ending.
Phone vendors fragment themselves already. They try to differentiate themselves with custom launchers and apps for everything. I'd love for my V30 to get this new software without getting a hacked OS or APK, but I really don't see Google as being a primary contributor to fragmentation.
Modern development stacks using NuGet, NPM, Bower, etc. tend to make it exceedingly easy to insert someone else's code into your project without paying attention to licensing or vetting their code. And because of how easy it is to put your own stuff on these package managers, they're full of one-off projects that don't have the reliability or long-term maintenance of the major open-source projects.
I'd fully expect to see a ton of small companies (small enough to not have strict process) with horrible dependencies.
I had Windows 7, 8, and 10 phones -- the Samsung Focus, Lumia 920, and Lumia 950.
7, 8, and 8.1 were great. Excellent UI -- better than Android or iPhone in my opinion. Very usable, clean, and never laggy. It could easily run smooth on hardware Android would choke on.
10 has been a horrible experience. For the two years I had my Lumia 950, I had constant problems. A patch would fix one thing and break another. Bluetooth never worked reliably. It somtimes became slow --- slow like Android was slow -- for seemingly no reason at all until a reboot. About a year into the phone, a patch came out that made GPS sporadically stop working until rebooting the phone -- which only exacerbated the Bluetooth issues, as the phone would often not reconnect to my car after a reboot.
I now have an LG V30 that I picked up a few days ago. It is one of the few headphones not only keeping the headphone jack, but doubling down on it by making it super high quality -- I want to vote with my wallet. I'm not happy to be using Android, but I am *extremely* happy to not be using Windows 10 Mobile.
I can only imagine the massive costs Microsoft eat as a result of their mobile lineup. 7 was an all new shell. 8 dumped that shell for a new one, and also brought in the NT kernel. And finally 10 dumped the mobile shell to make the same code shared between desktop and mobile. That was a huge amount of churn.
Slashdot Mirror
Mostly that Javascript has a lot of new developers, new enough that they're easily influenced by hype. The Javascript community seems to over-emphasize having a pretty website rather than technical merit.
Also, that Javascript exists in an environment with a different set of problems than most others. Solutions have yet to be well fleshed out, and there are a lot of different ideas being tested. So even the more experienced devs are going to be more prone to create a shifting landscape.
Well, hold on. Intel gets the added slowdown that any I/O is going to take a lot more cycles to perform than it used to, but AMD isn't out of the hot seat either. The Spectre variant that AMD is also vulnerable to is going to cause an even larger general-purpose slowdown to fix. Any app with the fix will have effectively disabled branch target prediction, which many modern programming languages depend on being fast.
So for instance, the ~10% slowdown Intel measured on some worst-case Javascript is also going to apply to AMD. It might be more or less depending on how well optimized AMD's branch target prediction implementation is.
Google's technique ... has a small performance hit but much smaller than KPTI.
Keep in mind Google's technique (retpoline) is not an alternative to KPTI. Retpoline addresses Variant 2. KPTI addresses Variant 3. Both are required.
Google has created "retpoline", a technique which allows an indirect branch (e.g. a vtable call) to occur in a way that effectively disables speculative execution by isolating branch target prediction into a safe effectless loop. This addresses Variant 2 (aka Spectre).
Retpoline does not depend on or assist a CPU or an OS patch: it is done purely at the software level, per-app, by a compiler. There is no simple OS-wide patch.
Google says a retpoline call has performance "within cycles" of a regular old mispredicted branch. The zero-cost predictions we're used to are a thing of the past, because it effectively forces misprediction. I'd be curious to see a benchmark of an indirection-heavy platform like .NET.
This does not help address or optimize Variant 3, which is what the big kernel patches for Page Table Isolation are needed for. So, your I/O-dependent apps like databases are still going to take a big performance hit. Nor does it address Variant 1.
so many people are willing to believe that just $3000 in well placed Facebook ads is all it took to 'steal' an election.
It'd be convenient to dismiss if it was just Facebook ads, but it wasn't. The large number of fake comments all over Facebook, Twitter, Reddit, etc. designed to misinform and ultimately drive a deep wedge between US citizens. Trump has even been found retweeting some of these fake accounts.
Most under 20 are getting their entertainment from Youtube, Hulu, Netflix, etc. -- and I'd bet many kids under 10 are growing up without the classic TV experience that most adults remember. Hell, I know a kid who'd rather watch Youtube or Twitch than any TV show... and he tells me most of his class is the same way.
There's definitely room for a new internet provider, but I think cable is firmly and deservedly dying.
It's not racing, but drifting is definitely not just dumb showboating; there is actually a very high amount of skill involved. Mike participates in Formula Drift, which is the best of the best and is judged technically.
Author knows nothing about security. Updated crypto algorithms / libraries have next to nothing to do with application security. How many apps are hacked through outdated crypto algorithms?
You've missed the point. This is a second line of defense intended to protect your users after your app has been hacked, when the attacker has dumped your database of password hashes. It helps to prevent them from using GPU-accelerated brute forcing to reverse user passwords that would then be plugged into other websites.
The primary purpose of recent key derivation algorithms like Argon2 is to guard against GPU-accelerated brute-forcing. Traditional methods like salted hashes or PBKDF2 are otherwise still secure.
Bruce Perens is Bigfoot, confirmed.
Degaussing monitors. Strafe Jumping.
"scientist", really?
I mean... he has a hypothesis and he's testing it. Sounds like science. Still a nutjob.
The Chinese have no expectation of "real news" -- *all* of their mainstream news is filtered through the lens of their government, and they know it.
In a small way this might put them at a better position than USA right now, where many people have a disconnect believing their news couldn't possibly be "fake news".
Perf is very important to me, so yes I've measured. You've reached a flawed conclusion from whatever you measured.
When I started writing C#, coming from C++ it would drive me nuts seeing all the blatantly wasted instructions, memory bloat, indirection, and extreme lack of locality that .NET has. It relies very heavily on the CPU's branch target prediction and cache to be reasonably fast, which has the effect of your "hot path" needing to be smaller in C# than it needs to be in C++.
It's been a decade since I started using C# and it still occasionally drives me nuts when I'm trying to write fast code. I do like C# for a number of its features, but performance is not one of them -- it is merely adequately fast for what I use it for.
To me, a C replacement needs a handful of things: portability, stability (language-wise), low-level hardware access, performance, and small size (both in terms of language and compiled code).
I'm all for a replacement being a safer-by-default language. The restriction on that, of course, being that I can also write unsafe code when I deem necessary and without jumping through hoops.
C++ absolutely fails the small size requirement, but in terms of safety I think it is on better ground: modern C++ practices are very much focused on easy to implement zero-cost abstractions that make code not only safer but more flexible.
As someone who writes a ton of C# and C++... no. C# might be fast enough, and things trivially transcribed can be faster due to default implementations, but, C++ will literally always win in the end. It might take two or three times longer to write the C++, but it will win. That's kind of the reason C++ still exists: if you need to, you can make it fast. For everything else there's [insert high-level language here]. Because things like C# only let you go so far with optimization, and then C++ lets you go ten steps further.
The promise of "the JIT will just make it all faster in the end" is an old one that has been made for decades by JITed languages. The promise has never been fulfilled -- it's pie in the sky marketing fluff.
GC is good for certain highly scalable lock-free algorithms, though. I'll give it that. Not much else.
For what C is used for, none of those are even approaching "critical". A lot of criticism leveled at C and C++ these days tends to come from high-level devs who simply don't have enough context for what someone could want in an improved C. As someone who clearly has a better understanding, you could do better to rise above hyperbole.
At this point with C, there are very few things everyone can get behind as an improvement. A lot of people like it for its small non-magic surface area, and something like e.g. tagged unions would even be too much syntax sugar. I think if people wanted a broadly more powerful language they'd move right to C++, but they don't -- so we need to look at why that is, and maybe we'll have a better idea of what a "new C" could possibly look like.
Basically you're only buying from the third-party by name rather than in practice.
This is a really simplified view, and it's not special to Amazon. Third-party logistics is a huge business. Very few companies do their own warehousing/shipping -- even the large ones. Many 3PLs will also host a web store for you as a value-add.
Companies do this because it's not their core business. They want to focus on their product/marketing/purchasing/etc. -- the fulfillment of it is an important but small part of their business. And if you're really really small like many of the sellers on Amazon, then you might be even more laser focused and not want to manage your own web store.
This is my biggest worry about the Kingkiller Chronicle adaptation that's been hinted at for a while. The network will be looking at it to bring over the GoT audience, and the story will absolutely fall flat if they try to force it.
Anyone who's comparing LOtR to GoT clearly doesn't understand anything about Tolkien and why he was writing his stories.
Indeed. GRRM has specifically said he set out for GoT to be a "what happens after LotR" kind of story -- to see how a kingdom falls apart after the happy ending.
Gawker exhibited the worst of ethics free reporting and had the audacity to call it journalism.
I would have agreed with you a few years ago, but the unabashedly biased reporting being done today makes Gawker seem tame in comparison.
Maybe people with mental disorders are more likely to join Mensa.
Phone vendors fragment themselves already. They try to differentiate themselves with custom launchers and apps for everything. I'd love for my V30 to get this new software without getting a hacked OS or APK, but I really don't see Google as being a primary contributor to fragmentation.
Modern development stacks using NuGet, NPM, Bower, etc. tend to make it exceedingly easy to insert someone else's code into your project without paying attention to licensing or vetting their code. And because of how easy it is to put your own stuff on these package managers, they're full of one-off projects that don't have the reliability or long-term maintenance of the major open-source projects.
I'd fully expect to see a ton of small companies (small enough to not have strict process) with horrible dependencies.
I had Windows 7, 8, and 10 phones -- the Samsung Focus, Lumia 920, and Lumia 950.
7, 8, and 8.1 were great. Excellent UI -- better than Android or iPhone in my opinion. Very usable, clean, and never laggy. It could easily run smooth on hardware Android would choke on.
10 has been a horrible experience. For the two years I had my Lumia 950, I had constant problems. A patch would fix one thing and break another. Bluetooth never worked reliably. It somtimes became slow --- slow like Android was slow -- for seemingly no reason at all until a reboot. About a year into the phone, a patch came out that made GPS sporadically stop working until rebooting the phone -- which only exacerbated the Bluetooth issues, as the phone would often not reconnect to my car after a reboot.
I now have an LG V30 that I picked up a few days ago. It is one of the few headphones not only keeping the headphone jack, but doubling down on it by making it super high quality -- I want to vote with my wallet. I'm not happy to be using Android, but I am *extremely* happy to not be using Windows 10 Mobile.
I can only imagine the massive costs Microsoft eat as a result of their mobile lineup. 7 was an all new shell. 8 dumped that shell for a new one, and also brought in the NT kernel. And finally 10 dumped the mobile shell to make the same code shared between desktop and mobile. That was a huge amount of churn.