I'm sure it is quite possible to do some ABX testing on this speaker vs some others and arrange them into an order that represents their comparative quality without people's bias / imagination creeping into reviews.
It doesn't make it any harder for a parent to gift a kid. I could load the Play store with $10 of credit and the kid can spend it in-game if they so desire. I could even avoid crediting Play if the account was set with a $10 purchase limit that was deducted from the card as it was used.
I don't see why it should cost any more to do this. If anything it would be less because you could purchase the item with the exact amount rather than overspending and being ripped off by the difference.
The main purpose of banning virtual currencies is that stops them from being glorified skinner boxes, especially if applied in conjunction with hard spending limits.
I don't see how your argument holds any sway. There is nothing to stop a game from gifting you something if you watch an ad. It certainly doesn't justify that virtual currency should be purchased with real cash.
Nor does it ban being able to play F2P games. If you want to play those games you carry on playing those games. Except when you buy the boosters you do so with real cash instead of pretend coins that you must purchase in amounts that exceed the thing you want to buy.
I didn't say ban buying virtual trinkets. I said ban virtual currencies which are purchased with real cash.
So an end to the bullshit in games like "buy a handful of star berries 10x - $5, a bushel of star berries - 50x - $20, a grove of star berries - 150x - $50, a forest of star berries (BEST VALUE!) - 500x - $150".
You could still buy the trinkets but they should be a direct cash transaction that you pay the exact amount for. That way you know much you're paying and you're not buying an excess of virtual scrip in order to do it.
It is gambling and it is a cynical attempt to screw the player to pay more money to unlock a game they've already paid for. So I'd be glad if they banned it, though Germany should be aiming for EU wide legislation.
I'd also like to see laws that ban virtual currencies which are purchased with real cash. And require gaming services (which includes appstores etc.) to enforce limits on the amount that anyone can purchase in-game in any given month. And worded to prevent bullshit circumvention of the limits. The limits could be set by the age rating of the game - the lower the rating, the lower the limit.
Such things might motivate companies to start producing games again instead of skinner boxes designed to target whales and compulsive gamblers.
Open up YouTube without logging on and the entire page is just bullshit click bait. People have figured out how to game the algorithm to get their vapid trash onto the front page, generating millions of views in the process.
I'm sure the same thing happens at a smaller scale. Channels know the keywords to use, the video stills to advertise the content, the baiting language to get the views. Once the views go up the ranking algorithm makes the video more prominent, perpetuating the process. And if it can be done for commercial reasons it surely can be done for political or propaganda purposes.
I assume any such system would have a challenge / response built into it. i.e. Cops turn up, allows them to type your license into it and they expect to see some kind of reaction / code appear on your device. And if it doesn't then you'll be required to produce your actual licence at a station in the next X days.
Memory leaks are a non issue? Easy bugs to find? You have an interestingly naive grasp of how complex programming can be in the real world and the memory constraints some software must operate within.
"The programmer let it happen" is a cop out and it doesn't even make sense. NULL pointer issues happen frequently enough to recognize them as an endemic problem. Regardless of how amazing you might personally consider your programming to be, or your low opinion of people who dare make errors. And if you're claiming you've never been responsible for a crash in production code then either you're a liar or you don't write production code.
The same argument could be made in any factory - the workers should know how to use their tools so therefore there is no reason for safety. Except we repeatedly discover that is not the case. People get crushed, scalded, electrocuted, burned, scalped in all kinds of horrible accidents on machinery where there is no safety, or it is easy to circumvent. Thus factory machinery these days is subject to rigorous safety standards that are designed to minimize risk to an acceptable level - safety gates, sensors, barriers, pressure mats, emergency stops etc.
Programmers don't lose their lives from doing bad things but somebody else might and it is not unreasonable that the tool should stop bad things from happening by design. And that is all Rust does. The language is designed to not use pointers so all the class of problems related to pointers simply can't happen. All shared data must be locked in use so data races cannot happen. Of course if you are desperate to do unsafe things in Rust you can use an "unsafe" block and have at it. But the default is safe and there are only a few instances where you'd ever care to throw the switches.
Why is it the language's job to make sure your code is somehow "safe"?
Firstly, you can do unsafe programming in Rust. Just enclose a chunk of code in an "unsafe" block and do what you like. But by default the language prevents you from 1) using pointers, 2) mutating types or memory, 3) writing to raw memory / buffers etc. 4) accessing shared data from multiple threads without the use of locks. If you must do those things you can, for example to call into C, or allow C to call into Rust. But 99.99% of the time you don't and the compiler will enforce that.
I'm failing to see how this is meant to be a problem.
There is something profoundly absurd about that sort of argumentation. Firstly it ignores the reality that even the most experienced programmer can be caught out. And that programmers only become experienced by writing a lot of crappy code, much of which ends in production. And that even a brief search reveals a plague of problems that NULL has caused and when even the inventor of NULL calls it a billion dollar mistake.
The ultimate absurdity is that claiming that just because some but not all NULL pointer issues can be fixed relatively simply, that it somehow it absolves a language which allowed them happen in the first place. It amounts to wasted time, poorer quality code and more bugs. It's just one of many issues that are present in C++ and are blocked by design in Rust.
Close to a non issue? Null pointers have been described as a billion dollar mistake. It is FAR from a non-issue.
And anybody who has programmed C++ can explain to you the amount of crashes they catch during the course of development and by implication how many are likely still there when the code goes into production.
You got it backwards. I'm praising that Rust prevents crashes from occurring by design (e.g. that you MUST protect and obtain locks on shared data). If code compiles in Rust then it likely it contains less bugs than equivalent code compiled in C++. Doesn't help fix application errors but it does mean it's not likely to drop dead because some code called a dangling reference.
Besides that, a crash is rarely ever a good thing. It might be simple to identify some crashes e.g. calling a null or dangling pointer or it could be something as insidious as a data race that takes weeks to trigger. If you are lucky you find the crash during development. If you're unlucky your customer finds it for you with all that implies - additional support costs, customer annoyance & downtime, lawsuits.
Arguing that a crash is somehow good is nuts. Even C++ recognizes they suck which is why it does what it can to mitigate them, e.g. providing unique / shared pointers and mutex guards in the standard library. Still doesn't go as far as Rust.
C++ has been moving in the same direction as Rust towards safer programming but thanks to the need to be backwards compatible, it is still unsafe by default and using some of these new features is very clumsy and verbose. e.g. if you want to do move semantics in C++ you have to add weird && constructors and if you thought the rule-of-3 was bad, wait until you see the rule-of-5. Stuff like implicit keywords and deleted constructors just adds to the mess.
And even if you do make use of the new features C++ is still hampered by the lack of things like borrow checking, thread safety checks etc. Even just writing headers and sources with forward referencing etc. is a chore. The toolchain / build system feels positively clunky compared to cargo.
My impression of using Rust is they went the right way by making safe be the default. It allows the compiler to enforce a lot more than C++ and normally in a lot less code.
Rust definitely needs better IDE integration but you can find plugins that work for VS Code, Atom, IntelliJ/Clion, Eclipse, Dev Studio. The IntelliJ plugin in particular is excellent but VS Code's is good too. Seriously I could write code all day in IntelliJ and it has all the niceities you would expect from a plugin - refactoring, code cleanup, reformatting, find usages, inspection, code completion etc.
I'm more concerned by trying to debug Rust than the editing aspect. Rust can be debugged through cdb, gdb, lldb etc. but none of that comes "out of the box" on Windows. It's much easier to get going on Linux since you only have a gnu backend and gdb is easy to install but even so you need little scripts to pretty up some of the data inspection. It would be nice if rustup or whatever had a simple way to install the debugger on Windows.
Concerning difficulty I think many of the same difficulties would be encountered if you chose C++ instead of Rust and came from a higher level language background. Both languages force you to think in terms of stack, heap, memory allocation etc. It's just that Rust will kick your ass up-front if you get it wrong while C++ will happily let you write errors into your code and you'll just have to discover them (or not) later when things break. Personally I would take that pain simply because it reassures me that code that comes out the other side has a lot less errors in it.
That might make the language seem more painful to use but its doing you a favor by making your errors obvious now, not later and to write safer code. I think the error messages from Rust are very useful. They tend to be descriptive and usually provide a suggested fix which is often right. Certainly far easier to work out what the error relates to than many C++ errors. It's not uncommon in C++ for a trivial code error to throw up a wall of impenetrable garbage thanks to templates and static typing.
An anecdote - I've been programming Rust for about 18 months now and do you know how often my compiled program has crashed because of a null pointer, dangling reference or some addressing error in all that time? Once. And that crash was in a C library I was calling from Rust! In other words the code I've written has never crashed a single time.
I see nothing major about Rust the language which needs to change. I think the biggest hurdle for people coming from C++ is understanding that stuff moves on assignment and there is no inheritance. So they have to unlearn stuff and think about doing things another way. It's certainly a hurdle but I don't think it's too tricky. The payoff is less bugs and ultimately that means better quality software, less support calls and happier customers. If I were developing for IoT or mission critical software I'd definitely choose Rust over C or C++ unless there was a reason I could not.
Most consumer products are sold by multiple stores and the competition comes from stores who offer convenience, better prices, and/or better customer service for the price you pay. The price being usually less than the MSRP.
Cars are big ticket items but the idea of dealerships is to perform a similar role - to be competition to each other so that when you buy a Ford, you have a choice of dealers and if you shop around you will get the best deal.
The Tesla sales model so far is buy from their store or take a hike. It's obvious why there may the competition issues with this.
In other words, sealed in. By any reasonable person's definition.
Apple are vaunted as masters of design, yet it's amazing how they can't produce a phone that allows the battery to be replaced without the use of tools. Almost as if it is a deliberate, cynical ploy to drive sales of new phones.
Yes and like Apple, they want people to pay exactly the MSRP or go fuck themselves. They don't want other dealers buying their products wholesale and undercutting them.
In other words they don't want multiple dealers in competition with each other selling their products. They want all the money to themselves.
If Ford / GM started selling directly then either a) they have an unfair advantage to undercut the dealers and drive them out of business, or b) they charge prices way in excess of dealers, c) they operate as a cartel with the dealers, neither undercutting them or charging more than them - price fixing.
None of these choices are good for the consumer. The only way I could see Ford / GM selling "direct" is if they spun off a completely independent subsiduary that was able to purchase and sell vehicles under exactly the same terms and conditions as any other dealer. But even this would be fraught with legal issues.
And besides that, this is beside the point. Tesla basically wants to be a monopoly seller of its products. That is TERRIBLE for consumers. They charge what they like and there is absolutely no way for a consumer to better the price, get a deal or anything because there is no competition to the website.
As horrible and as scuzzy as some dealers are, they are still a form of competition. Tesla simply doesn't want competition or to sell cars wholesale. It wants the money all to itself.
Mazda is to be applauded for making a more efficient internal combustion engine. But the only way it's "cleaner" than an electric vehicle is by making the assumption that the EV was charged from fuel produced by fossil fuel. That's a bogus assumption.
Apple said it would never intentionally "degrade the user experience to drive customer upgrades."
And yet they were caught doing exactly this. And besides that, Apple has sealed in the battery and made the cost / terms of replacement so onerous that it could have no other expected effect than drive customer upgrades.
Slashdot Mirror
Maybe EarPods are good headphones. For the price they fucking aught to be.
I'm sure it is quite possible to do some ABX testing on this speaker vs some others and arrange them into an order that represents their comparative quality without people's bias / imagination creeping into reviews.
I don't see why it should cost any more to do this. If anything it would be less because you could purchase the item with the exact amount rather than overspending and being ripped off by the difference.
The main purpose of banning virtual currencies is that stops them from being glorified skinner boxes, especially if applied in conjunction with hard spending limits.
Nor does it ban being able to play F2P games. If you want to play those games you carry on playing those games. Except when you buy the boosters you do so with real cash instead of pretend coins that you must purchase in amounts that exceed the thing you want to buy.
So an end to the bullshit in games like "buy a handful of star berries 10x - $5, a bushel of star berries - 50x - $20, a grove of star berries - 150x - $50, a forest of star berries (BEST VALUE!) - 500x - $150".
You could still buy the trinkets but they should be a direct cash transaction that you pay the exact amount for. That way you know much you're paying and you're not buying an excess of virtual scrip in order to do it.
I'd also like to see laws that ban virtual currencies which are purchased with real cash. And require gaming services (which includes appstores etc.) to enforce limits on the amount that anyone can purchase in-game in any given month. And worded to prevent bullshit circumvention of the limits. The limits could be set by the age rating of the game - the lower the rating, the lower the limit.
Such things might motivate companies to start producing games again instead of skinner boxes designed to target whales and compulsive gamblers.
I'm sure the same thing happens at a smaller scale. Channels know the keywords to use, the video stills to advertise the content, the baiting language to get the views. Once the views go up the ranking algorithm makes the video more prominent, perpetuating the process. And if it can be done for commercial reasons it surely can be done for political or propaganda purposes.
I assume any such system would have a challenge / response built into it. i.e. Cops turn up, allows them to type your license into it and they expect to see some kind of reaction / code appear on your device. And if it doesn't then you'll be required to produce your actual licence at a station in the next X days.
Memory leaks are a non issue? Easy bugs to find? You have an interestingly naive grasp of how complex programming can be in the real world and the memory constraints some software must operate within.
"The programmer let it happen" is a cop out and it doesn't even make sense. NULL pointer issues happen frequently enough to recognize them as an endemic problem. Regardless of how amazing you might personally consider your programming to be, or your low opinion of people who dare make errors. And if you're claiming you've never been responsible for a crash in production code then either you're a liar or you don't write production code.
Programmers don't lose their lives from doing bad things but somebody else might and it is not unreasonable that the tool should stop bad things from happening by design. And that is all Rust does. The language is designed to not use pointers so all the class of problems related to pointers simply can't happen. All shared data must be locked in use so data races cannot happen. Of course if you are desperate to do unsafe things in Rust you can use an "unsafe" block and have at it. But the default is safe and there are only a few instances where you'd ever care to throw the switches.
Why is it the language's job to make sure your code is somehow "safe"?
Firstly, you can do unsafe programming in Rust. Just enclose a chunk of code in an "unsafe" block and do what you like. But by default the language prevents you from 1) using pointers, 2) mutating types or memory, 3) writing to raw memory / buffers etc. 4) accessing shared data from multiple threads without the use of locks. If you must do those things you can, for example to call into C, or allow C to call into Rust. But 99.99% of the time you don't and the compiler will enforce that.
I'm failing to see how this is meant to be a problem.
The ultimate absurdity is that claiming that just because some but not all NULL pointer issues can be fixed relatively simply, that it somehow it absolves a language which allowed them happen in the first place. It amounts to wasted time, poorer quality code and more bugs. It's just one of many issues that are present in C++ and are blocked by design in Rust.
And anybody who has programmed C++ can explain to you the amount of crashes they catch during the course of development and by implication how many are likely still there when the code goes into production.
Besides that, a crash is rarely ever a good thing. It might be simple to identify some crashes e.g. calling a null or dangling pointer or it could be something as insidious as a data race that takes weeks to trigger. If you are lucky you find the crash during development. If you're unlucky your customer finds it for you with all that implies - additional support costs, customer annoyance & downtime, lawsuits.
Arguing that a crash is somehow good is nuts. Even C++ recognizes they suck which is why it does what it can to mitigate them, e.g. providing unique / shared pointers and mutex guards in the standard library. Still doesn't go as far as Rust.
And even if you do make use of the new features C++ is still hampered by the lack of things like borrow checking, thread safety checks etc. Even just writing headers and sources with forward referencing etc. is a chore. The toolchain / build system feels positively clunky compared to cargo.
My impression of using Rust is they went the right way by making safe be the default. It allows the compiler to enforce a lot more than C++ and normally in a lot less code.
I'm more concerned by trying to debug Rust than the editing aspect. Rust can be debugged through cdb, gdb, lldb etc. but none of that comes "out of the box" on Windows. It's much easier to get going on Linux since you only have a gnu backend and gdb is easy to install but even so you need little scripts to pretty up some of the data inspection. It would be nice if rustup or whatever had a simple way to install the debugger on Windows.
Concerning difficulty I think many of the same difficulties would be encountered if you chose C++ instead of Rust and came from a higher level language background. Both languages force you to think in terms of stack, heap, memory allocation etc. It's just that Rust will kick your ass up-front if you get it wrong while C++ will happily let you write errors into your code and you'll just have to discover them (or not) later when things break. Personally I would take that pain simply because it reassures me that code that comes out the other side has a lot less errors in it.
That might make the language seem more painful to use but its doing you a favor by making your errors obvious now, not later and to write safer code. I think the error messages from Rust are very useful. They tend to be descriptive and usually provide a suggested fix which is often right. Certainly far easier to work out what the error relates to than many C++ errors. It's not uncommon in C++ for a trivial code error to throw up a wall of impenetrable garbage thanks to templates and static typing.
An anecdote - I've been programming Rust for about 18 months now and do you know how often my compiled program has crashed because of a null pointer, dangling reference or some addressing error in all that time? Once. And that crash was in a C library I was calling from Rust! In other words the code I've written has never crashed a single time.
I see nothing major about Rust the language which needs to change. I think the biggest hurdle for people coming from C++ is understanding that stuff moves on assignment and there is no inheritance. So they have to unlearn stuff and think about doing things another way. It's certainly a hurdle but I don't think it's too tricky. The payoff is less bugs and ultimately that means better quality software, less support calls and happier customers. If I were developing for IoT or mission critical software I'd definitely choose Rust over C or C++ unless there was a reason I could not.
Cars are big ticket items but the idea of dealerships is to perform a similar role - to be competition to each other so that when you buy a Ford, you have a choice of dealers and if you shop around you will get the best deal.
The Tesla sales model so far is buy from their store or take a hike. It's obvious why there may the competition issues with this.
Apple are vaunted as masters of design, yet it's amazing how they can't produce a phone that allows the battery to be replaced without the use of tools. Almost as if it is a deliberate, cynical ploy to drive sales of new phones.
Here on planet Earth, slowing a phone's operation IS degrading the experience.
In other words they don't want multiple dealers in competition with each other selling their products. They want all the money to themselves.
If Ford / GM started selling directly then either a) they have an unfair advantage to undercut the dealers and drive them out of business, or b) they charge prices way in excess of dealers, c) they operate as a cartel with the dealers, neither undercutting them or charging more than them - price fixing.
None of these choices are good for the consumer. The only way I could see Ford / GM selling "direct" is if they spun off a completely independent subsiduary that was able to purchase and sell vehicles under exactly the same terms and conditions as any other dealer. But even this would be fraught with legal issues.
And besides that, this is beside the point. Tesla basically wants to be a monopoly seller of its products. That is TERRIBLE for consumers. They charge what they like and there is absolutely no way for a consumer to better the price, get a deal or anything because there is no competition to the website.
As horrible and as scuzzy as some dealers are, they are still a form of competition. Tesla simply doesn't want competition or to sell cars wholesale. It wants the money all to itself.
Mazda is to be applauded for making a more efficient internal combustion engine. But the only way it's "cleaner" than an electric vehicle is by making the assumption that the EV was charged from fuel produced by fossil fuel. That's a bogus assumption.
Apple said it would never intentionally "degrade the user experience to drive customer upgrades."
And yet they were caught doing exactly this. And besides that, Apple has sealed in the battery and made the cost / terms of replacement so onerous that it could have no other expected effect than drive customer upgrades.
Except for the fact that the wrong woman died in it.