SoylentNews is people
SoylentNews
Engadget and others are reporting that contrary to the very spirit of the set-top box DVR, TiVo says all subscribers with select devices will see ads prior to playing recorded shows after a software update rolls out. TiVo says subscribers will be able to skip the ads coming in the next 90 days, but did not elaborate on this as a user says they had to fast forward through the ads. Many subscribers are angry and threatening to cancel, calling the ads a feature that devalues the service as they pay for the ability to skip ads altogether.
This prompts the question: will cable companies, losing subscribers and looking to replace that revenue, do the same with their DVRs?
Original article: https://www.engadget.com/2019/09/21/tivo-pre-roll-dvr-ads-for-all-users/.
(Score: 5, Insightful) by Anonymous Coward on Monday September 23 2019, @11:34AM (12 children)
* No commercial entity will ever start 'showing' me ads on it because they decided to succumb to the allure of ad revenue.
You haven't kept up with Poettering's plans for systemd, have you?
(Score: 2) by https on Monday September 23 2019, @01:35PM (3 children)
Would it be too much to include a dose of Xanax when you post nightmare fuel like that?
Off to rob my local pharmacy now. Thanks a lot, fucker.
Offended and laughing about it.
(Score: 3, Funny) by DannyB on Monday September 23 2019, @03:33PM (2 children)
I'm holding out for when we get ads in the boot loader. Then as a mandated part of UEFI firmware. Then in Intel's "management engine" to be renamed "advertising engine".
The lower I set my standards the more accomplishments I have.
(Score: 2) by maxwell demon on Monday September 23 2019, @04:39PM (1 child)
Well, one day ads will be served directly to your brain through the mandatory brain implant (well, formally it won't be mandatory; it's just that it will be close to impossible to live if you don't have one).
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by DannyB on Monday September 23 2019, @04:53PM
In the future, the US Government will be a wholly owned subsidiary of a large conglomeration which includes MPAA, RIAA, ABCNNBCBSyFi and MSNBCartoonNeTCM and AT&T-MobSprintizen.
Brain implants will be mandatory at birth. Primarily to protect intellectual property. Whenever in ordinary life you happen to unintentionally over hear or see any copyright protected material, then your credit card will be automatically charged for the copyright license. Everyone will approve of this because it is so much more convenient then dealing will the billing for all of the copyright license payments for each and every day. And because public approval is required by law.
Everything will be secure, even IoT. Privacy is assured because only you and the national corporation can read your files. We will stop using absurd obsolete terms such as "citizens" and use the more modern and accurate term "employees". Everyone will be employed. Anyone who there is no job open for is a non-person, and therefore does not count as unemployed, and will be "surplussed".
All surplussed non persons will report to their local surplus centers within 24 hours according to as specified in their UEFI/systemd firmware.
The lower I set my standards the more accomplishments I have.
(Score: 2) by VLM on Monday September 23 2019, @03:36PM (6 children)
Systemd is essentially replacing tiny simple predictable easy to use stuff, with the opposite, which is in itself a gigantic piece of performance art advertising for Redhat consulting services.
The idea is to get billable hours by creating a system thats unreliable and complicated where there was never a problem beforehand.
This process is known as featherbedding and is very common outside FOSS OS development; its not a new business model, only newly applied to FOSS OS stuff.
There's a lot of middlemen out there looking for billable hours and willing to nudge things in the direction of ever more billable hours; god help us if they ever get commit privs on something as simple as "ls" or "cat" or "cd". Can you imagine what our command lines and lives would look like if the middlemen "improved" the ls command?
SystemD IS in itself by design, an advertisement for RHAT consulting services.
(Score: 2) by DannyB on Monday September 23 2019, @05:00PM
The virtues of systemd are predictability and reproducibility.
When nothing works, these two important conditions are met.
The lower I set my standards the more accomplishments I have.
(Score: 2) by stormreaver on Monday September 23 2019, @05:31PM (4 children)
Before systemd, I had spent plenty of time poking around the startup scripts to get a lot of little things working. I was never very good at it, but spent a lot of time online looking for hints and tips on why booting was so flaky, and then editing run-level scripts using those hints and tips. Sometimes, they even solved the problem.
I haven't even touched the boot scripts since I installed my first systemd-based Linux. My computers boot so reliably now that I tend to forget that there is a specialized subsystem for that. I have no idea why people think the SysV boot system was so good, as my experience had always been one of crossing my fingers every time I rebooted a SysV-based computer. It worked most of the time, but it would sporadically require a lot of time figuring out why the computer didn't boot, and there would be no rhyme or reason to it.
(Score: 2) by PartTimeZombie on Tuesday September 24 2019, @12:07AM
+ 1 Insightful.
(Score: 2) by sjames on Tuesday September 24 2019, @11:02PM (1 child)
My experience is opposite. SystemD occasionally decides to drop to the emergency shell with the filesystem unmounted. Manually issuing the same mount command it should have issued works first try. There seems to be no way to make systemd issue the command imperatively.
Under the hood, it's hundreds of config files utilizing the same semantics as the joke "comefrom" instruction.
With SysV, the scripts can be as complex or as simple as you want them. RedHat tended to have crazy over-complicated ones.
(Score: 1, Informative) by Anonymous Coward on Wednesday September 25 2019, @02:15AM
I've had that before. Its the parallel startup of target units. For some reason, on those particular boots, the target dependencies started or finished in a slightly different order, causing a later command to fail. The fix is to add a "Before" or "After" to the right unit file referencing the other unit file, but good luck figuring out which one it is as the error messages are less than helpful.
(Score: 2) by VLM on Friday September 27 2019, @11:15AM
That must be an unusual workload as I rarely had to do anything like that, and when I did there were dozens of working examples on the same system to compare to, and many explanatory websites; very rare to dive into an initscript alone...
(Score: 0) by Anonymous Coward on Tuesday September 24 2019, @10:21AM
I also run a systemd free distro (Slackware) - so the systemd commerical fiasco has no effect on me.