No kidding. The thing continually suggests that Linux is insecure on all number of ways (none are mentioned specifically), and that Linus is indifferent toward security. It has this completely useless statement to try to create a false association between Linux and the Ashley Madison hack:
Versions of Linux have proved vulnerable to serious bugs in recent years. AshleyMadison.com, the Web site that facilitates extramarital affairs and suffered an embarrassing data breach in July, was reportedly running Linux on its servers, as do many companies.
Those problems did not involve the kernel itself,...
The problem with the language they used is that any protocol they can't explicitly classify can be assumed to be encrypted. You run the risk of an unencrypted Youtube video getting prioritized over games, or whatever else is using custom protocols.
They should not be the ones to hold these reins. And I think that's the whole hold-up -- their focus is obviously that they want control, not so much that they want to limit bandwidth. Really, pretty much everyone involved who they consider a bandwidth hog would be happy to cooperate if tech was there to facilitate.
We should instead mandate that ISPs support an opt-in depriortization through some QoS extension to IPv6. I'm sure Netflix/etc. would cooperate marking their traffic as bulk if they could actually specify best-effort latency/throughput guarantees and configure their software to buffer/etc. to work with it. P2P software would probably be a good citizen too.
I just had to post something against the classic/. hivemind. What do I do to myself. You see, I mentioned APIs specifically, because I was talking about their APIs. Not Office. Not their latest shiny UI throw up. Their APIs. I'm a dev, I've been using their APIs extensively for close to two decades, and that's the perspective I wanted to give. I wasn't commenting on the quality of Linux vs Windows IOT, or the benefits (or lack thereof) of backward compatibility.
you can go look up how.NET's incompatibilities between versions cause havoc. Don't forget to look up Win32 System API calls, especially in the security area.
Yes, you can.
Newer.NET versions tend to, in the vast majority of cases, be backwards compatible with apps compiled for older versions. They have broken this in some very niche cases, but only where strongly justified. Their wont for backward compatibility is so great, they will leave in bugs and even keep the internal structure of objects the same to ensure any apps relying on that continue to work. I've submitted my share of bugs that ended up in the "won't fix" pile due to this.
Their Win32 API is probably the single largest working example of "backward compatible" you'll find in an API. The thing is for better or worse riddled with deprecated functionality, "Ex" functions to replace it, and structs which need to know their own size. Run an old Win32 app from the Windows 95 days and there's a really good chance it'll still work today. There are very few cases where they've made something specifically not work, and that has sometimes been because people have been using it wrong to the detriment of the user (i.e. retrieving the Windows version).
Their driver side tends to fluctuate a bit more as they make performance or safety enhancements by replacing the various APIs, but there's really no way around that.
Dumping a system that works and does what I want for a system that spies on me and will change at the whim of its maker with but a "swallow bitch" if I complain.
You jest, but Windows is far and above king of backward compatibility as far as APIs are concerned.
One does wonder how efficient it is compared to Linux, though.
Last time DX12 benchmarks were posted, NVIDIA flipped their lid --- DX12 seemed to only hurt their performance, while it gave AMD an easy 25-50% boost and let them catch up to NVIDIA's DX11 numbers.
This time, no such comparison. I wonder why.
With a Geforce 980 Ti, I get wildly variant 30-60fps in ARK. Conversely, Unreal Tournament 4 gives me a flat 144fps. Both at max settings.
I feel like ARK is probably just horribly unoptimized with all the custom effects they've added in.
Just like "don't use goto", or "don't use threads", etc., these guidelines and recommendations are really great to prevent beginners from making hard to spot errors, but all those variations and features exist for a reason and have a use.
Ok, my basic question is...What the hell is an immobilizer chip?
Just about all cars made in the last several years have immobilizer chips in their keys. When you start the car, the chip is read and the car won't start if it is missing or has an unknown identifier. If you've ever had to replace a key, this is why that is so expensive.
It's designed to make cars harder to steal. There is no remote capability.
It seems the long-term solution will involve eye tracking so that the device can "focus" with you. Tough problem, I imagine, to solve in such a tiny area without interfering with the experience. It would also likely need even better latency than the current setup, which is asking a lot.
The feature is dual-purpose. In AMD's case, it was originally created to improve latency and quality of wireless display tech. That it worked for games too was just a happy coincidence they took advantage of a while later.
Don't forget high-fps monitors, which is an even harder problem to solve than resolution. I've got an overclocked Geforce 980 Ti (faster than the Fury X) and it still can't manage 1080p @ 144hz in many games.
Last summer I bought a Nvidia Tegra Note 7 tablet based on promises that Android 5 (Lollipop) was coming out for it "real soon". They even stated that it was easy to port Lollipop on the Tegra Note 7 since it was basically a stock Android design with little or on deviation from the standard design. That "real soon" slipped to February of 2015 and when February 2015 came and went Nvidia became strangely mute on the subject, ignoring customers' inquiries.
What you describe is basically every tablet seller out there save for Google themselves. They save the new versions for their upcoming products, and only after those get put out do they update the old stuff.
Weight plays a lot into our perception for how solid and well built things are, even when they're not. Lightweight is great, but go too far and things feel like a fragile toy.
This is almost too good a problem to have with a laptop -- too lightweight? Put more battery in it.
A good shard (UO-speak for a custom server) would have great GMs regularly creating events for their players. I've played through a week-long monster invasion on Minoc, a war between Trinsic and Yew, a murder mystery involving 100+ players, and more custom "dungeon" areas than I can count. The last dungeon I remember was a play on Alice in Wonderland.
I haven't played UO in about 10 years, but custom shards gave hands down the best MMO experience I've ever seen even compared to current games.
Diablo had procedurally generated levels back in 1997. I'm sure other games came before it. This is a bit more interesting because the procedure was learned, not explicitly programmed.
I was very upset to hear this last night. My favorite composition from him was Casper's Lullaby -- beautiful, haunting, and simple. They are what inspired me to learn piano in my 20s.
When is it better to choose the well-tested, mature LAMP over this upstart collection of JavaScript-centric technologies?
JavaScript in its current form will never have a place larger than simple website scripting in my production environment -- it's unmaintainable in anything beyond small doses and is something we work with because there's literally no other option, not because we want to. TypeScript makes things better, but being better than JavaScript really isn't that tough. It's still not as good as -- and doesn't provide benefits instead of -- existing common backend languages like Java and C#.
To me, node.js perfectly represents the age of programming we're in: people are doing things because they can, not because they should. Things that would have been just-for-fun geeky side projects 10 years ago are now somehow making their way into legitimate business-critical projects.
Shuttle makes fanless VESA-mountable PCs that use the low power Atom CPUs. This would be a great use for them.
No kidding. The thing continually suggests that Linux is insecure on all number of ways (none are mentioned specifically), and that Linus is indifferent toward security. It has this completely useless statement to try to create a false association between Linux and the Ashley Madison hack:
Versions of Linux have proved vulnerable to serious bugs in recent years. AshleyMadison.com, the Web site that facilitates extramarital affairs and suffered an embarrassing data breach in July, was reportedly running Linux on its servers, as do many companies. Those problems did not involve the kernel itself,...
Came here for this. Tech writers should not be able to get away with using nonsense metrics.
It's not unprecedented. See for instance the "red black tree".
The problem with the language they used is that any protocol they can't explicitly classify can be assumed to be encrypted. You run the risk of an unencrypted Youtube video getting prioritized over games, or whatever else is using custom protocols.
They should not be the ones to hold these reins. And I think that's the whole hold-up -- their focus is obviously that they want control, not so much that they want to limit bandwidth. Really, pretty much everyone involved who they consider a bandwidth hog would be happy to cooperate if tech was there to facilitate.
We should instead mandate that ISPs support an opt-in depriortization through some QoS extension to IPv6. I'm sure Netflix/etc. would cooperate marking their traffic as bulk if they could actually specify best-effort latency/throughput guarantees and configure their software to buffer/etc. to work with it. P2P software would probably be a good citizen too.
There is no safe place to put your data. If someone wants it they'll get it. If you want to keep something private, encrypt it.
I just had to post something against the classic /. hivemind. What do I do to myself. You see, I mentioned APIs specifically, because I was talking about their APIs. Not Office. Not their latest shiny UI throw up. Their APIs. I'm a dev, I've been using their APIs extensively for close to two decades, and that's the perspective I wanted to give. I wasn't commenting on the quality of Linux vs Windows IOT, or the benefits (or lack thereof) of backward compatibility.
you can go look up how .NET's incompatibilities between versions cause havoc. Don't forget to look up Win32 System API calls, especially in the security area.
Yes, you can.
Newer .NET versions tend to, in the vast majority of cases, be backwards compatible with apps compiled for older versions. They have broken this in some very niche cases, but only where strongly justified. Their wont for backward compatibility is so great, they will leave in bugs and even keep the internal structure of objects the same to ensure any apps relying on that continue to work. I've submitted my share of bugs that ended up in the "won't fix" pile due to this.
Their Win32 API is probably the single largest working example of "backward compatible" you'll find in an API. The thing is for better or worse riddled with deprecated functionality, "Ex" functions to replace it, and structs which need to know their own size. Run an old Win32 app from the Windows 95 days and there's a really good chance it'll still work today. There are very few cases where they've made something specifically not work, and that has sometimes been because people have been using it wrong to the detriment of the user (i.e. retrieving the Windows version).
Their driver side tends to fluctuate a bit more as they make performance or safety enhancements by replacing the various APIs, but there's really no way around that.
Dumping a system that works and does what I want for a system that spies on me and will change at the whim of its maker with but a "swallow bitch" if I complain.
You jest, but Windows is far and above king of backward compatibility as far as APIs are concerned.
One does wonder how efficient it is compared to Linux, though.
DX12 was more about helping low-end CPUs, or let higher-end CPUs push more geometry. It doesn't do much to help GPUs.
Last time DX12 benchmarks were posted, NVIDIA flipped their lid --- DX12 seemed to only hurt their performance, while it gave AMD an easy 25-50% boost and let them catch up to NVIDIA's DX11 numbers. This time, no such comparison. I wonder why.
With a Geforce 980 Ti, I get wildly variant 30-60fps in ARK. Conversely, Unreal Tournament 4 gives me a flat 144fps. Both at max settings. I feel like ARK is probably just horribly unoptimized with all the custom effects they've added in.
Just like "don't use goto", or "don't use threads", etc., these guidelines and recommendations are really great to prevent beginners from making hard to spot errors, but all those variations and features exist for a reason and have a use.
Just about all cars made in the last several years have immobilizer chips in their keys. When you start the car, the chip is read and the car won't start if it is missing or has an unknown identifier. If you've ever had to replace a key, this is why that is so expensive.
It's designed to make cars harder to steal. There is no remote capability.
It seems the long-term solution will involve eye tracking so that the device can "focus" with you. Tough problem, I imagine, to solve in such a tiny area without interfering with the experience. It would also likely need even better latency than the current setup, which is asking a lot.
SSDs get their speed from being essentially a RAID-0 of several NAND chips. Individually, they're a good bit slower.
The feature is dual-purpose. In AMD's case, it was originally created to improve latency and quality of wireless display tech. That it worked for games too was just a happy coincidence they took advantage of a while later.
I've never used Raptr, because I've heard it's so terrible, but they do have an SDK for it and I have used that.
Both NVIDIA and AMD have methods of capturing directly on the GPU, making for a blissfully lag-free experience compared to, say, FRAPS.
Hopefully Windows has created a standard interface for these, and not just reimplemented FRAPS.
Don't forget high-fps monitors, which is an even harder problem to solve than resolution. I've got an overclocked Geforce 980 Ti (faster than the Fury X) and it still can't manage 1080p @ 144hz in many games.
Last summer I bought a Nvidia Tegra Note 7 tablet based on promises that Android 5 (Lollipop) was coming out for it "real soon". They even stated that it was easy to port Lollipop on the Tegra Note 7 since it was basically a stock Android design with little or on deviation from the standard design. That "real soon" slipped to February of 2015 and when February 2015 came and went Nvidia became strangely mute on the subject, ignoring customers' inquiries.
What you describe is basically every tablet seller out there save for Google themselves. They save the new versions for their upcoming products, and only after those get put out do they update the old stuff.
Weight plays a lot into our perception for how solid and well built things are, even when they're not. Lightweight is great, but go too far and things feel like a fragile toy.
This is almost too good a problem to have with a laptop -- too lightweight? Put more battery in it.
A good shard (UO-speak for a custom server) would have great GMs regularly creating events for their players. I've played through a week-long monster invasion on Minoc, a war between Trinsic and Yew, a murder mystery involving 100+ players, and more custom "dungeon" areas than I can count. The last dungeon I remember was a play on Alice in Wonderland.
I haven't played UO in about 10 years, but custom shards gave hands down the best MMO experience I've ever seen even compared to current games.
Diablo had procedurally generated levels back in 1997. I'm sure other games came before it. This is a bit more interesting because the procedure was learned, not explicitly programmed.
I was very upset to hear this last night. My favorite composition from him was Casper's Lullaby -- beautiful, haunting, and simple. They are what inspired me to learn piano in my 20s.
JavaScript in its current form will never have a place larger than simple website scripting in my production environment -- it's unmaintainable in anything beyond small doses and is something we work with because there's literally no other option, not because we want to. TypeScript makes things better, but being better than JavaScript really isn't that tough. It's still not as good as -- and doesn't provide benefits instead of -- existing common backend languages like Java and C#.
To me, node.js perfectly represents the age of programming we're in: people are doing things because they can, not because they should. Things that would have been just-for-fun geeky side projects 10 years ago are now somehow making their way into legitimate business-critical projects.