Most of the malware is in movie downloads. If a movie is in.wmv format, it's malware (Windows Media Player will prompt you to download the "drm" the file is supposedly protected by which will infect you). If it's an.exe, it's malware. If the movie is inside an encrypted.rar or.zip, then it's fake and the accompanying readme.txt will pretend you can get the key if you visit a site serving malware or some other scam.
Some of the ads on TPB are particularly scuzzy. I remember visiting once and an APK automatically began downloading on my phone. Other times when I've gone there sites have to tried to initiate downloads of.exes, popped up with fake virus / malware banners, or promoted software which has 99% probability of being scammy / trojans.
I realize TPB takes its money where it can get it but it's hardly surprising it's ended up on a blacklist. In a sense it's amazing it's taken so long to happen. Perhaps it should restrict ads to static text, images and a url to prevent drive by infections and some of the sleazier things on there right now.
I'm sure there are people who spoof their car's safety belt sensors too. You can only do so much to prevent determined idiocy. It doesn't mean you shouldn't enforce safety at all for the majority of people who aren't idiots.
I should think the problem is extremely obvious. A normal car will crash itself if you take your hands off the wheel. A car with autopilot will continue to steer itself and will appear to do so quite well for the most part. A consequence of that is drivers WILL become inattentive and WILL do things other than paying attention to the road, hazards, other vehicles etc. This is entirely forseeable and obvious.
And for the most part (that part where the car seems to be doing okay) maybe it doesn't matter if a driver is inattentive. But it sure as fuck matters when some kid runs out into the road, or a truck in front jack knifes, or the car has a "moment" and fails to see some obvious hazard. At that moment, the driver's attention might mean the difference between a serious accident and avoidance. Perhaps the car is quite good in normal situations but it's still not as good as a car AND a driver.
Allowing a driver to spend up to a minute messing around with his / her phone or whatever else is simply inexcusable. The car should force the driver to hold the wheel and only allow them to remove their hands for a moment. And if they do for longer, ignoring warnings then the car should pull over, stop, and disable autopilot for some period of time commensurate to making them use the mode properly.
The problem here is Tesla wants to have their cake and eat it all. They say their car is safe because of this-or-that feature and then they shove in things which are inherently unsafe. I wonder what Volvo does with their self drive functionality because I bet they take safety a hell of a lot more serious than Tesla does.
If they're allowing the user to take their hands off the wheel for up to a minute then they're still not taking safety seriously. Maybe the car is better than it was before, but it'd be better again with an attentive driver instead of one playing with their web browser because the car lets them.
The driver can still take their hands off the wheel for up to a minute. During which time they could be turned around fetching something out of the back, eating a sandwich, playing with Twitter. Anything except actually paying attention to the vehicle they are inside - a 2 ton vehicle hurtling down the road at 70mph.
So yeah, maybe the new software makes the car better at not crashing into trucks. It sure as hell isn't better than if the car AND the driver were both attentive to the road. Humans are excellent at negating safety features and any system which doesn't take this into account is dooming people (and not necessarily the driver) to an early grave.
It's simply a way to force people onto their own proprietary connectors, standards and peripherals. There is absolutely no sound technical reason to eliminate a head phone jack.
USB-C would be a good design if micro-B hadn't gotten there first. Micro-B has the frustrating issue of never plugging in the right way around but cables are cheap, chargers are cheap and it's the defacto format for most handsets (barring proprietary ones like Apple's).
In theory USB-C is better, but the cables and charges are still expensive compared to Micro-B, even when the only difference is the connector, and there are also problematic cables and chargers. Benson Leung has gone on a 1-man crusade to highlight the bad ones but to me that only highlights problems with an overly complex spec and how certification has been conducted to allow it to get in this state.
Plugging into a power bank is certainly better than nothing. It's certainly NOT better than swapping out a battery if the option is available.
For one thing your phone's battery might be old and is losing charge and so you want to replace it permanently with a new one. A bank will not help with that.
Secondly, you could maintain a second battery at full charge, swap it in and now you have full power. A power bank trickle charges your phone so if it's at 2%, then it's still 2% with the charger plugged in, and it might require an hour to charge it up. In the meantime you have phone with a dongle hanging off it. And during that period you can't do much with the phone since even having the display on could use more power than the charger is supplying.
And frankly charge banks are a solution that should have not existed in the first place. There is virtually NO BENEFIT to the user of a sealed in battery. It doesn't make the device appreciably smaller or thinner. A battery occupies almost the same space regardless of it being accessible or not to the user. The only benefit is to the manufacturer who gets to build obsolescence into a device and therefore increase sales. I'm somewhat surprised that someone like the EU doesn't block the practice.
So-called "smart" TVs push ads, track usage and after a few years start to go bitrotten as apps and services become discontinued. So-called "smart" watches are tied to proprietary services, can't last more than a few days on a charge and are obsolete in a few years. A "smart" fridge will be no different in this regard - you'll pay a premium for something that spies on you, will discontinue service after a few years and then display a bunch of error messages.
Meanwhile their supposedly dumb counterparts carry on working. A genuinely smart device would be one which provides value independent of some ephemeral service in the cloud and it would do so without compromising your privacy.
I've seen some but they cost way more money than a micro-B. Type-C is a complex standard, with active cables for devices that negotiate bus currents and there are lots of faulty cables and chargers out there. Perhaps that's why enthusiasm for USB type-C appears so underwhelming. It might be superior but micro-B is cheap and most people already have lots of devices, cables & chargers for that spec.
OpenOffice wasn't exactly a hive of activity before that. Sun's bureaucratic development policies resulted in frustration and a backlog of stuff which hadn't or wasn't allowed to go in. This wasn't minor stuff either, Novell maintained a fork called go-oo that had far better MSO support that Sun wouldn't accept. Sun was a rotten steward and the move to Oracle merely added evil to the process. Oracle was the last straw but I think a fork would have happened eventually.
Lenovo is shooting itself in the foot if it produces the "world's thinnest laptop" if it ships with the world's most useless keyboard. Touch typing on a flat bit of glass / plastic will suck big time regardless of whether they draw little boxes around where the "keys" are.
No, C++ offers new and exciting ways to totally screw things up, e.g. calling delete instead of delete[] on array, or calling delete on a base class where the destructor isn't virtual, or overloading new but not delete. Or calling a dangling pointer to a base class yields mysterious unimplemented method errors in some compilers. Since C++ barely ever deprecates anything of note (trigraphs and other minor stuff being the sum total), it means the issues compound with each release. C++ has all the ways to screw up found in C, the C API and adds plenty of its own.
And it's no use to say "only a bad programmer", because the reality is that programmers run the spectrum of skills and even the "good" programmers only become so from learning from mistakes. Mistakes that can be very costly to discover. That's reality. And even if a programmer is "good", it does not mean perfect.
Other languages from Java, Ruby, Swift, Go, Rust are all gaining popularity precisely because they stop all kinds of dumb errors that C or C++ blissfully allow through. The later a bug is found the more costly it is to fix. Stopping bugs from happening in the first place is the cheapest remedy of them all.
Even the most trivial C program can run afoul of differences from one system to another, one compiler to another. And C code has to be recompiled for each platform it ends up running on. It would be nice if I could compile a C or C++ application to LLVM bitcode against some portable APIs and have a runtime compile it natively but this is not the case right now and I doubt it ever will happen. Only then can we talk about C being portable.
Non-trivial C or C++ software is always littered with #ifdefs and other conditional tests throughout its build system and source to make it work across systems. For example SQLite3 has over 2000 #ifdef, #if, #else clauses in its source code to deal with various platform, compiler, debug configurations. And that's just a small library.
By and large Java DOES run anywhere. It is quite common for developers to write and test Java code on a PC workstation and deploy the same.jar /.war /.ear file to servers running Linux, Solaris or something else. The main reason this might not work is when the Java has JNI or some OS dependency that breaks this portability (e.g. SWT or JOGL). But most code has no such problem. And this is why Java is the prevalent language it is.
Yes C and C++ are "distinct" in principle but in practice C++ is basically a superset. There are minor differences in syntax, headers and issues around linkage to but they're so close that one can be considered the superset of the other. Most OSS libraries written in C are directly consumed by C++, their headers and so forth. Most C++ compilers also compile C.
C++ certainly provides various STL classes & templates that reduce the risk of some errors happening but it still requires code to use them correctly. But it's a Catch-22 since if people wrote code correctly then there wouldn't be a risk of errors in the first place... Yet we see how even supposedly mature libraries fall victim to exploits like overflows, not to mention the far more mundane and common issues like I mentioned. Even the most skilled programmers can't avoid errors and in many instances they're errors that another language wouldn't have allowed in the first place.
I explicitly said C/C+ since both suffer from the same issues. C++ could be argued to offer a superset of the same issues since it increases the number of ways of screwing things up.
Rust stands a pretty good chance of being used for low level things where fast, reliable and performant software is required. Languages that use garbage collection would suffer runtime penalties and their memory consumption goes up and down like a yoyo. They could also suffer more from long-running issues like heap fragmentation.
Whether Rust will succeed remains to be seen however it's already built up a substantial number of libraries and support on crates.io and has proven itself popular with developers. I think it will find its way into a lot of IoT devices, drones, server farms etc. I doubt it will ever become a popular high-level programming language though because the compiler is brutally strict and will kick a dev's ass if there are any problems with lifetimes, borrowing, thread sync etc. Things that are trivial in other language can be quite hard to do in Rust to the satisfaction of the compiler.
Driver inattentiveness has been a forseeable problem as cars strive to do more and more. It's good to see Tesla finally taking action but really it should haven't been necessary for someone to die to figure this out. Their self-drive mode is clearly limited and as such they must do everything they can to ensure the driver is ready to take over or veto the car in a split second.
This isn't just Tesla's problem either but every self-drive vehicle that only offers partial automation.
C/C++ has plenty of problems - buffer overflows, stack overflows, leaks, dangling pointers, etc. etc. It turns out that for many if not most real world applications, stability, development ease, time to market and a bunch of other considerations are far more important than raw speed. This is why higher level languages are so popular. Languages like Java, C#, Ruby, Python and newcomers like Go & Swift.
C/C++ is finding itself relegated to systems programming and certain niches like games where speed is still critical. Even from a systems / performance point of view languages like Rust are increasingly seen as ways to attain greater stability without compromising speed.
"Thinner" appeals to people even if the first thing they do with their precious glass coated sliver is put it into an ugly bump case to protect it. So much for being thin or stylish.
Slashdot Mirror
Most of the malware is in movie downloads. If a movie is in .wmv format, it's malware (Windows Media Player will prompt you to download the "drm" the file is supposedly protected by which will infect you). If it's an .exe, it's malware. If the movie is inside an encrypted .rar or .zip, then it's fake and the accompanying readme.txt will pretend you can get the key if you visit a site serving malware or some other scam.
I realize TPB takes its money where it can get it but it's hardly surprising it's ended up on a blacklist. In a sense it's amazing it's taken so long to happen. Perhaps it should restrict ads to static text, images and a url to prevent drive by infections and some of the sleazier things on there right now.
You're supposed to pay a premium for Apple licensed speakers of course. That's what you're supposed to do.
I'm sure there are people who spoof their car's safety belt sensors too. You can only do so much to prevent determined idiocy. It doesn't mean you shouldn't enforce safety at all for the majority of people who aren't idiots.
And for the most part (that part where the car seems to be doing okay) maybe it doesn't matter if a driver is inattentive. But it sure as fuck matters when some kid runs out into the road, or a truck in front jack knifes, or the car has a "moment" and fails to see some obvious hazard. At that moment, the driver's attention might mean the difference between a serious accident and avoidance. Perhaps the car is quite good in normal situations but it's still not as good as a car AND a driver.
Allowing a driver to spend up to a minute messing around with his / her phone or whatever else is simply inexcusable. The car should force the driver to hold the wheel and only allow them to remove their hands for a moment. And if they do for longer, ignoring warnings then the car should pull over, stop, and disable autopilot for some period of time commensurate to making them use the mode properly.
The problem here is Tesla wants to have their cake and eat it all. They say their car is safe because of this-or-that feature and then they shove in things which are inherently unsafe. I wonder what Volvo does with their self drive functionality because I bet they take safety a hell of a lot more serious than Tesla does.
I was right the first time. Somehow I thought I'd read 2000 pounds.
If they're allowing the user to take their hands off the wheel for up to a minute then they're still not taking safety seriously. Maybe the car is better than it was before, but it'd be better again with an attentive driver instead of one playing with their web browser because the car lets them.
Correction - 1 ton
So yeah, maybe the new software makes the car better at not crashing into trucks. It sure as hell isn't better than if the car AND the driver were both attentive to the road. Humans are excellent at negating safety features and any system which doesn't take this into account is dooming people (and not necessarily the driver) to an early grave.
It's simply a way to force people onto their own proprietary connectors, standards and peripherals. There is absolutely no sound technical reason to eliminate a head phone jack.
In theory USB-C is better, but the cables and charges are still expensive compared to Micro-B, even when the only difference is the connector, and there are also problematic cables and chargers. Benson Leung has gone on a 1-man crusade to highlight the bad ones but to me that only highlights problems with an overly complex spec and how certification has been conducted to allow it to get in this state.
For one thing your phone's battery might be old and is losing charge and so you want to replace it permanently with a new one. A bank will not help with that.
Secondly, you could maintain a second battery at full charge, swap it in and now you have full power. A power bank trickle charges your phone so if it's at 2%, then it's still 2% with the charger plugged in, and it might require an hour to charge it up. In the meantime you have phone with a dongle hanging off it. And during that period you can't do much with the phone since even having the display on could use more power than the charger is supplying.
And frankly charge banks are a solution that should have not existed in the first place. There is virtually NO BENEFIT to the user of a sealed in battery. It doesn't make the device appreciably smaller or thinner. A battery occupies almost the same space regardless of it being accessible or not to the user. The only benefit is to the manufacturer who gets to build obsolescence into a device and therefore increase sales. I'm somewhat surprised that someone like the EU doesn't block the practice.
Meanwhile their supposedly dumb counterparts carry on working. A genuinely smart device would be one which provides value independent of some ephemeral service in the cloud and it would do so without compromising your privacy.
I've seen some but they cost way more money than a micro-B. Type-C is a complex standard, with active cables for devices that negotiate bus currents and there are lots of faulty cables and chargers out there. Perhaps that's why enthusiasm for USB type-C appears so underwhelming. It might be superior but micro-B is cheap and most people already have lots of devices, cables & chargers for that spec.
OpenOffice wasn't exactly a hive of activity before that. Sun's bureaucratic development policies resulted in frustration and a backlog of stuff which hadn't or wasn't allowed to go in. This wasn't minor stuff either, Novell maintained a fork called go-oo that had far better MSO support that Sun wouldn't accept. Sun was a rotten steward and the move to Oracle merely added evil to the process. Oracle was the last straw but I think a fork would have happened eventually.
More to the point, it just smacks of sour grapes.
Lenovo is shooting itself in the foot if it produces the "world's thinnest laptop" if it ships with the world's most useless keyboard. Touch typing on a flat bit of glass / plastic will suck big time regardless of whether they draw little boxes around where the "keys" are.
And it's no use to say "only a bad programmer", because the reality is that programmers run the spectrum of skills and even the "good" programmers only become so from learning from mistakes. Mistakes that can be very costly to discover. That's reality. And even if a programmer is "good", it does not mean perfect.
Other languages from Java, Ruby, Swift, Go, Rust are all gaining popularity precisely because they stop all kinds of dumb errors that C or C++ blissfully allow through. The later a bug is found the more costly it is to fix. Stopping bugs from happening in the first place is the cheapest remedy of them all.
Non-trivial C or C++ software is always littered with #ifdefs and other conditional tests throughout its build system and source to make it work across systems. For example SQLite3 has over 2000 #ifdef, #if, #else clauses in its source code to deal with various platform, compiler, debug configurations. And that's just a small library.
By and large Java DOES run anywhere. It is quite common for developers to write and test Java code on a PC workstation and deploy the same .jar / .war / .ear file to servers running Linux, Solaris or something else. The main reason this might not work is when the Java has JNI or some OS dependency that breaks this portability (e.g. SWT or JOGL). But most code has no such problem. And this is why Java is the prevalent language it is.
C++ certainly provides various STL classes & templates that reduce the risk of some errors happening but it still requires code to use them correctly. But it's a Catch-22 since if people wrote code correctly then there wouldn't be a risk of errors in the first place... Yet we see how even supposedly mature libraries fall victim to exploits like overflows, not to mention the far more mundane and common issues like I mentioned. Even the most skilled programmers can't avoid errors and in many instances they're errors that another language wouldn't have allowed in the first place.
I explicitly said C/C+ since both suffer from the same issues. C++ could be argued to offer a superset of the same issues since it increases the number of ways of screwing things up.
Whether Rust will succeed remains to be seen however it's already built up a substantial number of libraries and support on crates.io and has proven itself popular with developers. I think it will find its way into a lot of IoT devices, drones, server farms etc. I doubt it will ever become a popular high-level programming language though because the compiler is brutally strict and will kick a dev's ass if there are any problems with lifetimes, borrowing, thread sync etc. Things that are trivial in other language can be quite hard to do in Rust to the satisfaction of the compiler.
This isn't just Tesla's problem either but every self-drive vehicle that only offers partial automation.
C/C++ is finding itself relegated to systems programming and certain niches like games where speed is still critical. Even from a systems / performance point of view languages like Rust are increasingly seen as ways to attain greater stability without compromising speed.
"Thinner" appeals to people even if the first thing they do with their precious glass coated sliver is put it into an ugly bump case to protect it. So much for being thin or stylish.